Archer C7 v5 seldom client disconnects between bands

Hey, I'm using latest snapshot on my Archer C7 v5 and having client disconnects when the client is going between bands, its not usual but its happening. Please take a look at below log.

Going to wlan0 (5GHz) because the signal is good

Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: binding station to interface 'wlan0'
Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: authentication OK (FT)
Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 MLME: MLME-AUTHENTICATE.indication(43:xx:xx:xx:xx:b3, FT)
Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: association OK (aid 2)
Sat Sep  5 17:23:29 2020 daemon.notice hostapd: wlan0: STA-OPMODE-N_SS-CHANGED 43:xx:xx:xx:xx:b3 2
Sat Sep  5 17:23:29 2020 daemon.info hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: associated (aid 2)
Sat Sep  5 17:23:29 2020 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 43:xx:xx:xx:xx:b3
Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 MLME: MLME-REASSOCIATE.indication(43:xx:xx:xx:xx:b3)
Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: binding station to interface 'wlan0'
Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 WPA: event 6 notification
Sat Sep  5 17:23:29 2020 daemon.notice hostapd: wlan1: Prune association for 43:xx:xx:xx:xx:b3
Sat Sep  5 17:23:29 2020 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 43:xx:xx:xx:xx:b3
Sat Sep  5 17:23:29 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 WPA: FT authentication already completed - do not start 4-way handshake
Sat Sep  5 17:23:31 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DISASSOCIATE.indication(43:xx:xx:xx:xx:b3, 1)
Sat Sep  5 17:23:31 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep  5 17:23:42 2020 daemon.err hostapd: nl80211: kernel reports: key addition failed

Client decides to go to wlan1 (2GHz) imminently due to its roaming algorithm, but realize above that DEAUTHENTICATE and DELETEKEYS sequence didn't even get a chance to run for wlan1 after DISASSOCIATE

Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: binding station to interface 'wlan1'
Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: authentication OK (FT)
Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-AUTHENTICATE.indication(43:xx:xx:xx:xx:b3, FT)
Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: association OK (aid 7)
Sat Sep  5 17:23:42 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: associated (aid 7)
Sat Sep  5 17:23:42 2020 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 43:xx:xx:xx:xx:b3
Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-REASSOCIATE.indication(43:xx:xx:xx:xx:b3)
Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: binding station to interface 'wlan1'
Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: event 6 notification
Sat Sep  5 17:23:42 2020 daemon.notice hostapd: wlan0: Prune association for 43:xx:xx:xx:xx:b3
Sat Sep  5 17:23:42 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 43:xx:xx:xx:xx:b3
Sat Sep  5 17:23:42 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: FT authentication already completed - do not start 4-way handshake
Sat Sep  5 17:23:44 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DISASSOCIATE.indication(43:xx:xx:xx:xx:b3, 1)
Sat Sep  5 17:23:44 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep  5 17:24:12 2020 daemon.info hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sat Sep  5 17:24:12 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DEAUTHENTICATE.indication(43:xx:xx:xx:xx:b3, 2)
Sat Sep  5 17:24:12 2020 daemon.debug hostapd: wlan0: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)

My algorithm to steer client (bss_tm_req) gives 2 minutes heads up after associating a band in order to not hurry up things that may go haywire (but it got rejected here)

Sat Sep  5 17:26:10 2020 user.notice 5GRoam: 43:xx:xx:xx:xx:b3 is being steered...
Sat Sep  5 17:26:11 2020 daemon.notice hostapd: wlan1: BSS-TM-RESP 43:xx:xx:xx:xx:b3 status_code=1 bss_termination_delay=0
Sat Sep  5 17:26:13 2020 user.notice 5GRoam: 43:xx:xx:xx:xx:b3 is steered to 5GHz with -58

Look here client is disconnected without its will (indication is 2 not 8) suspecting because above it didn't get a chance to do DEAUTHENTICATE and DELETEKEYS on wlan1 and I think that's why it got indication 2 and disassociated from the band

Indication 2 is previous authentication/association no longer valid
Indication 8 is client has left the AP by its own.

