What's new

AX92U - slow internet speedtest after upgrade to 3.0.0.4.386_41535-g1caa24a firmware

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

Last edited:
I am now 26 hours after the update - so far seems ok.
No visible crashes in the log files and Wifi is fast.
I'm on a 2 x AX92u set that are connected via Ethernet backhaul cable.

Hoping it stays that way...
 
I am now 26 hours after the update - so far seems ok.
No visible crashes in the log files and Wifi is fast.
I'm on a 2 x AX92u set that are connected via Ethernet backhaul cable.

Hoping it stays that way...
Is yours setup in AiMesh or AP?

I have a buddy setup in AiMesh, but his main router is an AX88U and 2 AX92U nodes. All have the latest Asus stock 386 firmware (41700 and 41712 respectively). It's stable.
 
Is yours setup in AiMesh or AP?

I have a buddy setup in AiMesh, but his main router is an AX88U and 2 AX92U nodes. All have the latest Asus stock 386 firmware (41700 and 41712 respectively). It's stable.

What's his uptime?
 
Can you tell me where to set guest network to be able to run on Nodes?
I'm not entirely certain -- maybe when you set up guest network, set the "SYNC to AIMesh Node" to "All" instead of just "ROUTER ONLY". If your connecting to the node and do a lan scan and you can't access other network clients, the guest network is working OK. If you can access other network clients, the node is not isolating.

I did try the Guest Network option in AP mode, and it doesn't isolate. I tried the "SYNC TO AIMesh Node" in both "ALL" and "Router Only". And neither option worked. So, maybe the update to Guest Network Mode only applies in AI Mesh mode.

If others can verify, I'd appreciate it. This may finally be an incentive for me to move to AI Mesh -- if it's stable and the guest network can isolate on the nodes.
 
Last edited:
What's his uptime?

This is what my friend said:

Uptime has been 2 Days, 16hrs and 7 minutes.

Downloaded the syslog, did searches for "crash0 and "panic", none found. See a lot of deauth , disassociates, reauths, and reassociates as I move around the mesh nodes.
 
This is what my friend said:

Uptime has been 2 Days, 16hrs and 7 minutes.

Downloaded the syslog, did searches for "crash0 and "panic", none found. See a lot of deauth , disassociates, reauths, and reassociates as I move around the mesh nodes.
2 days and 16 hours is definitely on the right path (the older firmware generally crashed upto 2 days).

Can anybody top these numbers?
 
2 days and 16 hours is definitely on the right path (the older firmware generally crashed upto 2 days).

Can anybody top these numbers?

I've been up on the new firmware for 1 day 7 hours (Router and AP) - no crashes - but the watchdog got fired, yesterday evening. It didn't lead to a crash but it did generate an error in the system log.
 
I've been up on the new firmware for 1 day 7 hours (Router and AP) - no crashes - but the watchdog got fired, yesterday evening. It didn't lead to a crash but it did generate an error in the system log.
Any chance you can share your log for the last day, including the watchdog event.
 
Any chance you can share your log for the last day, including the watchdog event.

Here's an edited log leading up to and through the event -- It didn't cause a crash -- no crash log or reset of router.


