Unstable WiFi Connections Recently - Many "Deauth" Entries

[monorailmedic]

My RT-AX58U has been plugging along just fine until recently, now running 388.2_2. At some point in the past month (tricky to tell as my main ISP changed, I was out of town, and I tweaked the failover script) WiFi devices regularly disconnect - albeit very briefly. None of the changes I've made are WiFi related, so I think it just made it harder to tell when all of this started as I was focussed on other challenges. I'm looking for help in understand what the root cause of these frequent drops may be so I can stop them.

What I'm Noticing
Some devices, such as a Google Home device I have with a screen, often shows that the connection has dropped and then pops back to life. Other devices, like my main laptop (M1 MBP) just have brief moments that I can't load content, or where video-conferencing gets jacked up. Sometimes, however, I actually see the laptop drop the WiFi connection, and then come back a few seconds later. My desktop, NAS, and other hardwired devices seem to be just fine.

My Findings
I'm definitely no expert at this, but consider myself a savvy end-user, so I figured I'd go into the logs and see what's going on. I did see a problem with the YazFi script that was causing a reset of some services and cycling of some device connections, and have since corrected that (just updated that script and those entries are gone). There are still quite a few things I'm noticing that I can't explain. Some of them may be benign, but I'm not sure. I'm pasting below a block from the logs and will go over what I know and what I don't about why some of these appear. I've masked a couple things.

The first two lines show deauth and then disassociation of a device "because sending station is leaving..." but no device left our very small condo during that time, no devices were powered down during that time, etc. No idea why this happened.
The next few lines (truncated) are all normal, I suspect seeing that I have an internal WAN IP (double NATd).
The kernel DROP IN lines, I'm guessing, are the router blocking packets. Probably normal?
Tailscale is probably causing the UDP mapping messages - and again, double NATd, so that seems expected.
After that I see the device that was disassociated starts reconnecting - just two seconds after it dropped. The next several lines are that handshake taking place.
After that a different device starts to connect - and looking before this block from the logs, it was disassociated two mins earlier for the same reason.

It's worth noting that I see many disconnects with other reasons, too. Again, in circumstances that don't seem right to me (a very uneducated person on this). Reasons include:
Disassociated due to inactivity
Unspecified reason
Previous authentication no longer valid

The Logs

May 16 23:44:45 wlceventd: wlceventd_proc_event(494): eth5: Deauth_ind xx:xx:xx:xx:xF:74, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
May 16 23:44:45 hostapd: eth5: STA xx:xx:xx:xx:xF:74 IEEE 802.11: disassociated
May 16 23:44:45 miniupnpd[13723]: private/reserved address 192.168.88.253 is not suitable for external IP
...
May 16 23:44:46 miniupnpd[13723]: private/reserved address 192.168.88.253 is not suitable for external IP
May 16 23:44:50 kernel: DROP IN=eth4 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:08:00 SRC=1xx.xxx.x5.206 DST=192.168.88.253 LEN=1184 TOS=0x00 PREC=0x00 TTL=116 ID=14522 PROTO=TCP SPT=443 DPT=57698 SEQ=4164051170 ACK=3368634025 WINDOW=1045 RES=0x00 ACK PSH URGP=0 OPT (0101080A25855DFB76010EBD) MARK=0x8000000 
May 16 23:44:52 kernel: DROP IN=eth4 OUT= MAC=yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:08:00 SRC=192.168.88.1 DST=255.255.255.255 LEN=150 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=130 MARK=0x8000000 
May 16 23:44:56 miniupnpd[13723]: PCP MAP: failed to add mapping UDP 41641->192.168.29.245:41641 'PCP MAP c2191e3f5a93de0f1eba71dc'
May 16 23:44:57 wlceventd: wlceventd_proc_event(530): eth5: Auth xx:xx:xx:xx:xF:74, status: Successful (0), rssi:0
May 16 23:44:57 hostapd: eth5: STA xx:xx:xx:xx:xF:74 IEEE 802.11: associated
May 16 23:44:57 wlceventd: wlceventd_proc_event(559): eth5: Assoc xx:xx:xx:xx:xF:74, status: Successful (0), rssi:-45
May 16 23:44:57 hostapd: eth5: STA xx:xx:xx:xx:xF:74 RADIUS: starting accounting session DC9D972FF31B8AA8
May 16 23:44:57 hostapd: eth5: STA xx:xx:xx:xx:xF:74 WPA: pairwise key handshake completed (RSN)
May 16 23:44:57 dnsmasq-dhcp[22957]: DHCPDISCOVER(br0) xx:xx:xx:xx:xF:74 
May 16 23:44:57 dnsmasq-dhcp[22957]: DHCPOFFER(br0) 192.168.29.175 xx:xx:xx:xx:xF:74 
May 16 23:44:57 dnsmasq-dhcp[22957]: DHCPREQUEST(br0) 192.168.29.175 xx:xx:xx:xx:xF:74 
May 16 23:44:57 dnsmasq-dhcp[22957]: DHCPACK(br0) 192.168.29.175 xx:xx:xx:xx:xF:74 WYZE_CAKP2JFUS-D03F27810F74
May 16 23:44:59 wlceventd: wlceventd_proc_event(530): eth5: Auth xx:xx:xx:x2:00:B5, status: Successful (0), rssi:0
May 16 23:45:00 wlceventd: wlceventd_proc_event(559): eth5: Assoc xx:xx:xx:x2:00:B5, status: Successful (0), rssi:-60
May 16 23:45:00 hostapd: eth5: STA xx:xx:xx:x2:00:B5 IEEE 802.11: associated
May 16 23:45:00 hostapd: eth5: STA xx:xx:xx:x2:00:B5 RADIUS: starting accounting session 3F919501E3EFAF4E
May 16 23:45:00 hostapd: eth5: STA xx:xx:xx:x2:00:B5 WPA: pairwise key handshake completed (RSN)

