Option disassoc_low_ack '1'

I currently have 1x 2.4ghz device that gets disconnected unexpectedly once every 5-7 days. The device then pretends to be still connected with zero wifi strength signal, but no more IP connection is possible. Basically wifi on the device is frozen.
To get this client device back alive on the wifi, I have to remove the wifi config on the device and have to re-enroll the device again on my wifi. Then another 5-7 day cycle repeats on and on.
All other client devices have no issue.

It took me several weeks to identify that most likely the option:
option disassoc_low_ack '1'
is responsible for the unwanted disconnect.
I have now set this to 0, and for the first time ever, the strange disconnect no longer happens for 2 weeks now.

This option seems to be present for quite a while now in OpenWRT versions, in all versions being default-on.

I understand that this option might be helpful in professional environments, to kick lingering devices that just seem to block valuable AP ressources.

But can someone tell me, what kind of advantage this option brings, when it is default-enabled on a typical SOHO OpenWRT router at home?

1 Like

By spec all wifi devices should be able to detect they have been dropped and ask to re-associate.

Home routers have limited resources and limited number of clients (some hardware is capped at 32 clients max).

That said, for hostapd (the application that is using this config to operate the wifi in the device) this option is default 0
https://w1.fi/cgit/hostap/commit/?id=0d7e5a3a29efd4bc138e74b19657e750d22c2887
while in OpenWrt this is set to 1 by default

from this commit done in the old source archive https://git.openwrt.org/?p=openwrt/svn-archive/openwrt.git;a=commit;h=9b020e776ec7fb475b38ef3403ff5c88e523fe93
hostapd: enable disassoc on many consecutive excessive retries, improves AP mode reliability with many clients

I think that it can be a good idea to open a PR on github or on mailing list to change this default, they either accept it or reject it and tell you a better answer than a couple lines from the old commit.

2 Likes

thanks. I think I might do that.
But I will do some long term observation first, to collect more results.

Technically, this is a client bug. Of course not having control of that it may be possible to work around.

Many battery powered clients simply shut down their wifi radio when they don't need the network. They may not even transmit a deassociate request first, since to them that is a waste of battery power.

1 Like

Yep, sounds like you've found one of the big causes. From my hanging around the Bufferbloat developer community (as a spectator, not a developer!) and other places, I've heard about that for years. Many devces have poor powersave handling that causes a lot of delay going in and out of it. Don't know if that's getting better over the years or not, but one can turn it off, most of the time.

Here's a great article digging into many sources of delays in wifi... maybe you can find and disable some other sources of your drops: https://www.smallnetbuilder.com/wireless/wireless-features/33228-wi-fi-ping-spikes-causes-and-fixes I realize you're not complaining about latency so much, but one or two things may apply. (been talking to a lot of latency oriented folks recently)

This does sound like bad design in the station code, not handling a disassociation well. I guess there's always checking for a updated driver that (hopefully) addressed it...