Also below wlan1 has 2 repeated disassociation indicators which is weird, indicator 1 means no reason.

I know for a fact that when I turn off Wi-Fi on my phone, I get indication 8

Sat Sep  5 17:27:12 2020 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 43:xx:xx:xx:xx:b3
Sat Sep  5 17:27:12 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: disassociated due to inactivity
Sat Sep  5 17:27:12 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DISASSOCIATE.indication(43:xx:xx:xx:xx:b3, 2)
Sat Sep  5 17:27:12 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep  5 17:27:12 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DISASSOCIATE.indication(43:xx:xx:xx:xx:b3, 1)
Sat Sep  5 17:27:12 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep  5 17:27:13 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sat Sep  5 17:27:13 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DEAUTHENTICATE.indication(43:xx:xx:xx:xx:b3, 2)
Sat Sep  5 17:27:13 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)

After that I manually turn on the client (my phone) screen and found out that it has no Wi-Fi icon and it connects automatically again as nothing happened with 4-way-handshake. My phone has power saving turned off for both Wi-Fi and the dual-bands on Archer C7 v5.

So what do you think happening here? How can I fix it?

Can you better describe your issue?

Because what you noted above sounds like normal operation...particularly when someone configures the 5.4 and 2.4 GHz APs with the same SSID.

  • Is this the OpenWrt?
  • Did you install some package?

