Thanks for the results, my cards made a detour back to china so I still cant test myself. Any chance you can test the “MLO Alpha Release” (assuming any of your client cards actually work with MLO)?
To remove the variable of your ISP/forwarding, you could run iperf3 on the Banana Pi (say iperf3 -s) and then measure directly from your client (iperf3 -c [IP]). It is also possible to use more than one concurrent TCP connection (e.g., -P 8 for 8 connections).
@frank-w do you know if the upstream mediatek code for the filogic880 runs on the Banana Pi as is or if one would have to start with the Sinovoip repo
Mainline misses some patches, when using daniels or my repo bananapi r4 works so far,but without rss/lro. Wifi card needs at least a patch i have in my repo and special firmware (both in my 6.10-rc branch),maybe more is needed for full support.
So if you want to use all features so far you need to use sinovoips version with the caveat that it is old and it’s hard to add newer drivers.
Sorry, upstream was not quite the right word here ^^. What I mean is, that in addition to sinovoip, mediatek also maintains a git which seems still based on the outdated openwrt 21.02 (it is the basis for sinovoips work after all), but unlike sinovoip they claim that MLO is “working” and from a quick glance there is a build target for the Banana Pi.
I am just not sure what the difference between the git repos from mediatek and sinipoip is other than that the latter seems 5 months old and include a patches for 2.5G ethernet.and the older mt7916 (i.e., asiarf) cards.
I completely agree with all your arguments. And the most annoying thing is that they simply begin to ignore everyone who asks too many clarifying questions. In principle, I am ready to wait, but then I would like my 2 QCA9880 to work as a temporary solution. Why they don’t work is unclear. No answers either
you can add the firmware either after installing to SD (in /lib/firmware/mediatek) or add them to $OPENWRT/files/lib/firmware/mediatek, where $OPENWRT is your build dir - but later one is discouraged.
When you change something and do a make, those (binary) files that are changed will be overwritten. So if you change sources, it should produce the new binary files without extracting any archive over the changed file(s), but i am not 100% sure if there is not some sort of checksum-testing.
Kernel patches must be applied like frank-w said in target/linux/mediatek/patches-6.6
edit: just tested it myself. when you modify e.g. ./build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/linux-6.6.35/drivers/net/wireless/mediatek/mt76/mt7996/init.c and execute make, it deletes those changed files and extracts the linux archive again. i know there was some sort of command like make kernel or make packages/kernel, but cant remember. this only recompiled the kernel without touching anything else.
edit #2: when changing sources, you need to use make target/linux/compile and make package/kernel/linux/compile instead of make only. When using the first two commands, changes to sources will be applied.
Patching in openwrt is a bit tricky (thats one of the main reasons i do not use it). It uses mainline mt76 not the one from linux kernel…so you have to add patch to the mt76 package somehow.
Thank you! I will give this a try, placing the firmware in lib/firmware/mediatek didnt work for me either when i tried, that was doing both methods via files in make and using scp once the device was booted.
Is it currently possible to install a driver in openwrt to make the be14 wifi card work or maybe there is an image with driver to install from the manufacturer’s website to test this card?
Here is the power graph captured at 100sps with a FNIRSI FNB48S from when I plug the usb-c to the time I do the speedtest (the 14W peak). Note that I have a 10G ethernet SFP and a DAC to my ISP box connected to the R4. I also got a new speed record of 3248Mbps / 273Mbps during this run.
Finally also got my 2 cards, I have not had the time to compile openwrt with patches for the 3 interfaces (and I guess I would still not get EHT mode in openwrt as it is?) but using the MP4 image I can confirm the “bug” of only seeing 1Gbps but at least I managed to test with a 10G SFP cable and its not iperf3 (almost the full 10G are reached).
Can anyone using a current openwrt snapshot with franks patches confirm they get higher numbers (I had ~1.5 with the devices next to each other like this using two mt7916 cards).
