Exactly, that matches my observations. Probably we need to wait for Wi-Fi 8 chipsets to fully support STR. But thx for sharing your results.
But anyway, I am sure the W1700K will be my primary Router for next years. So it will be there and is waiting for new clients to come.
SOE + Wifi/PPE fixes + EIP93 dynamic fallback + bonding PPE offloading and bonding-SOE support + LRO DSA fix
All regression has been fixed.
Kinda tiring to keep following the mainline/fanboy changes. I’m busy due to real life issues and NPU FW project (NPU-based DPI circumvention). Will not be updated any soon.
I find the best way to gauge is by the number of WiFi frames the AP has heard from the client on that band. If the count is climbing, that link is carrying traffic and if it's flat, the link is idle, even if it shows associated.
Drop this straight into your w1700k SSH session:
MAC= 55:11:33:bb:ff:a1 # Change to your client's MAC
BASE=$(ls -d /sys/kernel/debug/ieee80211/phy*/netdev:*-mld*/stations 2>/dev/null | head -1)
[ -z "$BASE" ] && { echo "No MLO AP interface found - is an mlo SSID up?"; exit 1; }
[ -z "$MAC" ] && MAC=$(ls "$BASE" | head -1)
S="$BASE/$MAC"
[ -d "$S" ] || { echo "Station $MAC not found. Associated:"; ls "$BASE"; exit 1; }
echo "Station: $MAC (Ctrl+C to stop)"
echo "Links : $(ls -d "$S"/link-* 2>/dev/null | sed 's,.*/link-,,' | tr '\n' ' ')(0=2.4 1=5 2=6)"
echo "Start an UPLOAD iperf now (no -R). Non-zero + climbing = that band is active."
g() { cat "$S/link-$1/rx_fragments" 2>/dev/null; }
d() { [ -z "$1" ] && printf " n/a " || printf "+%-6s" "$(($1-${2:-0}))"; }
p0=$(g 0); p1=$(g 1); p2=$(g 2)
while :; do
sleep 2
c0=$(g 0); c1=$(g 1); c2=$(g 2)
echo "$(date +%T) 2.4G:$(d "$c0" "$p0") 5G:$(d "$c1" "$p1") 6G:$(d "$c2" "$p2")"
p0=$c0; p1=$c1; p2=$c2
done
Then on your client: iperf3 -c 192.168.1.1 -R -P 8 -t 30
You should see those numbers climb on each band if it has traffic.
14:34:47 2.4G: n/a 5G:+183 6G:+241
14:34:49 2.4G: n/a 5G:+126 6G:+162
14:34:51 2.4G: n/a 5G:+292 6G:+188
14:34:53 2.4G: n/a 5G:+175 6G:+301
14:34:55 2.4G: n/a 5G:+235 6G:+419
14:34:57 2.4G: n/a 5G:+180 6G:+161
All I can say is that MLO is a lot more stable than the last time I tested, still plenty of room for improvement.
In its current state I don't see any difference between MLO and straight EHT320, but I'm capped by my 2.5G link and the QCNCM865 = 2 links max so I get the same speed either way.
I think the real test is with a true 3 link mt7927 with a 10g link on the other side?
I read somewhere that the QCN865 only supports 160+160 MHz MLO. It doesn't support 320+160 MHz.
Thank you for sharing the script. However, I got some slightly strange results when I tried it.
The actual traffic throughput is around 2 Gbps, but the script sometimes reports a frame count of zero. I have, of course, confirmed that the MLD MAC address is correct. My assumption is that offloaded packets bypass the kernel, which may explain why the reported values are extremely low.
The script also appears to indicate that the 6 GHz link is being used primarily. However, when I observe the actual RF spectrum with a HackRF, the 5 GHz band also appears to be in use.
In any case, just one month ago, merely connecting to an MLO SSID caused the AP to crash. Considering that, I think it has improved tremendously. Great job!!
The reported maximum MLD link rate is 5.7 Gbps, which is the same as EHT320, so it does seem correct that a 160 MHz + 160 MHz configuration is the maximum supported combination.
However, when I actually configure it as 160 MHz + 320 MHz, the 6 GHz link appears to be using the full 320 MHz bandwidth.
Every time I test this, I get unexpected results. It feels like trying to find my way through the dark...
Could you try with newest firmware: https://github.com/mediatek/mtk-openwrt-feeds/commit/e1d5a2d3f750976080b7b1559cabafe31322819f
Also could you show output:
dmesg | grep -i npu
I am currently testing @Gilly_1970 's build, so this is not a self-built image. What would be the best way to test the newer firmware?
I tried replacing the files under /lib/firmware/mediatek, but doing only that seems to break the MLO stability of @Gilly_1970 ’s build. On the second connection attempt, the client no longer receives a DHCP lease.
root@OpenWrt:/lib/firmware/mediatek# find .
.
./mt7996
./mt7996/mt7996_wm_233.bin
./mt7996/mt7996_rom_patch_233.bin
./mt7996/mt7996_dsp.bin
./mt7996/mt7996_wa.bin
./mt7996/mt7996_wm_tm.bin
./mt7996/mt7996_wm.bin
./mt7996/mt7996_rom_patch.bin
./mt7996/mt7996_eeprom_2i5i6i.bin
./mt7996/mt7996_wm_tm_233.bin
./mt7996/mt7996_wa_233.bin
./mt7996/mt7996_eeprom_233.bin
./mt7996/mt7996_eeprom.bin
./mt7996/mt7996_eeprom_233_2i5i6i.bin
./mt7996_org
./mt7996_org/mt7996_dsp.bin
./mt7996_org/mt7996_wa.bin
./mt7996_org/mt7996_wm.bin
./mt7996_org/mt7996_rom_patch.bin
./mt7996_org/mt7996_eeprom_2i5i6i.bin
./mt7996_org/mt7996_eeprom.bin
root@OpenWrt:/lib/firmware/mediatek# dmesg|grep -i npu
[ 0.000000] OF: reserved mem: 0x0000000084000000..0x00000000849fffff (10240 KiB) nomap non-reusable npu-binary@84000000
[ 0.000000] OF: reserved mem: 0x000000008a000000..0x000000008cbfffff (45056 KiB) nomap non-reusable npu-pkt@8a000000
[ 0.000000] OF: reserved mem: 0x000000008cc00000..0x0000000090bfffff (65536 KiB) nomap non-reusable npu-txpkt@8cc00000
[ 0.000000] OF: reserved mem: 0x0000000090c00000..0x0000000090c067ff (26 KiB) nomap non-reusable npu-txbufid@90c00000
[ 0.000000] OF: reserved mem: 0x0000000090c06800..0x0000000090e067ff (2048 KiB) nomap non-reusable npu-ba@90c06800
[ 3.951842] airoha-npu 1e900000.npu: NPU fw version: 0.1111
[ 14.104436] input device check on
[ 15.640539] mt7996e 0000:01:00.0: NPU version: 0.1111
That's an impressive list of patches! How do you know that all the regressions have been fixed? Is everything working well with no errors for you? Have you done any performance comparisons with other builds?
I meant there was no regression from the original positive results (I re-run the same automated tests but it takes time) - from Gemtek W1700K Community Builds - #343 by iCare
And Gemtek W1700K Community Builds - #374 by iCare
[Aug 6, 2026, 5:28:20 PM UTC] kern.warn: [ 89.044455] airoha_eth 1fb50000.ethernet wan: validation of usxgmii with support 0000000,00000000,00000000,00006000 and advertisement 0000000,00000000,00000000,00006000 failed: -EINVAL[Aug 6, 2026, 5:28:20 PM UTC] kern.err: [ 89.262339] airoha_eth 1fb50000.ethernet wan: could not attach PHY: -22
this might give a clue using wan port is not functional
My new project. The concept is simple; I've used LLM and reverse engineering skills to make human-readable and compilable codes from en7581_MT7996_npu_rv32.bin and en7581_MT7996_npu_data.bin from OpenWRT tree. Then, I make all the functions public by exposing all of them via public headers. Finally, LLM has generated the original version of the complete NPU implementation from these human-readable reverse-engineered code.
This is not even 0.1.0 level in terms of completeness, but this will be used to make "WiFi offload + DPI circumvention" NPU. I hope this would be useful for someone working on a custom version of W1700K1/K2 NPU firmware.
[EDIT] Basic functions (e.g. WiFi offloading) are now tested and confirmed to work normally.
One thing I might want to add is that, since most of the disappointing factors remaining for W1700K/K2 are about WiFi, if there is someone knowing well about WiFi stuffs and MT7996 firmware or NPU part of WiFI offloading (which are not my stuffs), they could try this kind of way (direct modification of MT7996 firmware or NPU firmware for WiFi part) to breakthrough the WiFi performance. (if it does not check signing, like NPU one)
I don't know. I'm just writing gibberish after painful orthopedic treatment.
One more thing: I'm also working on custom NPU firmware with custom OpenWRT Luci menu to provide Marvell/Broadcom/etc.-like Switch ACL feature.
Switch ACL is in-switch-chip firewall-like feature that does not cost the router CPU usage for initial L3~ binding. For this, PPE needs additional feature called "IFC" (Ingress Frame Classifier) which is a TCAM within PPE (like the above large switch chips). This has not been implemented for AN7581 (only for 7583 in mainline and OpenWRT) but my SOE work has ported it partially already; Fully featured IFC is needed but AN7581 probably has the same fully-featured IFC H/W same as AN7583.
I'm thinking of serving a custom version of AN7581 NPU with DPI circumvention and Switch ACL, and a Luci extension package to control DPI feature and ACL list.
Is anyone else seeing a very small number of ethernet errors on the wan port? I'm seeing approximately 24 errors per day. It's no big deal on throughput but I am curious what is going on.
Airoha FlowSense
⚠
Physical Bottleneck
Hardware errors detected on WAN (2 rx_errors). Check WAN cable or SFP. Latency stats may be misleading.
I'm on hardware 2.1 running the fanboy builds and the wan is connected to the 2.5 Gbit/s port on a Comcast XB10 in transparent mode with 2 Gbit/s service (over-provisioned by 20%). It may well be that the port is saturated by a burst every now and then. I've replaced the wan cable with a shielded cat6a cable but no change.
Flowsense Updated luci-app-airoha-flowsense-1.1.5-r4
I've added in new gauges that captures frames per second on each of the wifi bands, which is handy for MLO. While I was tying it all together, I also ended up giving the instrument cluster a major facelift. 
Note: Because LuCI isn't wired up correctly for MLO, I'm currently working around it so the gauges display with MLO, but it's still a work in progress.
I have been averaging 150 Rx errors per day on WAN over the last 20 days on Fanboy's builds. It's on HW 1.0. Besides you and me, I haven't seen anyone else report this thus far. My original post about the issue in this thread above: Gemtek W1700K Community Builds - #290 by gregnukem
Nice work, maybe you could move the STA and dB lines below the RTY lines. It's a little bit disturbed by the circles.
P.S. the CPU load is affected by rendering the page/plugin. So it's not the real value. Mine is showing 15-20% vs. nearly 0% in terminal.
I have MLO disabled. Is the w1700k secretly splitting data between 6 Ghz and 5 Ghz? I just realized that the only way the numbers work out is if the data from the 5 and 6 Ghz dials are added together.
This screenshot is on my W1700K configured as a dumb AP with the wan labeled port folded into the lan bridge all connected to the upstream with a 2.5 Gbit/s ethernet lan to the desktop. The iperf3 was between a wifi connected laptop and an ethernet connected desktop.
wolfgang@bonnet:~$ iperf3 -c dyson
Connecting to host dyson, port 5201
[ 5] local fdfa:9105:918::30 port 58680 connected to fdfa:9105:918::31 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 208 MBytes 1.74 Gbits/sec 0 4.14 MBytes
[ 5] 1.00-2.00 sec 218 MBytes 1.83 Gbits/sec 0 4.14 MBytes
[ 5] 2.00-3.00 sec 222 MBytes 1.86 Gbits/sec 0 4.14 MBytes
[ 5] 3.00-4.00 sec 219 MBytes 1.83 Gbits/sec 0 4.14 MBytes
[ 5] 4.00-5.00 sec 222 MBytes 1.87 Gbits/sec 0 4.14 MBytes
[ 5] 5.00-6.00 sec 221 MBytes 1.85 Gbits/sec 0 4.14 MBytes
[ 5] 6.00-7.00 sec 213 MBytes 1.79 Gbits/sec 0 4.14 MBytes
[ 5] 7.00-8.00 sec 224 MBytes 1.88 Gbits/sec 0 4.14 MBytes
[ 5] 8.00-9.00 sec 224 MBytes 1.88 Gbits/sec 0 4.14 MBytes
[ 5] 9.00-10.00 sec 219 MBytes 1.84 Gbits/sec 0 4.14 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.14 GBytes 1.84 Gbits/sec 0 sender
[ 5] 0.00-10.01 sec 2.13 GBytes 1.83 Gbits/sec receiver
iperf Done.
wolfgang@bonnet:~$
That's odd, you're seeing two different MACs on each radio?
I've been messing around a lot trying to get the Wi-Fi bands to display correctly under MLO, so there's a fair chance I introduced a new glitch.