(It really sounds like you should ask the support for the client device, not OpenWrt. But again, I've also observed this "roaming" behavior - regardless if the SSIDs are different or the same.)

BTW, you don't show your /etc/config/wireless - that'll probably make things easier.


config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11a'
	option path 'pci0000:00/0000:00:00.0'
	option htmode 'VHT40'
	option channel '44'
	option country 'US'
	option txpower '23'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ft_over_ds '1'
	option ssid 'ssid'
	option encryption 'psk2+ccmp'
	option ft_psk_generate_local '1'
	option key 'ssidssid'
	option ieee80211r '1'
	option max_inactivity '65000'          <- just to be safe that client doesn't get kicked out needlessly, however i didnt do disassociate_on_low_ack=0, never got disassociated on low acknowledgment anyway
	option rssi_reject_assoc_rssi '-80'    <- this has no effect, didn't get parsed into hostapd.conf
	option ieee80211v '1'
	option bss_transition '1'
	option logger_syslog_level '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ahb/18100000.wmac'
	option htmode 'HT20'
	option channel '1'
	option country 'US'
	option txpower '24'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ft_over_ds '1'
	option ssid 'ssid'
	option encryption 'psk2+ccmp'
	option ft_psk_generate_local '1'
	option key 'ssidssid'
	option ieee80211r '1'
	option max_inactivity '65000'        <- just to be safe that client doesn't get kicked out needlessly, however i didnt do disassociate_on_low_ack=0, never got disassociated on low acknowledgment anyway
	option ieee80211v '1'
	option bss_transition '1'
	option logger_syslog_level '1'

So to recap, client got kicked out of the band once a day or once a few days w/o its own doing (indicator is not 8), when it goes back and forth between bands. I'm trying to isolate the issue, I'm sure 90% its not the client, and its OpenWrt.

Maybe I will try using rsn_preauth=1, having authorized beforehand so it wont get deauthrized after steering?? I also read hostapd.conf thoroughly and maybe there are problems in wpa commands which I should try but I need assistance on that.

I do not use package for steering, its my own script solely based on hostapd_cli bss_tm_req with disassoc_imminent timer on 600s (any lower than that, then theres disconnection issues just like this) so this is also in consideration, but 600s is sweet spot and it doesn't get any disconnections.

If its a roaming behavior then we're doomed, lol. How this can be a behavior? Its not good.

Another client timeout, this time with indication 8. What's going on? Client has -71 to -75dBm signal at that point.

Sat Sep 12 02:40:47 2020 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 43:xx:xx:xx:xx:b3
Sat Sep 12 02:40:47 2020 daemon.err hostapd: nl80211: kernel reports: key addition failed
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: binding station to interface 'wlan1'
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: authentication OK (FT)
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-AUTHENTICATE.indication(43:xx:xx:xx:xx:b3, FT)
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: association OK (aid 3)
Sat Sep 12 02:40:47 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: associated (aid 3)
Sat Sep 12 02:40:47 2020 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 43:xx:xx:xx:xx:b3
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-REASSOCIATE.indication(43:xx:xx:xx:xx:b3)
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: binding station to interface 'wlan1'
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: event 6 notification
Sat Sep 12 02:40:47 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: FT authentication already completed - do not start 4-way handshake
Sat Sep 12 02:40:48 2020 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 43:xx:xx:xx:xx:b3
Sat Sep 12 02:40:48 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: event 2 notification
Sat Sep 12 02:40:48 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.1X: unauthorizing port
Sat Sep 12 02:40:48 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: disassociated
Sat Sep 12 02:40:48 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DISASSOCIATE.indication(43:xx:xx:xx:xx:b3, 8)
Sat Sep 12 02:40:48 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep 12 02:40:49 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sat Sep 12 02:40:49 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DEAUTHENTICATE.indication(43:xx:xx:xx:xx:b3, 2)
Sat Sep 12 02:40:49 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: authentication OK (open system)
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-AUTHENTICATE.indication(43:xx:xx:xx:xx:b3, OPEN_SYSTEM)
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep 12 02:44:26 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: authenticated
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: association OK (aid 3)
Sat Sep 12 02:44:26 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: associated (aid 3)
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-ASSOCIATE.indication(43:xx:xx:xx:xx:b3)
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 MLME: MLME-DELETEKEYS.request(43:xx:xx:xx:xx:b3)
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.11: binding station to interface 'wlan1'
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: event 1 notification
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: start authentication
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.1X: unauthorizing port
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: sending 1/4 msg of 4-Way Handshake
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: received EAPOL-Key frame (2/4 Pairwise)
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: sending 3/4 msg of 4-Way Handshake
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: received EAPOL-Key frame (4/4 Pairwise)
Sat Sep 12 02:44:26 2020 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 43:xx:xx:xx:xx:b3
Sat Sep 12 02:44:26 2020 daemon.debug hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 IEEE 802.1X: authorizing port
Sat Sep 12 02:44:26 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 RADIUS: starting accounting session 321E5FAE63C4AF41
Sat Sep 12 02:44:26 2020 daemon.info hostapd: wlan1: STA 43:xx:xx:xx:xx:b3 WPA: pairwise key handshake completed (RSN)

Might have just found out the culprit here. When disassoc_timer is set for like equal to 5min (informing that the AP will be gone in 5min, in a way forcing client to steer) and if the client doesn't get steered by then, it disconnects itself.

So I, for now, disabled disassociation timer parameter.

Update. Yes I sorted the issue out one-by-one by first polishing my roaming algorithm using beacon reports and new tweaks etc. and also fixes for example disassoc_timer option usage.

For the last few days, I think I completely fixed the phone disconnecting itself and/or phone steering itself to bad rssi AP problem, by simply using;

  1. basic_rates option
  2. dtim interval 1
  3. beacon interval 101 and 103
  4. disassoc on low ack 0
  5. disassoc on inactivity on for like 3-5min (need it for having clean station table)

And I guess that's it, though I think basic_rates option did the trick mostly, use "legacy rates" option is on 0 but that doesn't do anything for me. I might as well use "force 40MHz all time" option for 5GHz later on to test further.


I needed to manually edit hostapd.sh file by hand as below to make it work:

	if [ "$ifname" = "wlan0" ]; then
		append bss_conf "supported_rates=480 540" "$N"
		append bss_conf "basic_rates=480 540" "$N"	
	fi
	if [ "$ifname" = "wlan1" ]; then
		append bss_conf "supported_rates=120 180 240 360 480 540" "$N"
		append bss_conf "basic_rates=120 180 240 360 480 540" "$N"	
	fi

The trick was to set 5GHz basic rates no lower than 48 or 54Mbps, so phone's internal roaming algorithm wouldn't consider steering to it or got disconnected trying (they score everything internally rcpi to phy rate) and stay on 2GHz at distance.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.