Any tips on what to look for or try would be welcome. My main network is now barely usable because of these issues, and I've gotta figure something out.

 

[drinkingbird]

Did it seem to start with 388.2_2? If so try downgrading.

Did you do a full factory reset after upgrading from 386 to 388?

Check if you have roaming assistant enabled, maybe the RSSI is set too low (new noise in your area, etc). Try another channel.

Just standard things to check. Worst case, the radio may be dying. Does it seem to be only one band or both?

Keep in mind when you upgrade code, 3rd party plugins/scripts may no longer work correctly. You may have to start from scratch (WPS reset) and add things one at a time to see if something is causing compatibility issues.

 

[monorailmedic]

I'm also seeing this a few times a day, and it looks like it's indicating config changes to WiFi, but I've not made any.

May 16 23:30:10 cfg_server: cm_updateChanspec call wl_chanspec_changed_action
May 16 23:30:10 cfg_server:  event: wl_chanspec_changed_action_a101 of eid(13) of cfgs(1708)
May 16 23:30:10 cfg_server: current chansp(unit0) is 1007
May 16 23:30:10 cfg_server: current chansp(unit1) is e39b
May 16 23:30:10 cfg_server: dump exclchans:
May 16 23:30:10 cfg_server: old wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
May 16 23:30:10 cfg_server: new wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
May 16 23:30:10 cfg_server: old wl1_acs_excl_chans:0xd0a5
May 16 23:30:10 cfg_server: new wl1_acs_excl_chans:0xd078,0xd07c,0xd080,0xd0a5,0xd976,0xd87e,0xd97e,0xe17a,0xe27a,0xe37a,0xed72,0xee72,0xef72
May 16 23:30:10 cfg_server:  wl_chanspec_changed_action: Need to restart acsd for AVBL update
May 16 23:30:10 rc_service: cfg_server 1708:notify_rc restart_acsd
May 16 23:30:10 custom_script: Running /jffs/scripts/service-event (args: restart acsd)

 

[drinkingbird]

I'm also seeing this a few times a day, and it looks like it's indicating config changes to WiFi, but I've not made any.

May 16 23:30:10 cfg_server: cm_updateChanspec call wl_chanspec_changed_action
May 16 23:30:10 cfg_server:  event: wl_chanspec_changed_action_a101 of eid(13) of cfgs(1708)
May 16 23:30:10 cfg_server: current chansp(unit0) is 1007
May 16 23:30:10 cfg_server: current chansp(unit1) is e39b
May 16 23:30:10 cfg_server: dump exclchans:
May 16 23:30:10 cfg_server: old wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
May 16 23:30:10 cfg_server: new wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
May 16 23:30:10 cfg_server: old wl1_acs_excl_chans:0xd0a5
May 16 23:30:10 cfg_server: new wl1_acs_excl_chans:0xd078,0xd07c,0xd080,0xd0a5,0xd976,0xd87e,0xd97e,0xe17a,0xe27a,0xe37a,0xed72,0xee72,0xef72
May 16 23:30:10 cfg_server:  wl_chanspec_changed_action: Need to restart acsd for AVBL update
May 16 23:30:10 rc_service: cfg_server 1708:notify_rc restart_acsd
May 16 23:30:10 custom_script: Running /jffs/scripts/service-event (args: restart acsd)

Are you using a DFS channel? If so, don't.

 

[monorailmedic]

Did it seem to start with 388.2_2? If so try downgrading.

