Is there a way to recover from a bad configuration by entering failsafe mode by pressing reset button during router boot-up? I tried following failsafe troubleshooting instructions but wasn't successful. I have a TP-LINK OnHub flashed with 23.05
Your settings don't seem to apply to wireless ap.
How is that different from the settings below?
modprobe nss-ifb
ip link set up nssifb
# Shape ingress traffic to 450 Mbit with chained NSSFQ_CODEL
tc qdisc add dev nssifb root handle 1: nsstbl rate 450mbit burst 450kb
tc qdisc add dev nssifb parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 300 target 2.5ms interval 25ms set_default
# Shape egress traffic to 450 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 450mbit burst 450kb
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 300 target 2.5ms interval 25ms set_default
do try the reset button after it's booted. to make openwrt to factory default
the overall reset is to reflash with the google tool back to google firmware
then back to openwrt USB to do a full flash erase and reinstall
Those settings are only needed if you are using it as a router. You do not need to do anything if using it as an AP. I don't even have SQM installed on my AP build. It just works as is for an AP. You can test this with a vanilla build vs NSS build. The NSS AP will give faster Wi-Fi speeds.
I added a note to my instructions about this. Thanks for pointing it out.
I use OnHub as a router.
When I set this up and tested the internet speed on a switch-connected computer, the results are exactly what qos is applied, but when I test on a wirelessly connected smartphone, the results are full speed that qos is not covered by qos.
The settings that I have posted come from ACwifidudes instructions on his forum. I use my OnHub as a wired AP. Any Qos / SQM should be controlled by the main router not the AP.
Maybe try one of his builds to see if it acts differently. I make some small changes to my builds to suit my needs.
Hey everyone! Thank you for all your help with the OnHubs. I have three installed and they seem to be running pretty well but I have noticed on the hub that is meshed with 802.11 there are times that devices that use the 5ghz connection lose internet access. I haven't seen anything in the system log to suggest issues but in the kernal log it does seem like there may be something wrong.
This is from the mesh access point, and it is basically the same messages as the main Onhub.
[ 34.207464] debugfs: File 'virt_if' in directory 'stats' already present!
[ 34.208166] phy1-ap0: Created a NSS virtual interface
[ 35.440729] ath10k_pci 0001:01:00.0: pdev param 0 not supported by firmware
[ 35.462631] br-lan: port 4(phy1-ap0) entered blocking state
[ 35.462663] br-lan: port 4(phy1-ap0) entered disabled state
[ 35.467418] device phy1-ap0 entered promiscuous mode
[ 35.605239] IPv6: ADDRCONF(NETDEV_CHANGE): phy1-ap0: link becomes ready
[ 35.605429] br-lan: port 4(phy1-ap0) entered blocking state
[ 35.610787] br-lan: port 4(phy1-ap0) entered forwarding state
[ 35.815172] debugfs: File 'virt_if' in directory 'stats' already present!
[ 35.815525] phy1-mesh0: Created a NSS virtual interface
[ 35.824992] br-lan: port 5(phy1-mesh0) entered blocking state
[ 35.825983] br-lan: port 5(phy1-mesh0) entered disabled state
[ 35.832184] device phy1-mesh0 entered promiscuous mode
[ 35.837831] br-lan: port 5(phy1-mesh0) entered blocking state
[ 35.842645] br-lan: port 5(phy1-mesh0) entered forwarding state
[ 35.851482] br-lan: port 5(phy1-mesh0) entered disabled state
[ 36.479055] br-lan: port 4(phy1-ap0) entered disabled state
[ 39.157417] IPv6: ADDRCONF(NETDEV_CHANGE): phy1-mesh0: link becomes ready
[ 39.157684] br-lan: port 5(phy1-mesh0) entered blocking state
[ 39.163195] br-lan: port 5(phy1-mesh0) entered forwarding state
[ 39.259481] br-lan: port 4(phy1-ap0) entered blocking state
[ 39.259519] br-lan: port 4(phy1-ap0) entered forwarding state
[ 42.736132] IPv6: ADDRCONF(NETDEV_CHANGE): phy0-ap0: link becomes ready
[ 42.736297] br-lan: port 3(phy0-ap0) entered blocking state
[ 42.741624] br-lan: port 3(phy0-ap0) entered forwarding state
[ 720.637570] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 1181.835922] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 1819.673873] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 1838.793846] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[ 1860.794040] ath10k_pci 0000:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[13880.515812] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[48265.116388] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[84531.709013] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[84780.748224] ath10k_pci 0000:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[85116.746322] ath10k_pci 0001:01:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
I'm unsure where to go from here because once the device loses the connection it doesn't reestablish itself unless it is restarted or the wifi is toggled on and off. I'm assuming it may have something to do with the Transmit Queue but am unsure what to do.
The AP is meshed using the 5ghz connection as well so I am unsure if both the mesh backhaul and wifi connection may be causing interference.
If you guys have any advice I'd appreciate it!
Thanks!
I was able to recover from a bad configuration by resetting OpenWrt to the default configuration by pressing and holding the reset button for 10 seconds.
I hope the OpenWrt failsafe method bug could be fixed, as failsafe method works on other devices, and doesn't erase configurations like a reset.
Are you using sysupgrade OpenWrt firmware compiled with non-ct ath10k firmware and driver? If you're not sure, then you are probably not, and you should follow the advice to try with non-ct ath10k firmware and driver for mesh.
On 23.05, still cannot reboot to OpenWRT if there is any usb device attached.
I want to use it as a NAS.
I think if it's only a usb drive
I could imagine you could install openwrt on the drive
just like the usb stick
but i have not done this tho
Thanks!
I'm not quite sure how to build that firmware though.
Would I just take the -ct off of any instance that has it? and literally add "mesh11sd luci" at the end? Is the luci part of the mesh11sd?
Sorry, I'm trying to understand but am new to OpenWRT.
for this you can use the firmware-selector
go into " Customize installed packages and/or first boot script"
in " Installed Packages"
remove the driver you don't want and and add one you do
make sure luci is there and built is how you want
https://firmware-selector.openwrt.org/?version=23.05.2&target=ipq806x%2Fchromium&id=tplink_onhub
OnHub performs flawlessly, but the frequent boot failures when the NSS fq_codel is set are disappointing.
It crashes several times during the boot process, suffers several boot failures, and once it boots successfully, it works flawlessly after that.
This only happens when I set the NSS fq_codel startup script to eliminate bufferbloat.
Is anyone else using OnHub as a router and using NSS and fq_codel?
The build I use is here and the fq_codel script added to rc.local is below.
modprobe nss-ifb
ip link set up nssifb
# Shape ingress traffic to 450 Mbit with chained NSSFQ_CODEL
tc qdisc add dev nssifb root handle 1: nsstbl rate 450mbit burst 450kb
tc qdisc add dev nssifb parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 300 target 2.5ms interval 25ms set_default
# Shape egress traffic to 450 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 450mbit burst 450kb
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 300 target 2.5ms interval 25ms set_default
The part of the script that is causing issues is 'ip link set up nssifb'.
I've looked at the code in the relevant patches in various repositories, but from my knowledge I can't figure out which part is the problem.
Can I get a solution?
Have you tried this method to make use of the NSS cores? No need for a start up script. It is the method I use on my main router (RT4230W) and have tested it to work on the OnHubs as well.
That's right. That's what I used to do before using the rc.local script.
It worked fine with OnHub, except that it caused a reboot every time I saved settings in luci.
Rather, rickkdotnet/sqm-scripts-nss seems to show the same conflict, since it uses ip link up internally.
What firmware does your RT4230W use?
This issue occurs on kernel 5.15, and it doesn't seem like users of other devices are experiencing this issue as often.
This seems to be an issue with the onhub more often than other devices.
I use a version of ACwifidudes 23.05-snapshot that I build myself with some apps removed and others added on the RT4230W. The base NSS stuff is unchanged. I just remove the things I don't use and add what I want, namely minidlna and samba. I switched recently from the 22.03 builds, as the 23.05 matured the samba works better than it did originally.
Unfortunately, the only version available for the OnHubs is 23.05 with NSS. I never did a long test with the OnHub using it as a router. When I did try it, I did not run into any reboot issues. I run my OnHub (TP-Link) as an AP with a 23.05-snapshot NSS build and have not run into any reboot issues either. It only runs for a few hours when it is on. It is only to bring WiFi to the backyard when I'm out there listening to music.
Do you use the ct build?
My build is also a derivative of ACwifidude's work.
If you are using a non-ct build, this symptom seems to only be present on ASUS OnHub.
I use the non-ct version. It just works for me, so I haven't changed it. I use a TP-Link OnHub for my AP. I also have an ASUS flavor but haven't done much with it. Interesting that that one is giving problems, yet the TP-Link is okay.
1 Like
I have been playing around with the ASUS OnHub lately and have run into the issue that you mentioned. I am running the ct driver (23.05-snapshot) and after adjusting the speeds in luci-app-sqm using the nss-rk.qos with fqcodel the device rebooted without saving the changes. I am able to adjust settings and keep them by logging into the router and editing the config file for sqm and the change will stay. Do you get the random reboots after the sqm is set up and running or just while setting up the sqm?
1 Like