@namidairo has a pending patch for this
@hurrian Can you adapt this so that we no longer require serial to reflash?
Same issue with minimal-oc r33781 : on the initial boot, no RX on wan.
The kernel trace didn't agree with the reported speed :
airoha_eth 1fb50000.ethernet wan: Link is Up - 1Gbps/Full - flow control off
but luci and /sys/class/net/wan/speed reported 10Gbps.
After unplugging and plugging back the cable, the kernel trace was correct :
airoha_eth 1fb50000.ethernet wan: Link is Up - 10Gbps/Full - flow control off
but it didn't solve the issue.
After a reboot, I got the correct speed reported by the kernel immediately, and it worked.
I do not seem to have this issue. WDS + official OpenWrt SNAPSHOT r33661-92c7feebd2, I'm getting 160Mhz on 5Ghz.
Thanks, I removed that patch as of minimal-oc-ubi-2026.04.04-r33792. Please test.
same experience here, however it looks like fixed with minimal-oc-ubi-2026.04.04-r33792 build
I stuck in official snapshot r33768 build. sysupgrade doesnât works anymore. it seems flashing, but after reboot it still boot old build.
The rare but persistent problem of occasional sysupgrade failure remains an unsolved mystery. @andrewjlamarche has suggested that lowering the SPI flash speed may potentially be the solution.
Therefore, I have lowered the SPI from 50MHz to 33MHz on minimal-oc-ubi builds starting from 2026.04.05-r33794. As a control, my snapshot builds remain at 50Mhz.
If you're particularly OCD, you can help test this by sysupgrading minimal-oc-ubi 100 times, followed by snapshot for another 100 times. I'm only half-joking.
I plan on importing the GPIO and MDIO patches (once I finish fixing 6.18), but at this point I have low confidence that the http web UI will ever be accepted in mainline OpenWrt - everytime something like that has been proposed, it gets rejected...
I share the same view, which is why it was implemented as a standalone component.
Testing flash reads is easy, for example you could run md5sum /dev/ubi0_4 in a loop.
To test writes, you can write random values to recovery (not mounted, so this is fine) :
cp /dev/ubi0_3 /tmp/recovery.bin
SIZE=$(du -b /tmp/recovery.bin | cut -f1)
for i in $(seq 1 100); do
dd if=/dev/random of=/tmp/random.bin bs=$SIZE count=1 2>/dev/null
SRC=$(md5sum /tmp/random.bin | cut -d' ' -f1)
ubiupdatevol /dev/ubi0_3 /tmp/random.bin
DST=$(md5sum /dev/ubi0_3 | cut -d' ' -f1)
if [ $SRC == $DST ]; then
echo "Write $i OK"
else
echo "Write $i failed : $SRC != $DST"
break
fi
done
ubiupdatevol /dev/ubi0_3 /tmp/recovery.bin
In my case, both are stable, but I never had any corruption on sysupgrade too.
I tried minimal-oc r33794, it seems stable for sysupgrade. i tried 10 times and no issue for sysupgrade. but it too unstable to use. with that build, device reboots itself too frequently. especially, iperf3 test between wan(Main PC, 10GbE)-lan2(NAS, 10GbE), it canât sustain test a minute.
Maybe there would be traces for the reboot on the serial console.
But first you might try lowering the clock (in Luci : Status -> SOC Status) to 1200Mhz, to make sure the issue doesn't come from the default overclock.
device still reboots at stock clock too. and i missed point of reboot occured. page goes too fast.
i gave up. i just rolled back to minimal-oc r33371.
I wanted to share a fix for those using the OpenWrt SNAPSHOT (Kernel 6.12.x) on the Brightspeed XR1710G.
Many of us noticed that even with "Hardware flow offloading" enabled in LuCI, CPU usage remains high (50%+ sys load) during high-speed WiFi-to-LAN tests, and airoha-npu-mbox interrupts stay at zero.
The Problem: Race Condition
The issue is a race condition during boot. The firewall (fw4) initializes the hardware flowtable before the mt76 wireless driver has fully initialized the radio interfaces (e.g., phy0.0-ap0). Because the interfaces don't exist yet, they aren't added to the NPU's acceleration map.
How to Verify
Run this command. If you don't see your phy0.x interfaces in the list, your WiFi is NOT being offloaded:
nft list flowtable inet fw4 ft
The Fix
The fix is to restart the firewall after the wireless interfaces are up. You can test this manually first:
/etc/init.d/firewall restart
After the restart, check nft list flowtable inet fw4 ft again. You should see the phy0 interfaces added to the devices list. In my tests, this dropped CPU usage from 51% down to ~12% at 2.5Gbps throughput.
How to make it permanent
Add a delayed restart to your /etc/rc.local to ensure the WiFi drivers are ready before the firewall reloads:
- Edit
/etc/rc.local:
cat <<EOF > /etc/rc.local
# Delay firewall restart to allow mt76 interfaces to initialize
(sleep 15; /etc/init.d/firewall restart) &
exit 0
EOF
2.Ensure the script is executable:
chmod +x /etc/rc.local
/etc/init.d/done enable
My Setup:
- Device: Brightspeed XR1710G
- Firmware: OpenWrt SNAPSHOT r33728+4-cd0f6ddf13c0 / LuCI Master 26.077.44598~1c34772 (Kernel 6.12.79) https://github.com/OpenWRT-fanboy/w1700k-ubi-build
- Target: airoha/an7581
Hopefully, this helps others struggling with the 2.5G/10G "CPU ceiling" on this hardware!
You don't need to chmod +x /etc/rc.local. You can also change the rc.local in Luci under Startup->Local Startup (tab).
I also think we need to restart the firewall service if we add a new radio etc. Not sure if FW takes care of this by itself.
Ansuel committed this patch a few days ago which should make this unnecessary.
I don't think that's correct. Even with that patch, the wireless interfaces are not plugged into fw4.
Note that this is only a problem with snapshot. minimal-oc-ubi does not have this issue because I debugged PR #22533 with @tesf23 several weeks ago: Quantum Fiber W1700k support - #2523 by tesf23
it didnât work for reboot issue. it still reboots.
Just now ordered one at Amazon. Is there any specific version I should start with? Any version thatâs mostly in working condition? Sorry, I tried to read the last 4 monthsâ replies and lost where to start.