Release RT-AX92U Version 3.0.0.4.386.43084 released 6/3/21

[TXbreees]

That kind of worries me. My back haul connects at 2.5g and we get a lot of users copying huge files over the LAN. STA's connect between 1.7b- 2.5g

What's the RSSI of your back haul? Mine is around-55db

I only have the one router. This is connection speed from router to my desktop. RSSI is -44 DBM

 

[wesselkoning]

Seems stable now after 1 week. Had to manually reset the nodes. Dirty upgrade via app did not work out great. I now have an uptime of 8 days 50+ devices and without any issues.

 

[leerees]

I only have the one router. This is connection speed from router to my desktop. RSSI is -44 DBM

That is a really good figure. Is there a lot of interference from other AP's?

 

[wesselkoning]

well, not so stable as I thought. When I woke up this morning, I had WiFi connection, but no internet. Had to restart all nodes again... Sigh

 

[TXbreees]

That is a really good figure. Is there a lot of interference from other AP's?

Nope. I'm in a suburban area with fairly large lots so my direct neighbors are the only other ones showing up.

 

[TXbreees]

The day after an automated scheduled reboot:

Then after a manual reboot:

 

[John Kr Skjervik]

My 92U still has "fatal error" in system log every day, so I'm not happy with the latest firmware (084). Has performed hard reset. I see no improvements in signal strength or speed. I run my router as access point (AP) and 5Ghz-1 is disconnected, thats means I run only 2.4Ghz and 5Ghz-2

 

[John Kr Skjervik]

I have to go back to my older ASUS RT-AC86U with Marlin firmware.

 

[Techtype]

Follow up report: 5 days with this firmware, no errors in log, no other problems, processor use normal. (2 AX92Us in mesh with wired backhaul, using 5-2 band for client connections)

 

[John Kr Skjervik]

Last chance / attempt

Manually downloaded new firmware (3.0.0.4.386_43084) file and installed it. Performed a hard reset and reconfigured the router. Changed to AP mode so that it gets IP address from my network provider's fiber exchange. It did not take many hours before I get "fatal error" - Jun 21 15:59:23 kernel: wl0: fatal error, reinitializing, total count of reinit's [2]. I get this error 2-three times every day. Can anyone explain this? I have approx. 10 clients on wifi that is mobile phones, various hubs and laptops. Thank you.

 

[Techtype]

Last chance / attempt

Manually downloaded new firmware (3.0.0.4.386_43084) file and installed it. Performed a hard reset and reconfigured the router. Changed to AP mode so that it gets IP address from my network provider's fiber exchange. It did not take many hours before I get "fatal error" - Jun 21 15:59:23 kernel: wl0: fatal error, reinitializing, total count of reinit's [2]. I get this error 2-three times every day. Can anyone explain this? I have approx. 10 clients on wifi that is mobile phones, various hubs and laptops. Thank you.

This might be a bad 2.4 radio. But, it might also be something peculiar interfering on the 2.4 band. You might try setting the 2.4 band to 20 MHz only and then starting with channel 1, try forcing each of the channels all the way to 11 (Include every channel in your test 2, 4, 5, 7,etc as well as the usual suspects) Since your error occurs reliably and frequently, it should not take long to test all the channels.

 

[John Kr Skjervik]

Thanks ... will try, 20Mhz and start with channel 1, going to channel 2 after 24 hours.

test ch1: - Fatal error after few hours
Test ch2:

 

[bbunge]

Thanks ... will try, 20Mhz and start with channel 1, going to channel 2 after 24 hours.

test ch1: - Fatal error after few hours
Test ch2:

I would not check all of the 2.4 GHz channels. Just 1, 6 and 11 as those are the ones you should use at 20 MHz. Make sure your WIFI bands are set to fixed channel and bandwidth. Avoid DFS channels for 5 GHz if possible.

If you are getting errors in the log and your clients are happy with no apparent problems just ignore the log.

 

[John Kr Skjervik]

Thanks ... ok, i will try
test nr 1, Channel 1 - wl0: fatal error, reinitializing, total count of reinit's
test nr 2, Channel 6 - Jun 23 20:34:20 kernel: wl0: fatal error, reinitializing, total count of reinit's[1]
test nr 3, Channel 11 - Jun 24 17:10:35 kernel: wl0: fatal error, reinitializing, total count of reinit's[2]

 

[John Kr Skjervik]

Then the test is completed, result above ... What do I do next?

 

[John Kr Skjervik]

Hello. Is there anyone who can interpret / explain clippings from system log?


