Ath9k on Archer C7 v2: disassociated due to inactivity

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 :confused:

Thank you for your time!

1 Like

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

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!

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.

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.

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

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

Yes. A c5 v1(same as c7 v2)

Disabling Legacy rates and disassoc_low_ack doesn't fix it

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

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.

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.

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

1 Like

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.

1 Like

Hello fellas,

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

And:

Please feel free to share your thoughts.

With Metta
:pray:

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

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.

1 Like