Jan 26 17:49:31 wlceventd: wlceventd_proc_event(490): eth7: Deauth_ind
Jan 26 17:49:31 wlceventd: wlceventd_proc_event(490): eth7: Deauth_ind
Jan 26 17:49:31 wlceventd: wlceventd_proc_event(490): eth7: Deauth_ind
Jan 26 17:49:32 wlceventd: wlceventd_proc_event(490): eth7: Deauth_ind
Jan 26 17:50:23 wlceventd: wlceventd_proc_event(526): wl1.2: Auth [Redacted], status: Successful (0),
Jan 26 17:50:23 wlceventd: wlceventd_proc_event(555): wl1.2: Assoc [Redacted], status: Successful (0),
Jan 26 17:50:25 kernel: [Redacted] not mesh client, can't update it's ip
Jan 26 17:50:53 kernel: wl1: PSM microcode watchdog fired at 40303 (seconds). Resetting.
Jan 26 17:50:53 kernel: wl1: reason = psm watchdog at 40303 seconds. corerev 42 ucode
Jan 26 17:50:53 kernel: psmdebug phydebug
Jan 26 17:50:53 kernel: psm_brc psm_brc_1 M_UCODE_
Jan 26 17:50:53 kernel: brwk_ brwk_1
Jan 26 17:50:53 kernel: ifsstat
Jan 26 17:50:53 kernel: rxestat1
Jan 26 17:50:53 kernel: wepctl
Jan 26 17:50:53 kernel: aqmfifordy
Jan 26 17:50:53 kernel: PC :
Jan 26 17:50:53 kernel: R0:
Jan 26 17:50:53 kernel: R0:
Jan 26 17:50:53 kernel: phydebug :
Jan 26 17:50:53 kernel: 0x8
Jan 26 17:50:53 kernel: 0x8
Jan 26 17:50:53 kernel: 0x8
Jan 26 17:50:53 kernel: 0x39
Jan 26 17:50:53 kernel: 0x39
Jan 26 17:50:53 kernel: pktproc
Jan 26 17:50:53 kernel: psm stack_status :
Jan 26 17:50:53 kernel: psm stack_entries:
Jan 26 17:50:53 kernel: 0x0d5e
Jan 26 17:50:53 kernel: 0x1ddd
Jan 26 17:50:53 kernel: wl1: fatal error, reinitializing, total count of reinit's[1]
Jan 26 17:50:53 kernel: wl1: PSM microcode watchdog fired at 40303 (seconds). Resetting.
Jan 26 17:50:53 kernel: wl1: reason = psm watchdog at 40303 seconds. corerev 42 ucode revision
Jan 26 17:50:53 kernel: psmdebug phydebug macctl
Jan 26 17:50:53 kernel: psm_brc
Jan 26 17:50:53 kernel: brwk_
Jan 26 17:50:53 kernel: ifsstat
Jan 26 17:50:53 kernel: rxestat1
Jan 26 17:50:53 kernel: wepctl
Jan 26 17:50:53 kernel: PC :
Jan 26 17:50:53 kernel: R0:
Jan 26 17:50:53 kernel: phydebug :
Jan 26 17:50:53 kernel: 0x8
Jan 26 17:50:53 kernel: 0x39
Jan 26 17:50:53 kernel: 0x8
Jan 26 17:50:53 kernel: 0x39
Jan 26 17:50:53 kernel: pktproc
Jan 26 17:50:53 kernel: psm stack_status :
Jan 26 17:50:53 kernel: psm stack_entries:
Jan 26 17:50:53 kernel: 0x0d5e
Jan 26 17:50:53 kernel: wl1: fatal error, reinitializing, total count of reinit's[2]
Jan 26 17:50:53 kernel: wl1: PSM microcode watchdog fired at 40304 (seconds). Resetting.
Jan 26 17:50:53 kernel: wl1: reason = psm watchdog at 40304 seconds. corerev 42 ucode
Jan 26 17:50:53 kernel: wl1: fatal error, reinitializing, total count of reinit's[3]
Jan 26 17:51:01 watchdog: wl reinit count 10
Jan 26 17:51:01 watchdog: reinit of unit0:0
Jan 26 17:51:01 watchdog: reinit of unit1:3
Jan 26 17:51:01 watchdog: reinit of unit2:7
Jan 26 17:51:01 watchdog: reinit of unit3:0
Jan 26 17:51:01 watchdog: reinit of unit4:0
Jan 26 17:51:01 watchdog: reinit of unit5:0
Jan 26 17:51:01 watchdog: reinit of unit6:0
Jan 26 17:51:01 watchdog: reinit of unit7:0
Jan 26 17:51:01 watchdog: reinit of unit8:0
Jan 26 17:51:01 watchdog: reinit of unit9:0
Jan 26 17:51:01 watchdog: reinit of unit10:0
Jan 26 17:51:01 watchdog: reinit of unit11:0
Jan 26 17:51:01 watchdog: reinit of unit12:0
Jan 26 17:51:01 watchdog: reinit of unit13:0
Jan 26 17:51:01 watchdog: reinit of unit14:0
Jan 26 17:51:01 watchdog: reinit of unit15:0
Jan 26 17:51:01 watchdog: reinit of unit16:0
Jan 26 17:51:01 watchdog: reinit of unit17:0
Jan 26 17:51:01 watchdog: reinit of unit18:0
Jan 26 17:51:01 watchdog: reinit of unit19:0
Jan 26 17:51:01 watchdog: reinit of unit20:0
Jan 26 17:51:01 watchdog: reinit of unit21:0
Jan 26 17:51:01 watchdog: reinit of unit22:0
Jan 26 17:51:01 watchdog: reinit of unit23:0
Jan 26 17:51:01 watchdog: reinit of unit24:0
Jan 26 17:51:01 watchdog: reinit of unit25:0
Jan 26 17:51:01 watchdog: reinit of unit26:0
Jan 26 17:51:01 watchdog: reinit of unit27:0
Jan 26 17:51:01 watchdog: reinit of unit28:0
Jan 26 17:51:01 watchdog: reinit of unit29:0
Jan 26 17:51:01 watchdog: reinit of unit30:0
Jan 26 17:51:01 watchdog: reinit of unit31:0
Jan 26 17:51:50 wlceventd: wlceventd_proc_event(490): eth7: Deauth_ind [Redacted], status: 0, reason:
Jan 26 17:51:53 kernel: [Redacted] not mesh client, can't update it's ip
Jan 26 17:53:12 kernel: wl1: random key value: [Redacted]
Jan 26 17:53:12 wlceventd: wlceventd_proc_event(490): wl1.2: Deauth_ind [Redacted], status: 0, reason
Jan 26 17:53:37 wlceventd: wlceventd_proc_event(526): wl1.2: Auth [Redacted], status: Successful (0),
Jan 26 17:53:37 wlceventd: wlceventd_proc_event(555): wl1.2: Assoc Redacted], status: Successful (0),
 
I have switched back all my AP's to AiMesh nodes out of curiosity. I have to say, I'm liking AiMesh 2.0 a lot better compared to 1.0. There are a bunch of essential settings now in 2.0 that were missing in 1.0 which caused me to switch to AP mode. My two AX92U's are on 386.41712 and three AC68U's are on 386.41634... main router connected to all nodes via MoCA 2.0 wired backhaul. So far so good...I have not had to reboot my main AX92U to switch my AP's to mesh nodes. It's uptime has been 2 days 7 hours...2 of those hours have been in AiMesh. Fast wired and wifi speeds. Ai Protection and Traffic Analyzer turned on. I have about 70+ wired and wireless devices spread across the main router and mesh nodes.
 
Last edited:
Has anybody managed to figure out what "kernel: wl1: random key value:" means?
 
I have 2 RT-AX92u so far everything is fine in the log and in reality devices switch from router to node without any dropout so I can say it works. Dload/upload speeds are the same as before so I can safely say it works.
 

Sign Up For SNBForums Daily Digest

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

Members online

Top