Ath9k on Archer C7 v2: disassociated due to inactivity

PlqnK · April 7, 2018, 3:48pm

Hi!
For a couple of months now I have a recurring problem with the 2.4Ghz Wi-Fi of my TP-Link Archer C7 v2 router. Every couple of days all my clients gets disconnected and it's impossible for them to reconnect, they can still see the SSID but when you try to connect nothing happens.
I already had this problem before but it was fixed sometime last year and came back pretty recently. I came back from my vacation at the end of february, I upgraded my router (via opkg) and the problem started reappearing.

When I check my system logs there's this:

Fri Apr  6 22:46:39 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED AA:AA:AA:AA:AA:AA
Fri Apr  6 22:46:39 2018 daemon.info hostapd: wlan1: STA AA:AA:AA:AA:AA:AA IEEE 802.11: disassociated due to inactivity
Fri Apr  6 22:46:39 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED BB:BB:BB:BB:BB:BB
Fri Apr  6 22:46:39 2018 daemon.info hostapd: wlan1: STA BB:BB:BB:BB:BB:BB IEEE 802.11: disassociated due to inactivity
Fri Apr  6 22:46:40 2018 daemon.info hostapd: wlan1: STA AA:AA:AA:AA:AA:AA IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Apr  6 22:46:40 2018 daemon.info hostapd: wlan1: STA BB:BB:BB:BB:BB:BB IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Apr  6 22:46:45 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED CC:CC:CC:CC:CC:CC
Fri Apr  6 22:46:45 2018 daemon.info hostapd: wlan1: STA CC:CC:CC:CC:CC:CC IEEE 802.11: disassociated due to inactivity
Fri Apr  6 22:46:46 2018 daemon.info hostapd: wlan1: STA CC:CC:CC:CC:CC:CC IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Apr  6 22:46:50 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED DD:DD:DD:DD:DD:DD
Fri Apr  6 22:46:50 2018 daemon.info hostapd: wlan1: STA DD:DD:DD:DD:DD:DD IEEE 802.11: disassociated due to inactivity
Fri Apr  6 22:46:51 2018 daemon.info hostapd: wlan1: STA DD:DD:DD:DD:DD:DD IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Apr  6 22:46:57 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED EE:EE:EE:EE:EE:EE
Fri Apr  6 22:46:57 2018 daemon.info hostapd: wlan1: STA EE:EE:EE:EE:EE:EE IEEE 802.11: disassociated due to inactivity
Fri Apr  6 22:46:58 2018 daemon.info hostapd: wlan1: STA EE:EE:EE:EE:EE:EE IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

And when I check my kernel logs there's this:

[338387.915320] ------------[ cut here ]------------
[338387.920136] WARNING: CPU: 0 PID: 0 at compat-wireless-2017-01-31/net/mac80211/rx.c:4214 0x875a5cf0 [mac80211@87580000+0x607a0]()
[338387.931983] Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]: 89 (0x59)
[338387.941594] Modules linked in: pppoe ppp_async iptable_nat ath9k pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE     ath9k_common xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp     xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect     nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt ath9k_hw sch_cake     nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress ath10k_pci ath10k_core ath mac80211     cfg80211 compat ledtrig_usbport ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables ifb tun ehci_platform ehci_hcd     gpio_button_hotplug usbcore nls_base usb_common
[338388.032799] CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.4.92 #0
[338388.039953] Stack : 803875b4 00000000 00000001 803e0000 00000000 00000000 00000000 00000000
[338388.039953] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[338388.039953] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[338388.039953] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[338388.039953] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[338388.039953] 	  ...
[338388.076393] Call Trace:[<80071a8c>] 0x80071a8c
[338388.081008] [<80071a8c>] 0x80071a8c
[338388.084646] [<80081888>] 0x80081888
[338388.088282] [<875a5cf0>] 0x875a5cf0 [mac80211@87580000+0x607a0]
[338388.094391] [<800818e4>] 0x800818e4
[338388.098045] [<875a5cf0>] 0x875a5cf0 [mac80211@87580000+0x607a0]
[338388.104141] [<80260a70>] 0x80260a70
[338388.107769] [<80260c54>] 0x80260c54
[338388.111403] [<87748388>] 0x87748388 [ath9k_common@87748000+0x4800]
[338388.117790] [<876477f4>] 0x876477f4 [ath9k@87640000+0x16650]
[338388.123633] [<876477d4>] 0x876477d4 [ath9k@87640000+0x16650]
[338388.129485] [<87644a44>] 0x87644a44 [ath9k@87640000+0x16650]
[338388.135321] [<80084448>] 0x80084448
[338388.138947] [<80083e04>] 0x80083e04
[338388.142578] [<800a8014>] 0x800a8014
[338388.146221] [<8006a990>] 0x8006a990
[338388.149851] [<80060bf8>] 0x80060bf8
[338388.153472] 
[338388.155075] ---[ end trace b3f3d64bb3f3d64b ]---

