Folks, there appears to be an updated Wifi driver in the MTK feeds. I have updated my script for those who want to build themselves, and posted an updated (simple) compiled build here:
Rahzadan/openwrt_bpi-r4_mtk_builder: OpenWRT Builder for BPI-R4 with Mediatek Feeds
It would also appear that the issue of duplicate ports showing up on the status page has been fixed.
Any noticeable performance differences?
I've been struggling to maintain useable speeds more than a few feet away. I currently have different wifi cards in my R4 so it's at-least useable, and I'm wondering if this is worth swapping the BE14 back in to test.
Which WiFi cards you are using?
The BPI-R4 BE1400, the WiFi7 Module.
I just don't have it installed right now because of the performance issues. So I temporarily switched over to using two MT7916E cards. I was curious if anyone has tried this new driver before disassembling my BPI-R4 and swapping the cards back over.
Stupid question: will this work with stock OpenWrt 24.10.1? Or do you need to install a special build for bpi r4 to make it work with the MT7916E cards?
You need to use script which was created by community member in this thread and add required kmods/firmware for the MT7916E card, then build and install.
I’m sorry I think my initial question just added confusion, let me clarify.
I have the BPI-R4-NIC-BE14, the WiFi7 module made for the BananaPi R4. But due to the abysmal performance I removed it and temporarily replaced it with two MT7916E modules from AsiaRF. This was only a stopgap until the BE14 drivers got better.
I was asking if anyone had a chance to try out the image from @Rahzadan and how the performance on the BE14 is, I wasn't trying to ask about the MT7916E at all.
Essentially I wanted to know if these new drivers are worth the hassle of disassembling my BPI-R4 to remove the MT7916E's and put the BE14 back in. I really only mentioned the swap at all to avoid the impression that I was just too lazy to flash an SD Card and try it myself lol.
So my curiosity got the better of me and I ended up putting my BE14 back in just to try out this new driver.
Here is what I noticed so far in the short amount of time I had to test it:
Testing using iperf3 with iPhone 15 Pro which is Wi-Fi 6E, Supporting 2.4 GHz, 5 GHz, and 6 GHz
MLD seems to work reliably, I connected quickly and negotiated the fastest frequency every time I connected.MLD was actually more problematic. I would typically have to wait at-least 1min for my iPhone to actually connect whereas MLD was nearly instant.1.3Gb/s to 1.5Gb/s, Which is typical real-world performance for the iPhone 15 Pro.1Gb/s from more than 6in away now (this is not a joke). Previously I could only achieve 1Gb/s+ when the phone was within less than 1ft of the router.1Gb/s+ range, even if I see a dip in speed it will quickly recover. Prior I would have already been at 500Mb/s or less.500Mb/s to 800Mb/s (Though at this point I'm very close to my other WiFi router and in another room.) Prior I would have been below 50Mb/s.80Mb/s and 250Mb/s. Prior I would have already dropped to around 1Mb/s or less and possibly disconnected entirely.1Mb/s and 8 Mb/s though the connection isn't super stable it does mostly still work. Prior I 100% would have already disconnected and the SSID would no longer be visible.iperf3 won't run anymore. I was able to SSH into OpenWRT a couple times from this far away but keystrokes weren't even being sent, but I did see the OpenWRT terminal prompt. [1]-80dBm to around -72dBm.tx_power is actually at its max or at least close to it as this is the first time I actually felt any real heat coming from the BE14 Module.[1]. This spot in particular is a big deal. The room Im in at this point has copper pipes in all three interior walls. In addition to that it aligns perfectly so that between me and the R4 is a, sliding glass door (aluminum frame), French doors (aluminum doors), copper pipes in the kitchen walls, plus the refrigerator and the microwave which are both steel. This spot is so bad that my current WiFi router - which is 15ft closer - struggles to maintain useable speeds in here.
So There definitely seems to be some performance improvments in this latest update. I'll spend some more time with it and see if it's possibly even in a useable state finally.
@Rahzadan and @woziwrt , hope you don't mind me tagging you in this. Are there any tips or advice on building my own image based on these updates? Im hoping to start maintaining my own image that stays updated with the MTK feeds at-least until the open source mt76 driver has matured enough.
However in this image I have noticed that opkg update throws an error, several software packages are not listed in the search, and most aren't able to be installed. I'd like to avoid this issue if it's possible to have custom image still be able to download packages from OpenWRT?
I am new to building OpenWRT images, but the R4 has motivated me to start learning. Im getting a build environment set-up and am going to start playing around with it. But I have no experience in modifying build scripts like this, such as changing defaults, adding additional patches or modifications or what the best source of information would be for individual options in the build menu.
Any guidance would be very appreciated, and thank you for the images. @woziwrt if it weren't for you and FrankW over on the BPI Forums I'd pretty much be lost at this point. Three months I've been at this and instead of getting frustrated, Im only getting more motivated to learn and experiment.
I agree BE14 seems to be slow, comparing to similar device type.
If you have enough knowledge and you know what is GitHub actions, you can do an image based on my action but of course in this thread there are better scripts.
I’ve heard the term a million times but I have never used it, so I’m not sure how it works. But I can look it up.
Sorry if this is a dumb question, but you mean build scripts? I’ve been messing around in the build menu for a few hours now. But I haven’t made it beyond that yet, mostly because I had no idea how many options are in that menu 
Well that went smoothly for my first time ever compiling...anything. Built really quick and with no errors! I used @woziwrt's Github repo and build script, with a lot of customization.
Setup my build environment with a Ubuntu 24.04 VM on my EPYC 7402p Unraid server, VM only had 24 of 48 threads available to it and the image compiled in, I'm not actually sure but it was less than an hour. It actually took longer to prepare everything else prior to make menuconfig.
I even included quite a-lot of packages and libraries since im trying to make an image that contains everything I need by default. This way I don't really need to worry about installing things from opkg, or compiling separate packages later.
Stuck at work right now, but I cant wait to tryout my first ever OpenWRT image when I get home later.
The BE14 board is far from perfect. Its main problem is that it is very prone to Wifi noise. It's difficult to get good range and throughput with it. This isn't only a driver issue, but a hardware issue with the power amplifier / power regulator of the BE14 board unfortunately. I've read the threads regarding shielding the BE14 and the general consensus seems to be that it's a lost cause. While the BE14 board works, it is noisy and not ideal.
Hi @Rahzadan ( Thanks for sharing your build )
I tried your build ,where its looks like the CPU utilization is not moving very well compare to latest build from @woziwrt
on woziwrt build CPUs are working (better) i'm getting Network speeds around 
820Mb/s
on your build the latest one , cpus are not working equally and one is taking the full load and the network speeds are around 
530Mb/s
Note : i'm using 5G modem m.2 for network , I built the image based on your repo with adding 5G modem packages such as ECM , QMI, Modem inteface etc..
The pre-compiled builds on my github page are nothing more than compilations from MTK Feed and OpenWrt sources, with a few module selections to meet my personal/particular needs. I only provide them as releases because I figured someone might be able to use them.
The compiled build from @woziwrt you mentioned above is from April 26, and there has been many updates since then, which are/were incorporated into the build I compiled.
I'm not a coder/programmer. I fact, I literally couldn't code my way out of a paper bag. The easy part is compiling/building someone else's code, which is what I'm doing with the releases on my github page. As far as I know, @woziwrt is not modifying the code in any way either - his build script is VERY similar to mine.
In a nutshell: Maybe a future build I compile will fix your issues, maybe it won't. The best people to direct your issues or bug reports to would be theOpenWrt/Mediatek team.
The only "testing" I do before I post a compiled binary to my guthub is to make sure the image boots on my BPI-R4 units and that basic functionality is present. If it appears to work, I post the updated build. I don't do extensive testing.
most probably could be feature to enable the cpu offloading ?
nah dude its mostly related to assigning the load between the cores , where the majority is moving to core 0 but in the fact its looks like the system is not set on the good way to deal with all network interfaces ,
example if you suppling the network to other device through Lan you will see different utilization than WIFI, all of them are unbalanced .
As other users point out, I'm afraid that the highly variable performance of the BE14 card is by design:
In my case I bought a BPI-R4 to unify my set consisting of an x86 box, a router in dumb AP mode and an ONT and I have found that the AP part, after seeing what happens with the BE14 card, I have not dared to buy it and I bought two AsiaRF cards. I hope they work better than what BE14 card users are reporting.
There are certainly differences between the internal design of the wireless part of a current wifi router:
This is a picture of the 2.4GHz RF part of an AX router. The main chip (MediaTek MT7976GN) is visible and the four RF Front-End Module (FEM), i.e. the dedicated power amplifier chips (KCT8239SD), are also clearly visualized:
Now, the RF part at 5GHz, with dedicated MediaTek MT7976AN chip and its four dedicated FEM/power amplifier chips (KCT8539HE FEM):
If we take a look at the picture of the BE14 board:
Both front and back, no FEM is displayed, so these chips appear to carry eFEM and as many have already found, the performance of this module can exhibit highly variable range. That is, they work this way by design.
The question I ask myself is:
Is there a possibility that, through drivers or EEPROM firmware, they will improve the management of the eFEM (embedded Front-End Module, also known as integrated power amplifiers) of the BE14 board?
If not, do we know if SinoVoIP will release an improved revision of the eFEM chips or will they make a dedicated FEM design instead?
Thanks @Rahzadan just tried your build, still wasnt straight forward but finally, finally my banana works LOL 
Got 910Mb/s on the 6g wifi download on speedtest, never saw that even in wired machines on my net, and it is connect throught 3 switches and one floor and to a vm fw which also go throught 2 switches and to a router with double nat, now i can buy at least one more, i almost gave up on it and put it aside as failed experiment.
All i wanted was wifi7 with openwrt, 3 or maybe 4 month later i have it 
Thanks for your work!
I found a setting under network, global network option, packet steering is set to enabled, try changing to "enabled (all cpus)"
This can't help for assigning the loads properly