Because of the other factors I can't pinpoint it. I was thinking of downgrading as a shot in the dark. Need to look up the process. I have backups.

Did you do a full factory reset after upgrading from 386 to 388?

No. I stay up to date on updates, and I think the Merlin docs mention resetting if jumping across multiple updates. Would a factory update be a waste if I restore a config file? Trying to make this as a last option if I'll need to spend a long time reconfiguring.

Check if you have roaming assistant enabled, maybe the RSSI is set too low (new noise in your area, etc). Try another channel.

Disabled. I've never adjusted any of the settings on the Professional tab. Control channels are both set to auto, which I'd have thought would have helped avoid conflicts?

Just standard things to check. Worst case, the radio may be dying. Does it seem to be only one band or both?

I have always had SmartSelect on, so I'm not sure whether this is always happening on the same band. I'd have thought I could see it in the logs, but not that I've noticed.

Keep in mind when you upgrade code, 3rd party plugins/scripts may no longer work correctly. You may have to start from scratch (WPS reset) and add things one at a time to see if something is causing compatibility issues.

Totally fair - but the only thing I've ever added was the WAN failover script. I've since uninstalled it and turned off failover in order to eliminate variables.

 

[monorailmedic]

Are you using a DFS channel? If so, don't.

I just disabled it now.

 

[monorailmedic]

Still seeing dauths after disabling DFS :-/

 

[drinkingbird]

Because of the other factors I can't pinpoint it. I was thinking of downgrading as a shot in the dark. Need to look up the process. I have backups.

No. I stay up to date on updates, and I think the Merlin docs mention resetting if jumping across multiple updates. Would a factory update be a waste if I restore a config file? Trying to make this as a last option if I'll need to spend a long time reconfiguring.

Disabled. I've never adjusted any of the settings on the Professional tab. Control channels are both set to auto, which I'd have thought would have helped avoid conflicts?

I have always had SmartSelect on, so I'm not sure whether this is always happening on the same band. I'd have thought I could see it in the logs, but not that I've noticed.

Totally fair - but the only thing I've ever added was the WAN failover script. I've since uninstalled it and turned off failover in order to eliminate variables.

It isn't necessarily the number of revisions you jump, but the major releases. 386 to 388 definitely should be full factory reset and reconfigure from scratch, not a backup. If you do downgrade (easy enough, same process as upgrading) and you have a backup from that older code, restoring it should be ok. But factory reset after downgrading, then preferably reconfigure by hand, but if the backup is from that version, you're probably ok (unless the backup was taken from a "dirty" router that has been upgraded several times without factory reset).

What version were you on before 388.2_2? If it was 386, you definitely need to factory reset and reconfigure from scratch. That alone may resolve your problem.

Auto channel selection usually does work fine, as long as you have it set to 20/40/80 and DFS unchecked. I would avoid 160 so leave that unchecked.

Try disabling smartselect, that could quite possibly be the culprit, the router bumping a client to 5ghz but the client sees the signal isn't as good and goes back to 2.4, then the router does it again, etc. Most devices will prefer 5ghz on their own as long as the signal is good.

You mentioned yazfi so thought you were running that. Note that uninstalling something does not necessarily clear out all its configs and variables.

While it seems like a pain, the first step is always WPS factory reset and reconfigure from scratch. Lots of "weird" issues disappear that way.

 

[monorailmedic]

Try disabling smartselect, that could quite possibly be the culprit, the router bumping a client to 5ghz but the client sees the signal isn't as good and goes back to 2.4, then the router does it again, etc. Most devices will prefer 5ghz on their own as long as the signal is good.

Disabled SmartSelect just before this reply. Looks like deauths are continuing, but I'll give things a few to stabilize given that this change alone, I suspect, would cause quite a bit of disconnecting and reconnecting.

You mentioned yazfi so thought you were running that. Note that uninstalling something does not necessarily clear out all its configs and variables.

It seems to have been installed with one of the images along the way - but I never installed it. I realize stuff can be left behind - I was hoping there was a greater level of debugging I could do rather than guessing that it could be this or that. All VERY reasonable prospects by the way, just trying to avoid the pain I suppose.

Hopefully I'll get through work quickly enough tomorrow to do a reset before leaving town for a few days. Trying to leave things stable for my s/o while I'm out.

 

[drinkingbird]

Disabled SmartSelect just before this reply. Looks like deauths are continuing, but I'll give things a few to stabilize given that this change alone, I suspect, would cause quite a bit of disconnecting and reconnecting.

It seems to have been installed with one of the images along the way - but I never installed it. I realize stuff can be left behind - I was hoping there was a greater level of debugging I could do rather than guessing that it could be this or that. All VERY reasonable prospects by the way, just trying to avoid the pain I suppose.