That I think might be related.

Here's my wireless configuration:

root@Nexus:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'pci0000:01/0000:01:00.0'
        option htmode 'VHT80'
        option channel '128'
        option txpower '20'
        option country 'FR'
        option distance '11'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'Skynet'
        option key 'XXXXXXXX'
        option encryption 'psk2+ccmp'
        option macfilter 'allow'
        list maclist 'XX:XX:XX:XX:XX:XX'

config wifi-iface 'station_radio0'
        option device 'radio0'
        option network 'wwan'
        option mode 'sta'
        option encryption 'psk-mixed+tkip+ccmp'
        option key 'XXXXXXXX'
        option ssid 'Livebox-1220'
        option disabled '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/qca955x_wmac'
        option htmode 'HT20'
        option txpower '20'
        option country 'FR'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'Genisys'
        option encryption 'psk2+ccmp'
        option key 'XXXXXXXX'
        option macfilter 'allow'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'
        list maclist 'XX:XX:XX:XX:XX:XX'

config wifi-iface
        option device 'radio1'
        option mode 'ap'
        option ssid 'Ultron'
        option network 'guest'
        option key 'XXXXXXXX'
        option encryption 'psk2+ccmp'

I'm pretty sure this regression made it's way in one of the update that was made available between the 4th and the 20th of february, because I updated my router before leaving and everything was fine and I updated pretty much as soon as I came back and the problem came back.

Is there any workaround or fix possible? Should I fill a "real" bug on the bugtracker?

My current workaround is to restart the router or the Wi-Fi interface and I guess I could add that to my crontab but that's not a satisfying solution really

Thank you for your time!

silentcreek · April 7, 2018, 6:13pm

You might wanna try the wireless option disassoc_low_ack=0. It's a long time since I had issues with clients losing their connection to my Archer C7 v2, but I remember setting this option fixed it. See: https://wiki.openwrt.org/doc/uci/wireless#inactivity_timeout_options

PlqnK · April 9, 2018, 7:19am

Alright I will try it! I didn't tried it beforehand because the people reporting that it fixed their problem also had the line disconnected due to excessive missing ACKs in their logs which is not my case. Also my kernel log seems to indicate a crash of some sort in the ath9k driver and the problem those people encountered was that their clients got disconnected every 30 or so minutes whereas mine only get disconnected every 2 or 3 days.
I also just find it strange that it worked fine without it until february.

But I will try it anyway and report back, thanks for your help!

zorxd · July 20, 2019, 2:15am

So how did it work out for you?
I seem to have a similar problem with the same router. OpenWRT 18.06.4.
Only on the 2.4 GHz radio so far. I restart the radio and clients reconnect. My clients are fixed and well within range so I never expect them to disconnect. But of course if they do, I expect them to reconnect which isn't the case here.

I don't have the kernel oops in my logs however. It can work for days before I need to reset the radio, so it's hard to reproduce.

I'll try the option disassoc_low_ack '0' trick to see if it helps.

zorxd · July 21, 2019, 12:49am

OK so I confirm I get the bug even after setting option disassoc_low_ack '0' so it doesn't help.

I didn't really have these issues before. I added a new client recently. I still don't understand how a single client could jam my access point, and prevent other clients from connecting until I restart the AP.
Still never happened on my 5 GHz radio either.

Magnets · July 21, 2019, 5:46pm

I have the same problem and the disassoc_low_ack doesn't fix it. I see others saying that disabling the option "Allow legacy 802.11b rates" fixes it. I'm testing that now

zorxd · July 21, 2019, 6:22pm

well it didn't fix it for me
Do you also have the Archer C7 and having the problem only on 2.4 GHz?

Magnets · July 21, 2019, 7:25pm

Yes. A c5 v1(same as c7 v2)

Magnets · July 25, 2019, 8:47am

Disabling Legacy rates and disassoc_low_ack doesn't fix it

Magnets · July 25, 2019, 12:22pm

Some links for reference:
https://www.gargoyle-router.com/phpbb/viewtopic.php?t=11289

github.com/openwrt/mt76

MT7628: Clients keep disconnecting.

opened 02:27AM - 06 May 18 UTC

closed 09:04AM - 27 Mar 19 UTC

yujincheng08

I have a HC5661A using MT7628. I've just test the latest commit e2eedc92 and it'…s very unstable. I connect my xperia phone to the wifi and it keeps disconnected around every 10 minutes. And the log keeps showing: ``` WPA: group key handshake completed (RSN) ``` I google for a solution and I added the followings to `/etc/config/wireless` ``` option wmm '0' option wpa_group_rekey '0' option wpa_pair_rekey '0' option wpa_master_rekey '0' ``` Things become better. But after 18-20 hours, clients disconnect again and the AP disappears from the air. I reference to the log and it shows: ``` hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs ``` I asked google for help again and added the following line to `/etc/config/wireless`: ``` option disassoc_low_ack '0' ``` After a few days testing, clients also keep disconnected, the log did not show something related to ACKs but: ``` hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: disassociated due to inactivity daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx ``` BTW, when clients disconnected, only rebooting recover the AP. The full `/etc/config/wireless`: ``` config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/10300000.wmac' option htmode 'HT20' option country '00' option legacy_rates '1' config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option ssid 'LEDE' option wmm '0' option encryption 'psk-mixed' option key 'keep it secret' option wpa_group_rekey '0' option wpa_pair_rekey '0' option wpa_master_rekey '0' option disassoc_low_ack '0' ```

