AR9344 Wireless Issue -


#1

Hi all. I have a LEDE 17.01.04 device with an Atheros AR9344 wi-fi chipset. I've been experiencing an issue - where after approximately 24 hours, I loose Wi-Fi connectivity. An up/down of the wireless or reboot of the router becomes necessary.

Does anyone have any ideas?

My log:

Sat Nov 11 13:52:54 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: group key handshake completed (RSN)
Sat Nov 11 13:57:57 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs
Sat Nov 11 13:57:57 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Sat Nov 11 13:58:27 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

It appears this has been noted before:

https://forum.openwrt.org/viewtopic.php?id=43188
https://dev.openwrt.org/ticket/12372
https://dev.openwrt.org/ticket/19648
https://dev.openwrt.org/ticket/19741
https://dev.openwrt.org/ticket/19799
https://dev.openwrt.org/ticket/19885

I've added:

option disassoc_low_ack '0'

To my SSID today. I'll be monitoring for any changes and/or improvement.

Currently installed: hostapd-common 2016-12-19-ad02e79d-6


#2

It happened again, I am now expriencing a similar issue as here: Associated station showing connection when client not present

I had 2 clients connected, I no longer see the AP on air, and I have turned off the WiFi on one device.

After about 5 minutes, the 2nd device disappeared. After some more time, the device I mentioned above disconnected.

Sun Nov 12 12:28:38 2017 daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 WPA: group key handshake completed (RSN)
Sun Nov 12 12:28:38 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: group key handshake completed (RSN)
Sun Nov 12 12:34:17 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 00:00:00:00:00:02
Sun Nov 12 12:34:17 2017 daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: disassociated due to inactivity
Sun Nov 12 12:34:18 2017 daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 12 12:34:28 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Sun Nov 12 12:34:28 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated due to inactivity
Sun Nov 12 12:34:29 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

(00:00:00:00:00:02 is another LEDE device, I haven't placed a bug report yet - the WiFi uses an arbitrary MAC/BSSID address.)


#3

My Archer C7 v2 has the similar issue on 2.4G wifi. The chip is QCA9558 which shares same driver as AR9344. However I just do down/up every 3 hours in cron to work it around.
My sw is built on LEDE 17.01 branch.


#4

Thanks for the info on a workaround. Do you happen to have a copy of the script?

I'm not sure this will work for me as a permanent workaround, since an Up/Down changes ID of the interfaces in SNMP.

Are there any supported WiFi chipsets without known issues?


#5

Here it is. Suppose ifconfig will not change anything (IP/route) other than controlling the network interface. If use ifdown/ifup could bring more side effect.

root@LEDE-C7:~# cat /etc/crontabs/root
0 */3 * * * ifconfig wlan1 down && sleep 1 && ifconfig wlan1 up

#6

For the question "Are there any supported WiFi chipsets without known issues?" I feel the answer is NO. But that is why you use OpenWrt/Lede. Some issues you can wait for the fix from community. Some of them you can work around. Those can never be expected from stock firmware.


#7

OK, I've removed:

I had a distance optimization of 50, I increased this to 100 (if I leave this blank, I start to have packet loss when testing with ping flood...)

When increasing the distance optimization to 100, I noticed that the Coverage Class changed to:

Coverage class: 1 (up to 450m)

I will monitor this setting.

BTW: I've noticed that dynamic ACK calculation is done in ath5k and ath9k...maybe this setting will fix my problem, as having a Coverage class set should disable dynack.


#8

It occurred again. At the time, I could not wait for the log, I associated with another AP.

  • clients loose LAN and WAN connectivity
  • the AP appears and disappears for approximately 5 minutes
  • the AP completely disappears from the air
  • clients disassociate

I'm thinking a few things are happening; but mainly, that I have an extremely congested 2.4 spectrum in my neighborhood, and there's always certain settings I configured in such an environment. I'll place a copy and inform you of the results (other than the increase in bandwidth I've experienced). I also enabled a few of the Atheors-only features (bursting, fast frames and compression). See: http://madwifi-project.org/wiki/ChipsetFeatures/SuperAG

root@LEDE:~# uci show wireless.radio0
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.hwmode='11g'
wireless.radio0.path='platform/ar934x_wmac'
wireless.radio0.txpower='7'
wireless.radio0.country='US'
wireless.radio0.htmode='HT40'
wireless.radio0.distance='100'
wireless.radio0.frag='2346'
wireless.radio0.beacon_int='75'
wireless.radio0.ieee80211w='1'
wireless.radio0.dtim_period='3'
wireless.radio0.bursting='1'
wireless.radio0.compression='1'
wireless.radio0.ff='1'
wireless.radio0.rts='784'
#I removed the channel option from the Paste

See: https://lede-project.org/docs/user-guide/wifi_configuration
and: https://wiki.openwrt.org/doc/uci/wireless
https://tutorials.technology/tutorials/45-Improving-WiFi-performance-on-Linux-LEDE.html


#9

LEDE using mac80211 kernel driver, not use old madwifi driver. Don't add madwifi options.
I have wr841n device (same ar9344) working very stable with 17.01.4. I recommend that you try to make sure everything is stable or not with default settings.

This tutorials https://tutorials.technology/tutorials/45-Improving-WiFi-performance-on-Linux-LEDE.html is very bad idea.


#10

Thanks, I was confused by that. Especially the date on the link I provided (2017).

Is there any way to access these features of the Ahteros chipset, then?


#11

