RT-AX68U and unstable wifi on Windows resume

[RapidReader]

Hello all, I'm new here (obviously) and am looking for help on how to troubleshoot an issue. I recently replaced my home wifi with an RT-AX68U, which I flashed to Merlin 386.7 (and have since re-flashed following tips from L&LD about fully resetting the router when flashing). My issue is, for Windows clients only, when they resume from standby, there is a lot of instability of the wifi signal for usually 3-6 minutes. On the Windows side, I'll see a wifi connection icon, and it may work for about 10-15 seconds, but then it will drop to no connection, then often back to connected but no internet, then usually no connection again, and then after a few minutes, it will usually connect. Once it gets to that final connection, it's completely stable and solid (until the next Windows standby and then resume). But this usually takes a few minutes. Trying to disconnect and manually reconnect to the wifi doesn't speed things up.

From the router side, the log shows a number of "wlceventd: wlceventd_proc_event(508): eth5: Disassoc xx:xx:xx:xx:xx:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0" messages during those first minutes after resume, so I think this tells me that it's the Windows side that is disconnecting. Is that right? Here's a link to a chunk of the log showing the associating/disassociating during those few minutes: https://pastebin.pl/view/b7f16a71

This happens with connecting to my main SSID; I've tried both with Smart Connect on and off, and it behaves the same. However, if I connect to a guest SSID, either 2.4ghz or 5ghz, I don't see this behavior; in that case, as soon as the client resumes, it quickly finds the (guest) wifi and connects and holds the signal pretty much immediately. Also, this only happens with Windows clients (various laptops running Windows 10). My Android and ChromeOS devices connect pretty much immediately on resume, with none of this weirdness. I also have a Windows desktop that is hardwired, and naturally it connects immediately on resume as well.

Any suggestions for how else to troubleshoot this? Is there any other sort of logging that I should do to try to see exactly what's happening during those few minutes before the signal stabilizes?

Thanks for any help or tips!

 

[bbunge]

Hello all, I'm new here (obviously) and am looking for help on how to troubleshoot an issue. I recently replaced my home wifi with an RT-AX68U, which I flashed to Merlin 386.7 (and have since re-flashed following tips from L&LD about fully resetting the router when flashing). My issue is, for Windows clients only, when they resume from standby, there is a lot of instability of the wifi signal for usually 3-6 minutes. On the Windows side, I'll see a wifi connection icon, and it may work for about 10-15 seconds, but then it will drop to no connection, then often back to connected but no internet, then usually no connection again, and then after a few minutes, it will usually connect. Once it gets to that final connection, it's completely stable and solid (until the next Windows standby and then resume). But this usually takes a few minutes. Trying to disconnect and manually reconnect to the wifi doesn't speed things up.

From the router side, the log shows a number of "wlceventd: wlceventd_proc_event(508): eth5: Disassoc xx:xx:xx:xx:xx:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0" messages during those first minutes after resume, so I think this tells me that it's the Windows side that is disconnecting. Is that right? Here's a link to a chunk of the log showing the associating/disassociating during those few minutes: https://pastebin.pl/view/b7f16a71

This happens with connecting to my main SSID; I've tried both with Smart Connect on and off, and it behaves the same. However, if I connect to a guest SSID, either 2.4ghz or 5ghz, I don't see this behavior; in that case, as soon as the client resumes, it quickly finds the (guest) wifi and connects and holds the signal pretty much immediately. Also, this only happens with Windows clients (various laptops running Windows 10). My Android and ChromeOS devices connect pretty much immediately on resume, with none of this weirdness. I also have a Windows desktop that is hardwired, and naturally it connects immediately on resume as well.

Any suggestions for how else to troubleshoot this? Is there any other sort of logging that I should do to try to see exactly what's happening during those few minutes before the signal stabilizes?

Thanks for any help or tips!

First recommendation is to go back to Asus firmware and see if the issue persists. Use default WIFI settings and avoid DFS channels. Make sure your WIFI drivers are up to date (don't rely on WIndows update but go to the WIFI card maker for their driver update). Not sure if the AX68U supports WPA3 but if it does use WPA2/WPA3-Personal and even then some clients may not like it.

 

[Tech9]

In this specific case I believe the client is the issue. Many Wi-Fi adapters in Windows have driver related issues with hibernation, sleep or standby. I would focus my attention on the client - update the drivers, disable power saving features, etc.

 

[BreakingDad]

In this specific case I believe the client is the issue. Many Wi-Fi adapters in Windows have driver related issues with hibernation, sleep or standby. I would focus my attention on the client - update the drivers, disable power saving features, etc.

Especially ones built into motherboards - realteks for example, I've had great success disabling them and replacing them with Intel Cards. No matter what settings I throw at an Intel network card, I can't make them unstable.

Agree that all the powersave settings on network cards are a pita.

 

[Tech9]

The ones attached to PCIe line are usually better and have better troubleshooting chances, but USB adapter almost always has some issues after sleep.

 

[RapidReader]

Thanks everyone for your suggestions. I did go back to stock Asus firmware 3.0.0.4.386.49479, but there was no difference. Focusing on the Windows driver, I ensured that I was using the most up to date driver (Dell Wireless 1820A 802.11ac, built in to my Dell XPS 9350; got the driver from Dell's website) and deleted and re-installed the driver, but the problem persists. Might anyone else have any other suggestions for how to troubleshoot this or what else I could try? I'm at a loss for what else to do. Thanks in advance!

 

[RapidReader]

Just in case anyone finds this thread in the future, I found the solution to my problem. I had a Linux server on my network that was also running DHCP (I had a weird network setup before I replaced my wifi routers, and this server was acting as a router for one of my subnets), so I believe the Windows clients were getting confused by multiple DHCP messages. Once I disabled this other DHCP server, everything has been working fine. Thankfully I stumbled onto another post that sounded similar to my problem, and it gave me the idea to look into my network topology as the source of the problem.