Quantum Fiber W1700k support

@namidairo has a pending patch for this

@hurrian Can you adapt this so that we no longer require serial to reflash?

6 Likes

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.

1 Like

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.

1 Like

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:

  1. 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:

Hopefully, this helps others struggling with the 2.5G/10G "CPU ceiling" on this hardware!

4 Likes

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

3 Likes

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.