RapidReader
New Around Here
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!
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!