System log;


Jul 13 21:05:06 wlceventd: wlceventd_proc_event(556): eth5: Assoc 70:EE:50:1C:86:50, status: Successful (0), rssi:-45

Jul 13 21:05:12 kernel: wl0: random key value: 13E8E9C68DF0D2DA0FCF037DBF00BA1E0D9077E6C4A104E6956F1D5B37769DE4
Jul 13 21:05:12 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 13 21:05:12 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 13 21:07:29 kernel: wl0: PSM microcode watchdog fired at 776668 (seconds). Resetting.
Jul 13 21:07:29 kernel: wl0: reason = psm watchdog at 776668 seconds. corerev 42 ucode revision 1570.159 features 0x0426
Jul 13 21:07:29 kernel: psmdebug 0x00ff8014 phydebug 0x0 macctl 0x84160403 maccmd 0x4
Jul 13 21:07:29 kernel: psm_brc 0x0000 psm_brc_1 0x0000 M_UCODE_DBGST 0x2
Jul 13 21:07:29 kernel: brwk_0 0x0094 brwk_1 0x0000 brwk_2 0x0030 brwk_3 0x7121 brwk_4 0x0000
Jul 13 21:07:29 kernel: ifsstat 0x1ea0 ifsstat1 0xf0 txectl 0x4992 txestat 0x421
Jul 13 21:07:29 kernel: rxestat1 0x7000 rxestat2 0xc0 rcv_frmcnt 0x0 rxe_rxcnt 0x50
Jul 13 21:07:29 kernel: wepctl 0x50
Jul 13 21:07:29 kernel: aqmfifordy 0x0 wepstat 0x0 wep_ivloc 0x1e wep_psdulen 0x4a
Jul 13 21:07:29 kernel: PC :
Jul 13 21:07:29 kernel: R0: 0xff802f 0xc98009 0xec9442 0xff80dd
Jul 13 21:07:29 kernel: R0: 0xff80cf 0xff801a 0xff8002 0xfe80e6
Jul 13 21:07:29 kernel: R0: 0xff98eb 0xff80cc 0xff8016 0xc98224
Jul 13 21:07:29 kernel: R0: 0xff80c9 0xc98017 0xec8224 0xff9393
Jul 13 21:07:29 kernel: R0: 0xff8002 0xfe80e6 0xff98ea 0xff80cb
Jul 13 21:07:29 kernel: R0: 0xfe8017 0xfe8224 0xec80e6 0xfe98e3
Jul 13 21:07:29 kernel: R0: 0xff80ec 0xc99472 0xff80cd 0xc98017
Jul 13 21:07:29 kernel: R0: 0xc8801c 0xc98009 0xfe9442 0xc980de
Jul 13 21:07:29 kernel: R0: 0xc980e3 0xff80d6 0xc98030 0xec8009
Jul 13 21:07:29 kernel: R0: 0xff8014 0xff8014 0xff8014 0xff8014
Jul 13 21:07:29 kernel: R0: 0xff8014 0xff8014 0xfe801c 0xff8014
Jul 13 21:07:29 kernel: R0: 0xff8014 0xff8014 0xff8014 0xff8014
Jul 13 21:07:29 kernel: R0: 0xff8014 0xff8014 0xff8014 0xff8014
Jul 13 21:07:29 kernel: R0: 0xff8014 0xff8014 0xff8014 0xff8014
Jul 13 21:07:29 kernel: R0: 0xff8014 0xff8014 0xff80c5 0xff8016
Jul 13 21:07:29 kernel: R0: 0xff8014 0xff8014 0xff8014 0xff8014
Jul 13 21:07:29 kernel: psm stack_status : 0x10
Jul 13 21:07:29 kernel: psm stack_entries:
Jul 13 21:07:29 kernel: 0x00e6
Jul 13 21:07:29 kernel: 0x1472
Jul 13 21:07:29 kernel: 0x11d5
Jul 13 21:07:29 kernel: 0x10e8
Jul 13 21:07:29 kernel: 0x1ba4
Jul 13 21:07:29 kernel: 0x1bbe
Jul 13 21:07:29 kernel: 0x1de7
Jul 13 21:07:29 kernel: 0x1bf0
Jul 13 21:07:29 kernel: wl0: fatal error, reinitializing, total count of reinit's[3]
Jul 13 21:15:11 wlceventd: wlceventd_proc_event(527): eth5: Auth 70:EE:50:1C:86:50, status: Successful (0), rssi:0
Jul 13 21:15:11 wlceventd: wlceventd_proc_event(556): eth5: Assoc 70:EE:50:1C:86:50, status: Successful (0), rssi:-45
Jul 13 21:15:17 kernel: wl0: random key value: 4A4A3C338C597054670200338AE4AFA588D2C1588383036FA4A6594776543B3C
Jul 13 21:15:17 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 13 21:15:17 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 13 21:25:16 wlceventd: wlceventd_proc_event(527): eth5: Auth 70:EE:50:1C:86:50, status: Successful (0), rssi:0
Jul 13 21:25:16 wlceventd: wlceventd_proc_event(556): eth5: Assoc 70:EE:50:1C:86:50, status: Successful (0), rssi:-45
Jul 13 21:25:22 kernel: wl0: random key value: CEC810FA467BB8F337A301516E453F36106DD31FA2090E5D74D15B82692F0528
Jul 13 21:25:22 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 13 21:25:22 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

 

