What's new

Release Asus RT-AX92U - New Firmware: 3.0.0.4.386_45898

  • 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!

mabela91

New Around Here
Firmware version 3.0.0.4.386_45898
- Release Note -

This version includes several vulnerability patches.
BusyBox
- CVE-2016-2148
- CVE-2016-6301
- CVE-2018-1000517

cURL
- CVE-2020-8169
- CVE-2019-5481
- CVE-2019-5482
- CVE-2018-1000120
- CVE-2018- 1000300
- CVE-2018-16839

Lighttpd
- CVE-2018-19052

Linux
- CVE-2020-14305
- CVE-2020-25643
- CVE-2019-19052

lldpd
- CVE-2020-27827

Avahi
- CVE-2017-6519

hostapd
- CVE-2021-30004
- CVE-2019-16275

OpenVPN
- CVE-2020-11810
- CVE-2020-15078

wpa
- CVE-2021-30004
- CVE-2021-27803
- CVE-2019-11555
- CVE-2019-9499
- CVE-2019-9498
- CVE-2019-9497
- CVE-2019-9496
- CVE-2019-9495
- CVE-2019-9494
- CVE-2017-13086
- CVE-2017-13084
- CVE-2017-13082
- CVE-2016-4476
- CVE-2015-8041

Bug Fixes and Enhancements:
- Fixed DoS vulnerability from spoofed sae authentication frame.
Thanks to Efstratios Chatzoglou, University of the Aegean,
Georgios Kambourakis, European Commission at the European Joint Research Centre,
and Constantinos Kolias, University of Idaho.
- Fixed envrams exposed issue.
Thanks to Quentin Kaiser from IoT Inspector Research Lab contribution.
- Fixed AiMesh web page multi-language issues.
- Fixed Stored XSS vulnerability.
- Fixed CVE-2021-41435, CVE-2021-41436.
Thanks to Efstratios Chatzoglou, University of the Aegean
Georgios Kambourakis, European Commission at the European Joint Research Centre
Constantinos Kolias, University of Idaho.
- Fixed Stack overflow vulnerability.
Thanks to Jixing Wang (@chamd5) contribution.
- Fixed information disclosure vulnerability.
Thanks to CataLpa from DBappSecurity Co.,Ltd Hatlab and 360 Alpha Lab contribution.
 
The 5G guest network (in isolated mode) on the aimesh node doesn't work with this firmware with my setup. I had the same problem with 44695. Reverting back to 43084 fixes the issue.

My main router is a AX88U, it's running the latest firmware (45898) without any issues, the problem is only when I upgrade the AX92U mesh node. I may try a full reset and adding the mesh node back in but the behaviour seems to be something in the newer firmware as devices try to connect to the node but get thrown off and can only connect to the main router. Trying to force them to bind just causes it to show a warning saying the signal isn't strong enough, even when the device is right next to the mesh node.

I'd be interested in anyone else who has managed to get the guest network working with this firmware.
 
The 5G guest network (in isolated mode) on the aimesh node doesn't work with this firmware with my setup. I had the same problem with 44695. Reverting back to 43084 fixes the issue.

My main router is a AX88U, it's running the latest firmware (45898) without any issues, the problem is only when I upgrade the AX92U mesh node. I may try a full reset and adding the mesh node back in but the behaviour seems to be something in the newer firmware as devices try to connect to the node but get thrown off and can only connect to the main router. Trying to force them to bind just causes it to show a warning saying the signal isn't strong enough, even when the device is right next to the mesh node.

I'd be interested in anyone else who has managed to get the guest network working with this firmware.

Is it the same issue described in this thread?

 
Back to this if you're using a raspberry pi. Based on this and the AImesh feedback above it sounds like this firmware version is a branch off of something before 3.0.0.4.386.44695

Screenshot 2021-10-08 074143.png
 
I installed it this morning. No problem detected. I only have an AX92U router. I haven't tested the mesh.
 
Is it the same issue described in this thread?

It could be although what I'm seeing is seems slightly different. In that thread clients are connecting to the mesh node but are unable to receive an IP via DHCP. In my case devices try to connect to the mesh node but are automatically dropped and connect to the main router instead. When I view the AiMesh page it shows that no guest clients are connected to the node, they are all on the main router.
I suppose it could be that the clients are falling back to the main router when they fail to receive an IP address, but I'd need to do more testing with more devices to see if that's the case.
 