LEDE dropped madwifi support, see: https://github.com/openwrt/luci/issues/995


#12

I understand that. The documentation says that, it also allows you to add these options on UCI.

Does that mean there's no way to enable these options with mac80211 in use???


#13

What documents ? The openwrt wiki is old. LEDE docs doesn't say that.


#14

The document you just showed me says that. And I noted that the setting is in my UCI, meaning, IT ALLOWED ME TO CONFIGURE IT. Anyways, you're missing me. Forget madwifi, I know that LEDE uses mac80211.

My question: Using mac80211, can the SuperAG (bursting, compression and fast frames) features be enabled?

How can I access the hardware registers to turn them on...or were these features of the old driver???

Not counting Atheros settings, I changed from default:

These were configs that I commonly changed on other APs to get better service.


#15

If I remember correctly, SuperAG is a ar5xx ath5k chipset family. Your device using AR9xxx ath9k chipset family.


#16

Thanks. That information helps.

I believe my issue is 2.4 GHz noise from other APs. I placed my device on a shared channel and edited the settings above. I've seen significant bandwidth improvement already. I'll see if this fixes my interment issue with the AP dropping clients due to a timeout on 'non-received' ACKs, as my RTS should kick in and clear the channel.


#17

I now have something different happening:

System log:

Wed Nov 22 19:12:45 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Wed Nov 22 19:12:45 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Wed Nov 22 19:12:46 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 2)
Wed Nov 22 19:12:46 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 2)
Wed Nov 22 19:12:46 2017 daemon.notice hostapd: wlan0: AP-STA-POSSIBLE-PSK-MISMATCH xx:xx:xx:xx:xx:xx
Wed Nov 22 19:12:47 2017 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Wed Nov 22 19:12:47 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Wed Nov 22 19:12:48 2017 daemon.info dnsmasq-dhcp[2323]: DHCPDISCOVER(br-lan) xx:xx:xx:xx:xx:xx
Wed Nov 22 19:12:48 2017 daemon.info dnsmasq-dhcp[2323]: DHCPOFFER(br-lan) 192.168.1.xxx xx:xx:xx:xx:xx:xx
Wed Nov 22 19:12:48 2017 daemon.info dnsmasq-dhcp[2323]: DHCPREQUEST(br-lan) 192.168.1.xxx xx:xx:xx:xx:xx:xx
Wed Nov 22 19:12:48 2017 daemon.info dnsmasq-dhcp[2323]: DHCPACK(br-lan) 192.168.1.xxx xx:xx:xx:xx:xx:xx
Wed Nov 22 19:14:45 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Wed Nov 22 19:14:45 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 00:00:00:00:00:02
Wed Nov 22 19:14:50 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Wed Nov 22 19:14:50 2017 daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: deauthenticated due to local deauth request

Kernel log:
[32129.458450] device wlan0 left promiscuous mode
[32129.463196] br-lan: port 3(wlan0) entered disabled state
[32131.382680] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[32131.520993] device wlan0 entered promiscuous mode
[32133.946237] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[32133.952970] br-lan: port 3(wlan0) entered forwarding state
[32133.958583] br-lan: port 3(wlan0) entered forwarding state
[32135.951031] br-lan: port 3(wlan0) entered forwarding state

This seems to have been reported before also:

https://dev.openwrt.org/ticket/10025
https://dev.openwrt.org/ticket/11747


Also has some options in the wrong section. Here are the current edits:

wifi-device:

option distance '100'
option frag '2346'
option beacon_int '75'
option rts '784'

wifi-iface:

option dtim_period '3'
option wpa_group_rekey '3600'
option wpa_disable_eapol_key_retries '1'

I'll watch.


#18

OK...

Mon Nov 27 21:48:47 2017 daemon.info hostapd: wlan0: STA 30:96:fb:7b:e0:6d IEEE 802.11: disconnected due to excessive missing ACKs
Mon Nov 27 21:48:47 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 30:96:fb:7b:e0:6d
Mon Nov 27 21:49:17 2017 daemon.info hostapd: wlan0: STA 30:96:fb:7b:e0:6d IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

From here, I did the following:

  • Removed: option wpa_disable_eapol_key_retries ‘1’
  • Changed power from a low setting to auto
  • I observed that when changing to "auto," the WiFi was at full power

AS OF NOW: I haven't had ACK or rekey issues on the xx:xx:xx:xx:xx:xx device since, nor had the WiFi AP dissappeard from the air; but the WiFi had dropped on the client. When it occurs now, the 00:00:00:00:00:02 device says connected. A stop and start of the xx:xx:xx client's WiFi successfully reconnects. I'm more convinced that it's just a congested 2.4 GHz band in my neighborhood.

At this point, it appears to be power/congested channels. I'll watch a few more days. Can anyone else who has this issue confirm their power setting, and if it can be increased, try it???


#19

OK, here we go again...

Sun Dec 3 09:54:13 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs
Sun Dec 3 09:54:13 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Sun Dec 3 09:54:43 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Dec 3 09:59:13 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 00:00:00:00:00:02
Sun Dec 3 09:59:13 2017 daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: disassociated due to inactivity
Sun Dec 3 09:59:14 2017 daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

But...the AP stayed on noticeably longer...and my xx:xx:xx device continued to read "An Authentication Error Occurred" before the AP eventually disappeared.

I've added:

option log_level '0'

I've verified I see level 0 and 1 hostapd log events now. I'll keep watching...


#20

Do you have any updates on this problems ?