[leerees]

I have been running Firmware Version:3.0.0.4.386_41712 for months. It's rock solid stable and very fast. Might be an idea to try that first. Having been burnt in the past, I always stay one firmware release behind.

Jul 13 21:07:29 kernel: wl0: PSM microcode watchdog fired at 776668 (seconds). Resetting.

This is related to WL0. At a guess, you have a client on your network that's misbehaving and causing the radio to shut down. Try updating all the drivers on your devices, especially on intel laptops. If that doesn't work you'll have to try and find the culprit through the process of elimination. It might be worth sending this to Asus support, they may work on a patch to protect our AX92u's in the future.

Jul 13 21:25:22 kernel: wl0: random key value:

This is just chatter, ignore it

70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

This is normal, it's just devices roaming between nodes.

The rest of it is either normal or related to the watchdog firing.

 

[empiretc]

I have been running Firmware Version:3.0.0.4.386_41712 for months. It's rock solid stable and very fast. Might be an idea to try that first. Having been burnt in the past, I always stay one firmware release behind.

Jul 13 21:07:29 kernel: wl0: PSM microcode watchdog fired at 776668 (seconds). Resetting.

This is related to WL0. At a guess, you have a client on your network that's misbehaving and causing the radio to shut down. Try updating all the drivers on your devices, especially on intel laptops. If that doesn't work you'll have to try and find the culprit through the process of elimination. It might be worth sending this to Asus support, they may work on a patch to protect our AX92u's in the future.

Jul 13 21:25:22 kernel: wl0: random key value:

This is just chatter, ignore it

70:EE:50:1C:86:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

This is normal, it's just devices roaming between nodes.

The rest of it is either normal or related to the watchdog firing.

Has 41712 been stable for you? Been running 43084 (the latest) and this router will lose the internet connection at random times. A simple reboot fixes it, but this is a problem if we are working remotely. We have scheduled daily reboots, but this has only helped a little as it can lose the connection at any time.

We do not lose WiFi or any connection to the router, it just loses its connection to the WAN. We have contacted Asus about it multiple times, but they have been no help.

We are wondering if we should downgrade to 41712 if it is more stable. Do you have any issues losing internet connection on 41712?

Thanks

 

[leerees]

Has 41712 been stable for you? Been running 43084 (the latest) and this router will lose the internet connection at random times. A simple reboot fixes it, but this is a problem if we are working remotely. We have scheduled daily reboots, but this has only helped a little as it can lose the connection at any time.

We do not lose WiFi or any connection to the router, it just loses its connection to the WAN. We have contacted Asus about it multiple times, but they have been no help.

We are wondering if we should downgrade to 41712 if it is more stable. Do you have any issues losing internet connection on 41712?

Thanks

41712 has been rock solid with no issues. I've been getting 900 mb/s over AX.

Your Internet connectivity problem sounds like a known DHCP issue with some Asus router / isp combinations. I beleive there is a fix although can't remember the steps, it was something to do with continous scanning?

 

[empiretc]

41712 has been rock solid with no issues. I've been getting 900 mb/s over AX.

Your Internet connectivity problem sounds like a known DHCP issue with some Asus router / isp combinations. I beleive there is a fix although can't remember the steps, it was something to do with continous scanning?

thanks for that.

recently enabled ipv6 and also installed the phone app and it enabled WAN access and https authentication. this was all done on Monday- the last time we lost internet. It is Thursday now and we haven't lost internet since. Fingers crossed.

We are going to give it a few more days, but if the problem persist, we will have to give 41712 a shot. Will update as it seems many others are experiencing this problem.