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...

Hi all,

I follow @bobafetthotmail to "set_default disassoc_low_ack 0", then reboot my router and check:
cat /tmp/run/hostapd-phy0.conf

driver=nl80211
logger_syslog=127
logger_syslog_level=0
logger_stdout=127
logger_stdout_level=0
country_code=VN
ieee80211d=1
hw_mode=g
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60 120 240
beacon_int=100
dtim_period=2
channel=acs_survey

noscan=1

ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935]
ieee80211ax=1
he_default_pe_duration=4
he_rts_threshold=1023
he_mu_edca_qos_info_param_count=0
he_mu_edca_qos_info_q_ack=0
he_mu_edca_qos_info_queue_request=0
he_mu_edca_qos_info_txop_request=0
he_mu_edca_ac_be_aifsn=8
he_mu_edca_ac_be_aci=0
he_mu_edca_ac_be_ecwmin=9
he_mu_edca_ac_be_ecwmax=10
he_mu_edca_ac_be_timer=255
he_mu_edca_ac_bk_aifsn=15
he_mu_edca_ac_bk_aci=1
he_mu_edca_ac_bk_ecwmin=9
he_mu_edca_ac_bk_ecwmax=10
he_mu_edca_ac_bk_timer=255
he_mu_edca_ac_vi_ecwmin=5
he_mu_edca_ac_vi_ecwmax=7
he_mu_edca_ac_vi_aifsn=5
he_mu_edca_ac_vi_aci=2
he_mu_edca_ac_vi_timer=255
he_mu_edca_ac_vo_aifsn=5
he_mu_edca_ac_vo_aci=3
he_mu_edca_ac_vo_ecwmin=5
he_mu_edca_ac_vo_ecwmax=7
he_mu_edca_ac_vo_timer=255

radio_config_id=930a682e18036ba286b0e14611efdd12
interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=0
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
wpa_passphrase=SafeGate@2022
wpa_psk_file=/etc/hostapd-wlan0.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=mywifi
bridge=br-lan
wds_bridge=
snoop_iface=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
dynamic_vlan=0
vlan_naming=1
vlan_no_bridge=1
vlan_file=/var/run/hostapd-wlan0.vlan
qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
config_id=400b052c4d3a26b417f9023f849b0398
bssid=5c:92:5e:cc:34:c8

But the client devices still be disassociated due to inactivity.

Tue Nov 29 20:05:14 2022 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED d0:d0:03:24:e4:18
Tue Nov 29 20:05:14 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: disassociated due to inactivity
Tue Nov 29 20:05:14 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DISASSOCIATE.indication(d0:d0:03:24:e4:18, 4)
Tue Nov 29 20:05:14 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DELETEKEYS.request(d0:d0:03:24:e4:18)
Tue Nov 29 20:05:15 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Nov 29 20:05:15 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DEAUTHENTICATE.indication(d0:d0:03:24:e4:18, 2)
Tue Nov 29 20:05:15 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DELETEKEYS.request(d0:d0:03:24:e4:18)

Please explain to me about this.

Thank you.