I had a build based on that done 30mins age. Glad I did not flash it yet. I do have serial pigtail sticking out. So no biggie if it bricks.
@OpenWRT-fanboy may you please add kmod-inet-diag and kmod-tun packages to your build? its needed for sing-box, allows to works with vpns/proxy, thanks!
@glassdoor Does the system crash (traceback what you have) disturb router work at all or it just raise in dmesg? (just curious)
It make wifi unusable.
building one from your repo to see if thing change.
As it is right now. lumos-npu builds wifi are not production ready. And do not know where the issue lies. so starting clean from your repo.. as they are as minimum as it gets.
Edit:
while waiting for the build to finish. I had a quick look at bridger changes between the 2024 version you are using and the sept 2025 version that Lorenzo recommended. Very minimum changes. The updates after sept 2025 are quite substantial thou.
If you donât return your equipment within 21 days, youâll have a non-return equipment fee.
$150 for a Wi-Fi or All-Fi Gateway
$200 for an All-Fi Hub
$65 for any Wi-Fi Extenders or All-Fi Boosters included as part of your Extended Wi-Fi
New price in 30 days = current + $150.
1 Like
That doesnât give me the info I asked for. I was hoping for /etc/config/wireless. Without that, my advice is to start a clean config and only change the minimum settings necessary to config wifi. I had some additional settings that accumulated over time as I followed discussions here, and I ended up with the performance issue you described.
And after 30 days? They will destroy them?
All will come again to ebay⌠and then - Adam Smithâs law of supply and demand.
Kr
preliminary results from testing relating to NPU wireless offload with w1700k as a AP with bridger.
Lumos-npu, minimal-npu and danâs v14 branchs all work when bridger is rolled back to
PKG_SOURCE_URL=https://github.com/nbd168/bridger
PKG_SOURCE_DATE:=2024-04-22
PKG_SOURCE_VERSION:=40b1c5b6be4e73a6749cf2997c664520eb20055d
PKG_MIRROR_HASH:=b3ba2ab5ffa1af55f8da2cae5a90df486474b97ed4c359ec40c986aa6e82c300
The other bridger version tested included the default that lumos and minimal repo came with and the sep 2025 version. They all show the following bugs
-
kernel warning which resulted in high latency and low throughput on wifi. (boot dependent, seems like a 50-50 chance if you get a good boot or bad boot). Easy to test. On a bad boot, iperf3 TCP DL retries are high and UDP DL out-of-order packets are massive.
-
wifi connection degrading after a while.. 2-3 hours at the shortest. It will stay connect but throughput drops to like 10-20Mbps. rebooting client device does not help. Only rebooting AP restores to normal throughtput.
Please help test and verify. Please help do reboot test. the more times the better. On a bad boot you will get the kernel warnings I posted yesterday.
I am going to do a long test with lumos-npu with only the bridger version rolled back as stated above. So far it so good. Will update if this setup breaks.
3 Likes
Iâm not so much sensitive to see difference 20mbit when I get 2000 
From the other side, I have only 900mbit network at homeâŚ
I have another issue, that I can not figure out whatâs going on - I turn off my phone for a hour, then when I turn on, speed was like 1 Mbps, and can not achieve more, so I reboot the device. I was trying to reproduce that and it seems to be easy: in tmux wifi down; sleep 2; wifi up and then speed goes down. Maybe it is somehow related that I donât use randomized mac address on my phone? Need to check.
Does anyone know if the 802.15.4 radio is available as a device under /dev/?
1 Like
No issues with non-NPU wireless. I have one in use by the family for the last week. various mobiles, laptops, tablets. apple.. android⌠power on off, sleep⌠gaming, wifi calling.. all working great. Essentially lumos. I donât have a single complain.
lumos-npu with the rolled back bridger has been working well so far and I was debating if I should put it into wider testing by the family but decided against it. The wifi latency has increased significally while offering only marginally higher max throughput (I do not have any 320MHz 6G devices).
2 Likes
The EFR32 is available at /dev/ttyS1. See this post: (link)
2 Likes
Have you done test with wifi down; wifi up and it works normally on your device(s)? Also please make sure that randomized mac address is disabled and you use physical mac address.
And if you can, just let me know if that is on lumos-npu or non-npu.
Thanks
ya wifi down and wifi up works fine. I donât have the habit of using random mac address. Using factory default. This is for lumos. Actually if your internet speed is lower than 2Gbps npu wireless offload has little benefit from w1700k as an AP.
lumos-npu is still early days. need much more testing.
edit:
just tested wifi up and wifi down on lumos-npu also. Works fine.
thatâs interesting. Thank you for making test.
I had this slow speed when my Pixel 6 was connected with 160Mhz.
As soon as I changed the 6Ghz radio on the W1700K to only use 80Mhz it was fast again.
I will test this again next week.
EDIT: i think it was with this build:
Can you expand on that please. Are you saying that it helps more with routing, not solely as an AP?
I've discovered the root cause of one of the problems that have been causing wifi performance degradation.
Upon boot, I ran a speedtest on an iPhone. Everything appears normal. However, when I run it again immediately after, speeds are dramatically reduced and ping times are through the roof. Once this degradation appears, it can only be remedied by rebooting.
This problem is caused by the bleeding-edge eMLSR patches by Lorenzo. Too bleeding-edge, it turns out.
This problem affects ALL of my builds of the last few days, regardless of NPU status. However, NONE of the builds on GitHub have these patches. Please use Attended Sysupgrade to upgrade to one of the latest releases (it's easy!)
If you don't have the GitHub option on Attended Sysupgrade, you are probably using an older build that doesn't have this problem, but you should upgrade anyway to take advantage of this awesome feature.
2 Likes
as an AP, it can push 1500Mbps DL and UL on wireless without NPU offload. And with very low latency to boot.
wireless with NPU offload frees up the cpu (almost zero load) but the trade off as of my testing right is that latency increased significantly. On waveform bufferbloat test. It went from A(without wireless NPU offload) to C. Same can be observed from Speedtest 12-20ms to 60-100ms latency on downloads. This needs more testing but this latency increase is consistant on various wireless NPU builds I have tested.
done updated first post