andresrecalde · July 28, 2019, 1:01am

Same exact problem on my C5 V1 (OpenWrt 18.06.4 r7808-ef686b7292). 2.4Ghz only. Happened with 18.02 and I upgraded hoping it would fix, but it hasn't.

PlqnK · August 12, 2019, 12:03pm

I didn't have the time to try the disassoc_low_ack before and I've seen that it didn't work for you.

I've moved to a new flat last year which is smaller than the last one and I get 5 GHz coverage in all the rooms, so I just disabled the 2.4 GHz radio.

zorxd · September 27, 2019, 1:42am

I am still experiencing this issue. Hopefully the next major release will fix this.

JonP · September 27, 2019, 5:26am

As have I, though its been working without a problem lately. Have the 2.4gHz radio go non responsive, with a crash notice, and without. Have had the 5gHz radio do the same. Reboot fixes it, while sometimes restarting the interface does or does not fix things.

Ive been running the C7 as a dumb AP, since I got a Zotac CI327 and run that as the router. C7 and CI327 run 18.06.4. Have logs and such, if anyone wants them.

amituofo · September 23, 2021, 6:56am

Hello fellas,

is this still a bug today? After some digging, this should have been resolved as of now, please see:

github.com/freifunk-gluon/gluon

ath9k devices run out of memory above certain client count

opened 04:01PM - 25 Jun 19 UTC

closed 07:26PM - 28 Aug 20 UTC

mweinelt

0. type: bug

### Bug report #### Welcome to "Debugging out of memory situations" 2019 Edition! **What is the problem?** Devices with ath9k radios seem to be quickly running out of memory as soon as they reach a certain client count. Running `wifi` causes the memory to be temporarily freed again, but does not prevent the device from leaking. Example: Archer C7 v2 looses ~68 MB of normally free RAM in roughly 20 minutes, then OOM reboots, multiple times https://stats.darmstadt.freifunk.net/d/000000021/router-meshviewer-export?orgId=1&var-node=f4f26d707c53&refresh=15m ![c7v2-clients](https://user-images.githubusercontent.com/131599/60113371-ecb69c80-9771-11e9-899f-b3202ca1e3c6.png) ![c7v2-loadmemory](https://user-images.githubusercontent.com/131599/60113372-ecb69c80-9771-11e9-85e4-768b5bd49a57.png) ![c7v2-uptime](https://user-images.githubusercontent.com/131599/60113373-ed4f3300-9771-11e9-9306-2cb33da90c03.png) Other affected nodes are: - 1043N v3 https://stats.darmstadt.freifunk.net/d/000000021/router-meshviewer-export?orgId=1&var-node=f4f26d3e9cac&refresh=15m - CPE210 v1.1 https://stats.darmstadt.freifunk.net/d/000000021/router-meshviewer-export?orgId=1&var-node=8416f96a33dc&refresh=15m  **What is the expected behaviour?** Memory usage should increase at a reasonable rate per client  **Gluon Version:**  v2018.2.1-7-geed810aa **Site Configuration:**  https://git.darmstadt.ccc.de/ffda/site/tree/v2018.2.x **Custom patches:**  none

And:

github.com/torvalds/linux

mac80211: simplify TX aggregation start

committed 09:12AM - 02 Oct 19 UTC

jmberg

+39 -35

There really is no need to make drivers call the ieee80211_start_tx_ba_cb_irqsaf…e() function and then schedule the worker if all we want is to set a bit. Add a new return value (that was previously considered invalid) to indicate that the driver is immediately ready for the session, and make drivers use it. The only drivers that remain different are the Intel ones as they need to negotiate more with the firmware. Link: https://lore.kernel.org/r/1570007543-I152912660131cbab2e5d80b4218238c20f8a06e5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Please feel free to share your thoughts.

With Metta

amituofo · September 24, 2021, 8:03am

Update:

A quick search of ath9k updates shows that the above fixes have not been applied, could any one help??

https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=commit&s=ath9k

JonP · October 6, 2021, 6:11pm

I am very much not an expert, but after reading thru the comments on the first one you mention, that sounds like its a memory leak type of issue, and the symptom seems to be the whole router goes OOM and reboots. That's not our issue, so it's not as likely to have a connection to our issue.

The second one, there's no mention about what kind of symptom it would cause, or even if it does cause one. Again, no expert, but it sounds like this might just improve efficiency, vs solve a visible problem. I can't tell from here, without any discussion, since I don't know how that part of the software works.