What's new

RT-AX92u - New firmware - 3.0.0.4.386_41712

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I was curious what the 'Up time' was on the computer that failed to connect, not the router. :)

But I guess if a reboot didn't help it connect, it's something else then.

2nd RMA?

Is the Control Channel on Auto?
 
That 'Auto' setting is most likely the culprit here.

Even when using manual control channels, I had to switch to a different one when moving from one Beta to another.


It may seem like a different issue to you. But to me, it is the same thing. No connection was possible on a specific control channel. When that (and only that) was changed, the network behaved as expected.
 
I faced Ethernet backhaul issue in 386. I have another 384 side by side to compare. I tried so many different setup, e.g. set Backhaul Connection Priority to WAN, swapping the cable attaching the two Aimesh nodes, factory hard reset on Aimesh nodes, etc. I cannot get it work.

The same issue happened on the one version earlier of my main Aimesh router AX88U 3.0.0.4.386_41700.

Please suggest.

2.png


1.png
 
@LeoT are all the routers on the same codebase?

If you have mixed wired and wireless backhaul, you should leave the Ethernet Backhaul Mode 'Off' and the Connection Priority to Auto.

Make the changes as noted above. Remove both nodes. Physically disconnect the wired node.

Perform the WPS reset appropriately for the model.

Add them to the network again. After 15 minutes, attach the Ethernet cable to the WAN port of the node you want in wired backhaul mode.

Reboot the system via the GUI via the AiMesh, System Settings, System Reboot button.

Consider repeating the above reboot after an hour or more (I find the network more stable afterward).

If the codebase is drastically different between the main and node AiMesh routers, the above may not have the expected effect.
 
as the screen shown above, the strange thing is.... the same codebase does not work as expected.
386 -> 386 Ethernet Backhaul does not work
386 -> 384 Ethernet Backhaul work

I tried so many times on hard reset, reboot before or after, re-setup, swapping, Pure Ethernet Backhaul Mode in System Settings

The only thing I did not try is to wait 15 min or 1 hr...

Consider repeating the above reboot after an hour or more (I find the network more stable afterward).
I think it is quite right. I found my dual WAN were both down often in the first setup hour...
 
@LeoT, sorry, but I don't think I would have ever got that from the screen snips you posted above. :)

If you're just resetting the nodes, that could be the issue too.

Unless others have any input, all I can suggest is to start from the beginning on all the routers. The following link may help.

Best Practice Update/Setup Router/AiMesh Node(s) 2021
 
Just a quick update. This firmware has been working perfectly and has been running for 12 days without any reboots or crashes.

I gave up with WiFi calling and decided to buy a separate femtocell which has solved my poor signal issues.

The WiFi calling issues I was having (intermittent calls diverted to voicemail) could be Android doze mode causing the connection to be closed. Therefore, the problem is probably not fixable if you want an android device that uses modern power saving techniques.
 
Last edited:
as the screen shown above, the strange thing is.... the same codebase does not work as expected.
386 -> 386 Ethernet Backhaul does not work
386 -> 384 Ethernet Backhaul work

The Ethernet Backhaul issue is fixed with ax92u 9.0.0.4.386_41994

ax88u 9.0.0.4.386_41994 -> ax92u 9.0.0.4.386_41994 - Ethernet backhaul work
ax88u 9.0.0.4.386_41994 -> ax92u 3.0.0.4.384_6437 - Ethernet backhaul work
ax88u 9.0.0.4.386_41994 -> ax92u 3.0.0.4.386_41712 - Ethernet backhaul does not work
ax88u 3.0.0.4.386.41700 -> ax92u 3.0.0.4.386_41712 - Ethernet backhaul does not work
 
I had nothing but problems with this firmware (386.41712). Just like dpw2atox, it would be working fine, then randomly start disconnecting clients and they wouldn't be able to reconnect. I downgraded to 384 and it is much more stable, although I still get the odd disconnection every now and then.

It's a pity that good harware is being spoiled by poor firmware.
 
I've been on this firmware version for a while and I've been experiencing random reboots around 3 to 4 times a day. I am currently troubleshooting the issue using a process of elimination. I've turned off all the services I can (All WiFi radios, IPV6 Firewall, etc.)

I noticed that no matter how many services I turn off via the AX92U's management UI, the memory consumption at bootup remains the same ~(467mb used, 45mb free). I am starting to wonder if these services are still running despite being disabled? If my hunch is correct, is there a way to remove these services and free up memory?

Second thing I noticed is that there is no way to turn off AIMesh from the UI. Can anyone advise how to turn it off as I don't use it right now.

Thanks!
 
I had nothing but problems with this firmware (386.41712). Just like dpw2atox, it would be working fine, then randomly start disconnecting clients and they wouldn't be able to reconnect. I downgraded to 384 and it is much more stable, although I still get the odd disconnection every now and then.

It's a pity that good harware is being spoiled by poor firmware.
May I ask where I can download and try older firmware like the 384 you mentioned? Thanks!
 
When I enable SSH and connect, I can run `ps` and get back a pretty comprehensive process list, including some names that I'm almost certain are core routing features, and they all show up as running under my current login's UID. (Maybe there's just no privilege system? There's no `su` in this busybox, at least.) Anyway you might be able to check if there are new processes in the list when you enable/disable certain services, and you should also be able to see the memory usage with `top`.
 
I'd just like to add that the 384 firmware is slower than 386. When I was on it, web pages took longer to load, a delay of a few seconds was perceivable. As before, I'd definitely advise people to do a complete hardware reset if they are having problems with the latest firmware. A dirty upgrade on the AX92u is going to cause problems as there's been a lot of bad firmware on this router in the past.

I still use this version of the firmware today and it is working perfectly with wireless backhaul. Clients have been given access to the AX channel and the mesh automatically shifts those clients on to the AX band. Throughput is the full 1gbps over WiFi.
 
Thanks for all the replies! I have another question. Do Asus routers have an internal temperature sensor, or does the CPU have one that I can monitor via the command line or via some other utility? I didn't see any SNMP options on the AX92U.
 
Found a solution to my AX92U reboot issues...install fans!
I installed 2 5cmx5cm USB powered box fans on top of the unit and stability has gone up dramatically.
Where before I'd get 4-6 reboots per day, now its like 1-2 per week!

Best use of the USB ports on a router I've found so far hahaha!
 
Found a solution to my AX92U reboot issues...install fans!
I installed 2 5cmx5cm USB powered box fans on top of the unit and stability has gone up dramatically.
Where before I'd get 4-6 reboots per day, now its like 1-2 per week!

Best use of the USB ports on a router I've found so far hahaha!
You have broken router.....4-6 reboots per day without fan ??? , 1-2 reboots per week with fan ??? LOL
The manufacturer did not include a fan, so it is supposed to work without a fan. Report it to the RMA because it is damaged.
 
You have broken router.....4-6 reboots per day without fan ??? , 1-2 reboots per week with fan ??? LOL
The manufacturer did not include a fan, so it is supposed to work without a fan. Report it to the RMA because it is damaged.
Everybody had this problem. It was caused by a bad firmware release.

The fix is to update the firmware but more importantly, you have to perform a hard reset using the WPS button method.

Once you do this, the reboots will stop.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top