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)
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.)
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.
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
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.
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.
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
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.
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.
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.
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
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???
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...