Wifi connectivity issues with ath10k

Hi :slight_smile:

This topic is about a connection drop that happens with ath10k stations.
Clients are able to connect but after a few seconds they disconnect.
It appears an important beacon is not sent in time/at all.
Tested with Linux, apple, and android clients and a Compex WPJ428 station.

Debug information:

  • there are ap (openwrt) and station (linux) syslogs [1,2]
  • i created a dump using a monitor interface. The beacon isn't in there which indicates to me that it is never sent and there's a bug with ath10k
  • my wireless config [4]

Things i've tried without success:

  • on the Arch LInux bug tracker, there's a suggestion for reducing the beacon interval [3] - that didn't help me
  • compiling various combinations of openwrt-trunk (now and early March) / 19.07 and ath10k stock / ct driver / firmware
  • increased basic_rate/supported_rates

one cange leads to a working state:

  • disabling the mesh networks (one for each radio) - disabling aps doesn't help

My conclusion is that this is an ath10k bug - for both stock and candelatech.
Does anyone have an idea what to do with this or any other workarounds?

kind regards

attachments:

[1] openwrt syslog

Thu Jun 25 22:45:09 2020 daemon.notice hostapd: nw24_0-1: AP-STA-DISCONNECTED 88:ad:d2:f5:a4:02
Thu Jun 25 22:45:09 2020 daemon.info hostapd: nw24_0-1: STA 88:ad:d2:f5:a4:02 IEEE 802.11: authenticated
Thu Jun 25 22:45:09 2020 daemon.info hostapd: nw24_0-1: STA 88:ad:d2:f5:a4:02 IEEE 802.11: associated (aid 1)
Thu Jun 25 22:45:09 2020 daemon.notice hostapd: nw24_0-1: AP-STA-CONNECTED 88:ad:d2:f5:a4:02
Thu Jun 25 22:45:09 2020 daemon.info hostapd: nw24_0-1: STA 88:ad:d2:f5:a4:02 RADIUS: starting accounting session 32B8DDB036C1A557
Thu Jun 25 22:45:09 2020 daemon.info hostapd: nw24_0-1: STA 88:ad:d2:f5:a4:02 WPA: pairwise key handshake completed (RSN)
^[[AThu Jun 25 22:45:41 2020 daemon.info hostapd: nw24_0-1: STA 88:ad:d2:f5:a4:02 IEEE 802.11: disconnected due to excessive missing ACKs
Thu Jun 25 22:45:41 2020 daemon.notice hostapd: nw24_0-1: AP-STA-DISCONNECTED 88:ad:d2:f5:a4:02
Thu Jun 25 22:46:11 2020 daemon.info hostapd: nw24_0-1: STA 88:ad:d2:f5:a4:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

[2] linux syslog

Jun 26 00:16:20 brot kernel: wlan0: authenticated
Jun 26 00:16:20 brot kernel: wlan0: associate with 06:f0:21:4e:1f:54 (try 1/3)
Jun 26 00:16:20 brot wpa_supplicant[483]: wlan0: Associated with 06:f0:21:4e:1f:54
Jun 26 00:16:20 brot kernel: wlan0: RX AssocResp from 06:f0:21:4e:1f:54 (capab=0x431 status=0 aid=2)
Jun 26 00:16:20 brot kernel: wlan0: associated
# networkmanager, psk, and such
Jun 26 00:16:21 brot kernel: iwlwifi 0000:04:00.0: No beacon heard and the time event is over already...
Jun 26 00:16:21 brot kernel: wlan0: Connection to AP 06:f0:21:4e:1f:54 lost

[3] https://bugs.archlinux.org/task/58457

[4] /etc/config/wireless (with stock ath10k, mode is mesh instead of adhoc)


config wifi-device 'radio24_0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/soc/a000000.wifi'
	option htmode 'HT20'
	option country 'DE'
	option phyref 'phy0'
	option channel '13'

config wifi-device 'radio5_0'
	option type 'mac80211'
	option channel '40'
	option hwmode '11a'
	option path 'platform/soc/a800000.wifi'
	option country 'DE'
	option phyref 'phy1'
	option htmode 'VHT40'

config wifi-iface 'w24_0_1'
	option mode 'ap'
	option ifname 'nw24_0-1'
	option device 'radio24_0'
	option network 'n_1'
	option encryption 'psk2'
	option isolate '0'
	option hidden '0'
	option key 'testtest'
	option ssid 'mpsk test'

config wifi-iface 'w5_0_1'
	option mode 'ap'
	option ifname 'nw5_0-1'
	option device 'radio5_0'
	option network 'n_1'
	option encryption 'psk2'
	option isolate '0'
	option hidden '0'
	option key 'testtest'
	option ssid 'mpsk test'

config wifi-iface 'mesh24_0'
	option ifname 'mesh24_0'
	option network 'mesh24_0'
	option encryption 'psk2'
	option ssid 'nom'
	option bssid '02:BA:CC:11:55:90'
	option key 'cookcake'
	option mode 'adhoc'
	option device 'radio24_0'

config wifi-iface 'mesh5_0'
	option ifname 'mesh5_0'
	option network 'mesh5_0'
	option encryption 'psk2'
	option ssid 'nom'
	option bssid '02:BA:CC:11:55:90'
	option key 'cookcake'
	option mode 'adhoc'
	option device 'radio5_0'

1 Like

Please show the output of:

iw phy0 info | grep 'valid interface combinations' -A 3 && iw phy1 info | grep 'valid interface combinations' -A 3

hello - and sure:

 $ iw phy | grep 'valid interface combinations' -A 3
        valid interface combinations:
                 * #{ managed } <= 16, #{ AP, mesh point } <= 16, #{ IBSS } <= 1,
                   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }

--
        valid interface combinations:
                 * #{ managed } <= 16, #{ AP, mesh point } <= 16, #{ IBSS } <= 1,
                   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }

Yeah, this is unfortunately really rearing its head on my Unifi AC Lite running 19.07.x. I tried downgrading to 18.x because I really didn't remember this being a problem but it's even worse there. Perhaps a point update to the 18 series introduced the bug.

i know this kinda old and probably a nofix because it's likely either a driver or a hardware issue and ath11k is already out of the box...

i just wanted to make available the information that we've seeked out a consultant who told us that would be a pain to go through the process of getting a fix with candelatech and entirely unrealistic to get a fix for the official firmware.
the resulting strategy was to use ath9k when mesh+ap was required on one radio or add an extra card for mesh installations that need the increased bandwidth (additional effect is that they don't have to share channels).

here and there, people pop up having the same issue but also the chances that this will be fixed are going down.
i'll close this thread.

1 Like

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