Hopefully I'll get through work quickly enough tomorrow to do a reset before leaving town for a few days. Trying to leave things stable for my s/o while I'm out.

Having disabled DFS and smartselect, did you reboot after?

 

[Dedel66]

It seems to have been installed with one of the images along the way -

That´s not possible!

 

[maxbraketorque]

Having disabled DFS and smartselect, did you reboot after?

Definitely reboot. I would power cycle the router too.

 

[monorailmedic]

That´s not possible!

I suppose it's possible that at some point I did that...but I have NO idea when, as I'd never heard of it, and the only guest network functionality I created was through the UI as I didn't have any special needs. I only learned it was installed when I ran amtm for the first time (didn't know it existed) last week. Maybe I installed it via SSH at some point a long time ago and forgot, but I've no idea why I would have.

 

[FredTheFrog]

I would do a full wipe of the router firmware and load Merlin release 388.2_2 using the Asus Firmware Recovery Utility, then configure your router settings as needed. That's the only thing that made my situation any better.

 

[drinkingbird]

I would do a full wipe of the router firmware and load Merlin release 388.2_2 using the Asus Firmware Recovery Utility, then configure your router settings as needed. That's the only thing that made my situation any better.

I'd probably just try factory reset before going quite that far. There is little you can mess up bad enough that a factory reset won't get it back to "factory". Wiping off the firmware is a much riskier proposal. If you want piece of mind you can reinstall the current version on top of itself.

 

[monorailmedic]

I did a a WPS reset and setup everything again (remembered to copy/screenshot my IP reservations and such!) and so far performance is looking better. The UI actually loads way faster, too - which is certainly a red flag that there were some issues previously.

I do still see some deauths, but not nearly as many, and they may be for legit reasons (or where the individual devices have problems) but I'll need to dig deeper.

Much appreciated.

 

[drinkingbird]

I did a a WPS reset and setup everything again (remembered to copy/screenshot my IP reservations and such!) and so far performance is looking better. The UI actually loads way faster, too - which is certainly a red flag that there were some issues previously.

I do still see some deauths, but not nearly as many, and they may be for legit reasons (or where the individual devices have problems) but I'll need to dig deeper.

Much appreciated.

Seeing deauths for "sending station has left" is normal, means the device was out of range, went to sleep, etc.

 

[vdrx]

Hello!
After returning home from a 2wk period I have noticed the same behavior as OP (even with the same deauth log entries). My router is an AX56U running on Current Version : 388.2_2. I do not remember having these issues prior to leaving home. All devices are always in great range since my apartment is small and walls are thin.

I rebooted the router and even left it turned off for a while in hopes it will recover from these issues, but it has not. All of the devices are always in range.
I will install 388.2_2 on top of itself and see if things improve, and I'll report back.

Seeing deauths for "sending station has left" is normal, means the device was out of range, went to sleep, etc.

This is certainly true, but not for devices that never move - for example my bedroom TV or work laptop which are within ~8 ft of the router with direct line of sight, both have full signal strength at all times.

 

[drinkingbird]

Hello!
After returning home from a 2wk period I have noticed the same behavior as OP (even with the same deauth log entries). My router is an AX56U running on Current Version : 388.2_2. I do not remember having these issues prior to leaving home. All devices are always in great range since my apartment is small and walls are thin.

I rebooted the router and even left it turned off for a while in hopes it will recover from these issues, but it has not. All of the devices are always in range.
I will install 388.2_2 on top of itself and see if things improve, and I'll report back.




This is certainly true, but not for devices that never move - for example my bedroom TV or work laptop which are within ~8 ft of the router with direct line of sight, both have full signal strength at all times.

First thought is possibly some new interference. Are you on static channel? It is possible the router changed channels while you were away (if not static), or the channel you're on now has interference. If changing channels doesn't help:

First try unplugging the router while powered on to drain the caps and reset everything. If no improvement, next thing to try is, hard factory reset and reconfigure manually. If none of that helps and you did not have this issue before and nothing has changed, your wireless radio (or solder joints) may be failing. Or the interference is severe and impacting the whole spectrum.

 

[vdrx]

Thank you so much for your suggestions, @drinkingbird !
I never thought of doing a site survey but I will definitely do it and see if there's any channel congestion/interference, this is great advice! The apartment building is rather new, and there were a few unoccupied apartments around, maybe they were filled up recently. My channels are all set on Auto, but you never know!

Never had this issue before - this is a brand new replacement router I received from Asus, the previous one was dropping the WAN connection constantly. I'd hate for this one to also have hardware issues, but if this is the case I might look at other manufacturers (I'm coming from previously owning TP-Link routers).