Unfortunately new version of firmware removes DNS Filter tab in LAN (Advanced settings). I was so happy to have it :(:mad:.
 
I've an RT-AX92U mesh (no other routers) and noticed a subtle change, and possibly worth starting a new thread(?)

Occurrences of "kernel: XX:XX:XX:XX:XX:XX not mesh client, can't update it's ip"

Seems to have changed, after this firmware update, to

Occurrences of "kernel: XX:XX:XX:XX:XX:XX not mesh client, can't delete it"

Devices connected via 5Ghz-1 or wired to a node (in my case an iMac and a Smart TV) loose connection to the network when this message hits the log, coming back in about 5 mins or with a device reboot.

Anyone else had this, or know how to fix it?
 
Unfortunately new version of firmware removes DNS Filter tab in LAN (Advanced settings). I was so happy to have it :(:mad:.
RMerlin mentioned in another firmware thread that it wasn’t finished and should be coming back later, if I recall correctly.
 
I am being assigned an IP from the guest network. Since the intranet access is deactivated for the guest network, the router uses a different ip area. But I cannot access the internet from here either.

OK.
Complement.
The assignment of the IP only works if the connection is established while the guest network is being activated or changes are being saved.
 
Last edited:
I've an RT-AX92U mesh (no other routers) and noticed a subtle change, and possibly worth starting a new thread(?)

Occurrences of "kernel: XX:XX:XX:XX:XX:XX not mesh client, can't update it's ip"

Seems to have changed, after this firmware update, to

Occurrences of "kernel: XX:XX:XX:XX:XX:XX not mesh client, can't delete it"

Devices connected via 5Ghz-1 or wired to a node (in my case an iMac and a Smart TV) loose connection to the network when this message hits the log, coming back in about 5 mins or with a device reboot.

Anyone else had this, or know how to fix it?

I am seeing this same problem on 2.4G and 5G networks. It does not appear to be all devices, but the set of devices having the problem is consistent across reboots of both the routers and the gadgets (an HP laptop and a smart TV). In my case, the devices won't come back; they report "unable to connect".

In the cases I have seen so far, this error message is preceded by two identical "Deauth_ind" messages and a single "Disassoc" message for the MAC address in question. So maybe something is being doubly freed?

I am going to have to downgrade the mesh, I'm afraid, because the laptop is my work machine.
 
Welcome to the forums @AndyB21.

Before downgrading, have you tried using a new SSID (8 alphanumeric characters only, no spaces, no punctuation, no smiley faces), and/or 'forgetting' and re-associating with the problem devices?
 
Welcome to the forums @AndyB21.

Before downgrading, have you tried using a new SSID (8 alphanumeric characters only, no spaces, no punctuation, no smiley faces), and/or 'forgetting' and re-associating with the problem devices?

All of my SSIDs comply with the length (<= 32 octets) restrictions of the protocol. They are also composed of printable, non-blank ASCII characters (required by convention, if not by standard). I did try forgetting the network on the laptop; that did not help.

I should point out that after a reboot of the router, the stations succeed in connecting; after a brief but variable period of time, they drop off with the error message mentioned. This was observed across both a soft and a hard reboot, since it is occasionally the case that a soft reboot fails to clear some component state.

Finally, I successfully downgraded to the June release (3.0.0.4_386_43084) that I had been running; these problems disappeared. I plan to submit a problem report to the vendor; I will hold off on upgrading until either (a) ASUS releases a fix or (b) they point me to a viable workaround or configuration change that will alleviate the problem.
 
Used this version of firmware for about a week and have met once the WAN gone down suddenly with red LED. Seems the WAN issue that bother me seems not fixed.
 
Used this version of firmware for about a week and have met once the WAN gone down suddenly with red LED. Seems the WAN issue that bother me seems not fixed.

Dealt with this issue since getting this router in May. Have posted here quite a bit about it, and nothing ever seemed to fix the issue.

Finally, ran across a post by MartineauUK. Installed the Chk-WAN script on this router, and now everything is perfect. If the WAN goes down, the script detects it and resets the WAN or reboots the router as necessary.

The last time we experienced a WAN outage, it took about 4 minutes for everything to come back online. This script is a life saver when working remotely.

It is unfortunate that Asus still has not addressed this as this is an expensive router. The EA8300 that the RT-AX92U replaced never experienced this issue.
 
All of my SSIDs comply with the length (<= 32 octets) restrictions of the protocol. They are also composed of printable, non-blank ASCII characters (required by convention, if not by standard). I did try forgetting the network on the laptop; that did not help.

I should point out that after a reboot of the router, the stations succeed in connecting; after a brief but variable period of time, they drop off with the error message mentioned. This was observed across both a soft and a hard reboot, since it is occasionally the case that a soft reboot fails to clear some component state.

Finally, I successfully downgraded to the June release (3.0.0.4_386_43084) that I had been running; these problems disappeared. I plan to submit a problem report to the vendor; I will hold off on upgrading until either (a) ASUS releases a fix or (b) they point me to a viable workaround or configuration change that will alleviate the problem.
I've also submitted a report in relation to guest networks for 45898 on the RT-AX92U via the feedback form. I tried upgrading again, this time factory reset the mesh node, re-added it in and re-configured the guest networks, but still have the same problem. I've discovered though that it's only the 5Ghz guest network that devices can't connect to, they were able to connect to the 2.4Ghz guest network on the mesh node. Had the same problem with the 44695 firmware. Reverting to 43084 fixes the issue with no other changes required.

I notice in 44695 there's a comment in the release notes about 'Fix 5Ghz WiFi abnormal issue', while it may be unrelated it seems odd that this is when the problem with the 5Ghz guest network started.
 
Dealt with this issue since getting this router in May. Have posted here quite a bit about it, and nothing ever seemed to fix the issue.

Finally, ran across a post by MartineauUK. Installed the Chk-WAN script on this router, and now everything is perfect. If the WAN goes down, the script detects it and resets the WAN or reboots the router as necessary.

The last time we experienced a WAN outage, it took about 4 minutes for everything to come back online. This script is a life saver when working remotely.

It is unfortunate that Asus still has not addressed this as this is an expensive router. The EA8300 that the RT-AX92U replaced never experienced this issue.
Got a link to that script?

*Edit*

Funny... a second after posting this message, I found it.
 

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