AR9344 Wireless Issue -

Installing and Using OpenWrt Network and Wireless Configuration
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.

1 Like
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
1 Like
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.

2 Likes
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.

1 Like
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.

1 Like
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 ?

21

This thread is a year old. I don't have problems any longer - the issue was congestion on the band. Changing to a clearer channel solved my problem.