Troubleshooting Wi-Fi Connectivity Issue in AiMesh Mode

[avole]

I've been encountering a weird Wi-Fi issue with my AiMesh setup where every few days, the Wi-Fi connected in AiMesh mode gets disconnected, displaying an error on my phone/iPad stating "incorrect password." The temporary fix I've found is manually rebooting the node, but I'm looking for a more permanent solution to this recurring problem. Has anyone else experienced this issue or know what might be causing it? I'm eager to understand the root cause and explore alternative solutions beyond scheduling regular reboots for the node. Thank you in advance for your help.

 

[bennor]

I've been encountering a weird Wi-Fi issue with my AiMesh setup where every few days, the Wi-Fi connected in AiMesh mode gets disconnected, displaying an error on my phone/iPad stating "incorrect password." The temporary fix I've found is manually rebooting the node, but I'm looking for a more permanent solution to this recurring problem. Has anyone else experienced this issue or know what might be causing it? I'm eager to understand the root cause and explore alternative solutions beyond scheduling regular reboots for the node. Thank you in advance for your help.

It may help others diagnose your possible issue if you post more specifics.
What are the router and AiMesh node models?
How are the AiMesh node(s) connected to the main router?
What firmware are they running? If the issue is with WiFi devices like smartphones connecting to the AiMesh node's WiFi, what are the WiFi settings (redact sensitive information)?
Do other WiFi clients exhibit the same issue as the "phone/iPad"?
Is the "phone" a iPhone? If not what make/model is it?
Does the WiFi password and SSID contain special characters?
Have you tried changing the WiFi password and SSID to a simple name and password as a troubleshooting test?
Have you instructed the phone to loose or forget the WiFi SSID/password and setup a new WiFi connection?
What other troubleshooting steps have you tried?

 

[avole]

Sorry forgot to include those information.

It may help others diagnose your possible issue if you post more specifics.
What are the router and AiMesh node models?

Main router: AX88U pro; only one node: AC68U

How are the AiMesh node(s) connected to the main router?

Ethernet connection

What firmware are they running? If the issue is with WiFi devices like smartphones connecting to the AiMesh node's WiFi, what are the WiFi settings (redact sensitive information)?

AX88U pro: 3004.388.6_2; AC68u: 3004.386.12_6. The problem also exist in the previous versions of firmware.
WiFi settings: Smart Connect with Dual band smart connect; 802.11ax / WiFi 6 mode enable; Authentication Method: WPA2/3.

Do other WiFi clients exhibit the same issue as the "phone/iPad"?

Yes.

Is the "phone" a iPhone? If not what make/model is it?

Yes.

Does the WiFi password and SSID contain special characters?

SSID only alphanumeric. Password contains special character. Guest wifi has no special characters in SSID and password, also has the same problem.

Have you tried changing the WiFi password and SSID to a simple name and password as a troubleshooting test?

Not yet.

Have you instructed the phone to loose or forget the WiFi SSID/password and setup a new WiFi connection?

Yes, the the problem persist.

What other troubleshooting steps have you tried?

Forget wifi, won't solve the problem. Try other devices, have the same problem. Reboot the node, solve the problem.

 

[glens]

Sad to say this may be evidence of AiMesh not working well with disparate hardware. Perhaps you've declared WPA3 in some fashion and the AC class node chokes on passing the information along, or something else technically similar?

 

[avole]

Same problem happened again, below is the system.log:

Mar 19 18:50:21 kernel: nas/389: potentially unexpected fatal signal 6.
Mar 19 18:50:21 kernel: Pid: 389, comm: nas
Mar 19 18:50:21 kernel: CPU: 1 Tainted: P (2.6.36.4brcmarm #1)
Mar 19 18:50:21 kernel: PC is at 0x401f1340
Mar 19 18:50:21 kernel: LR is at 0x4022f090
Mar 19 18:50:21 kernel: pc : [<401f1340>] lr : [<4022f090>] psr: 60000010
Mar 19 18:50:21 kernel: sp : beda91b8 ip : 402488f8 fp : 0007f420
Mar 19 18:50:21 kernel: r10: 0007f35c r9 : beda994e r8 : beda92fe
Mar 19 18:50:21 kernel: r7 : 00000025 r6 : 00000000 r5 : 40249280 r4 : 402484f8
Mar 19 18:50:21 kernel: r3 : 00004d64 r2 : 000009a0 r1 : 00000006 r0 : 00000000
Mar 19 18:50:21 kernel: Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Mar 19 18:50:21 kernel: Control: 10c53c7d Table: 9dbd804a DAC: 00000015
Mar 19 18:50:23 syslog: wlceventd_proc_event(530): wl1.1: Auth 98:A5:43:44:45:14, status: Successful (0), rssi:0
Mar 19 18:50:23 syslog: wlceventd_proc_event(540): wl1.1: ReAssoc 98:A5:43:44:45:14, status: Successful (0), rssi:0
Mar 19 18:50:23 syslog: wlceventd_proc_event(511): wl0.1: Disassoc 98:A5:43:44:45:14, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 19 18:50:29 syslog: wlceventd_proc_event(494): wl1.1: Deauth_ind 98:A5:43:44:45:14, status: 0, reason: 4-way handshake timeout (f), rssi:0
Mar 19 18:50:32 syslog: wlceventd_proc_event(530): wl1.1: Auth 98:A5:43:44:45:14, status: Successful (0), rssi:0
Mar 19 18:50:32 syslog: wlceventd_proc_event(559): wl1.1: Assoc 98:A5:43:44:45:14, status: Successful (0), rssi:0
Mar 19 18:50:38 syslog: wlceventd_proc_event(494): wl1.1: Deauth_ind 98:A5:43:44:45:14, status: 0, reason: 4-way handshake timeout (f), rssi:0
Mar 19 18:52:35 syslog: wlceventd_proc_event(530): wl0.1: Auth 18:3E:AA:BB:CC:99, status: Successful (0), rssi:0
Mar 19 18:52:35 syslog: wlceventd_proc_event(540): wl0.1: ReAssoc 18:3E:AA:BB:CC:99, status: Successful (0), rssi:0
Mar 19 18:52:35 syslog: wlceventd_proc_event(511): wl1.1: Disassoc 18:3E:AA:BB:CC:99, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 19 18:52:41 syslog: wlceventd_proc_event(494): wl0.1: Deauth_ind 18:3E:AA:BB:CC:99, status: 0, reason: 4-way handshake timeout (f), rssi:0
Mar 19 18:52:46 syslog: wlceventd_proc_event(530): wl1.1: Auth 18:3E:AA:BB:CC:99, status: Successful (0), rssi:0
Mar 19 18:52:46 syslog: wlceventd_proc_event(559): wl1.1: Assoc 18:3E:AA:BB:CC:99, status: Successful (0), rssi:0
Mar 19 18:52:52 syslog: wlceventd_proc_event(494): wl1.1: Deauth_ind 18:3E:AA:BB:CC:99, status: 0, reason: 4-way handshake timeout (f), rssi:0

 

[RMerlin]

Same problem happened again, below is the system.log:

The nas process handles the WPA encryption for your connected client. This is the first time I see this service actually crashing, so I wonder if maybe it might indicate failing hardware.

Try doing an electrical reset of your device. Unplug the power while leaving the power switch on. Wait 5-10 seconds, then plug it back in, and let it boot normally.

 

[avole]

The nas process handles the WPA encryption for your connected client. This is the first time I see this service actually crashing, so I wonder if maybe it might indicate failing hardware.

This node is AC68U, in service since 2019 as the main router and was converted as a AiMesh node since last year.

Try doing an electrical reset of your device. Unplug the power while leaving the power switch on. Wait 5-10 seconds, then plug it back in, and let it boot normally.

This problem has occurred many times over the past few months, with the temporary fix being an electrical reset as you mentioned; however, it keeps coming back.

 

[RMerlin]

This node is AC68U, in service since 2019.

This problem has occurred many times over the past few months, with the temporary fix being an electrical reset as you mentioned; however, it keeps coming back.

If just a regular reboot doesn't work, then maybe the root cause is the radio itself is crashing, causing the nas process to also crash as it tries to talk to it, and requiring an electrical reset to revive the radio itself. That would most likely point at a hardware issue with the radio itself.

See if, while you can't connect any other devices, the Wirelsss Log shows which channel that radio is. If it shows channel 0, then the radio itself is definitely crashed.

 

[L&LD]

To try to rule out a hardware issue:

Nuclear Reset https://www.snbforums.com/threads/major-issues-w-rt-ac86u.56342/page-4#post-495710

 

[avole]

If just a regular reboot doesn't work, then maybe the root cause is the radio itself is crashing, causing the nas process to also crash as it tries to talk to it, and requiring an electrical reset to revive the radio itself. That would most likely point at a hardware issue with the radio itself.

See if, while you can't connect any other devices, the Wirelsss Log shows which channel that radio is. If it shows channel 0, then the radio itself is definitely crashed.

Thank you for your help!

Are those the correct command to get the wireless log? I will check the log next time the problem comes back.
/usr/sbin/wl -i wl0.1 assoc
/usr/sbin/wl -i wl1.1 assoc

Maybe I can set up a cron job to monitor the log, and reboot the node whenever the channel is 0.

 

[avole]

To try to rule out a hardware issue:

Nuclear Reset https://www.snbforums.com/threads/major-issues-w-rt-ac86u.56342/page-4#post-495710

Thanks! I will definitely give the nuclear reset a go!

 

[RMerlin]

Are those the correct command to get the wireless log?

No, I mean go to the Wireless Log page on the webui:

https://demoui.asus.com/Main_WStatus_Content.asp

 

[avole]

No, I mean go to the Wireless Log page on the webui:

https://demoui.asus.com/Main_WStatus_Content.asp

Sorry, I think the problem occurs on the AiMesh node, so no wireless log from webui, is there any way to get the wireless log from terminal?

 

[RMerlin]

Sorry, I think the problem occurs on the AiMesh node, so no wireless log from webui, is there any way to get the wireless log from terminal?

I'm not sure if this work on an AiMesh node, but try the following over SSH:

wl -i $(nvram get wl0_ifname) status

Replace wl0 with wl1 for the 5 GHz radio, or wl2 for the second 5 GHz radio.

 

[avole]

I'm not sure if this work on an AiMesh node, but try the following over SSH:

wl -i $(nvram get wl0_ifname) status

Replace wl0 with wl1 for the 5 GHz radio, or wl2 for the second 5 GHz radio.

Yes, it works perfectly. Although for the node, the interfaces are wl0.1 and wl1.1 respectively.

 

[avole]

If just a regular reboot doesn't work, then maybe the root cause is the radio itself is crashing, causing the nas process to also crash as it tries to talk to it, and requiring an electrical reset to revive the radio itself. That would most likely point at a hardware issue with the radio itself.

See if, while you can't connect any other devices, the Wirelsss Log shows which channel that radio is. If it shows channel 0, then the radio itself is definitely crashed.

It happened again, Wireless Log shows the channel didn't fall back to 0, it stays the same.
Again, reboot solve the problem. I turned off the "Smart Connect" option, plan to turn off "Roaming assistant" if it happens again.