Bug 75231 - ath9k AR9485: intemittent failure to WPA 4way 1st msg: did not Ack EAPOL-Key frame
Summary: ath9k AR9485: intemittent failure to WPA 4way 1st msg: did not Ack EAPOL-Key ...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-01 11:01 UTC by David Hubbard
Modified: 2016-05-03 06:04 UTC (History)
4 users (show)

See Also:
Kernel Version: ubuntu 3.13.11, linux-next
Subsystem:
Regression: No
Bisected commit-id:


Attachments
lspci -nnv (10.22 KB, text/plain)
2014-05-01 11:01 UTC, David Hubbard
Details
syslog showing the one time it succeeded (162.67 KB, text/plain)
2014-05-01 11:02 UTC, David Hubbard
Details
syslog of what it typically does, failure (1023.81 KB, text/plain)
2014-05-01 11:03 UTC, David Hubbard
Details

Description David Hubbard 2014-05-01 11:01:01 UTC
Created attachment 134561 [details]
lspci -nnv

After looking at the old https://bugzilla.kernel.org/show_bug.cgi?id=49201

And carefully studying https://bugzilla.kernel.org/show_bug.cgi?id=62381

I think this might be related to bug #62381 but this laptop does not have bluetooth.

Steps to reproduce:
1. AP: TP-Link TL-WDR3600 running openwrt-git. AR9341 2.4GHz radio in use.
2. AP kernel: 3.10.36, also using ath9k so I can collect any info needed
3. STA: HP m6-1035dx with AR9485, see attached lspci.txt
4. STA has linux mint, so using NetworkManager
5. STA kernel: ubuntu 3.13.11-5b61677 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git
6. STA: add "blacklist ath9k" in /etc/modprobe.d/foo so I can manually modprobe ath9k with debug flags. "modprobe ath9k nohwcrypt=1 debug=0x84f9" or just "modprobe ath9k nohwcrypt=1"
7. Check /sys/module/ath9k/parameters/*:
  /sys/module/ath9k/parameters/blink 0
  /sys/module/ath9k/parameters/bt_ant_diversity 0
  /sys/module/ath9k/parameters/btcoex_enable 0
  /sys/module/ath9k/parameters/nohwcrypt 1
  /sys/module/ath9k/parameters/ps_enable 0
8. Check: iw wlan0 get power_save
  Power save: off


Problem:
- Association (4 way WPA2 handshake) fails in the 1st step. Will attach syslog from AP and STA.


I tried setting nohwcrypt=0 and building linux-next-3.15.0-rc3 5337aa0 but didn't see any change.
Comment 1 David Hubbard 2014-05-01 11:02:37 UTC
Created attachment 134571 [details]
syslog showing the one time it succeeded
Comment 2 David Hubbard 2014-05-01 11:03:53 UTC
Created attachment 134581 [details]
syslog of what it typically does, failure
Comment 3 David Hubbard 2014-05-01 11:06:25 UTC
(In reply to David Hubbard from comment #0)
> "modprobe ath9k nohwcrypt=1 debug=0x84f9"

That was 0x8f49 actually, typo in submitting the bug report.
Comment 4 David Hubbard 2014-05-18 09:36:26 UTC
Some additional testing makes it seem like an 11n issue:

Fails to associate when STA "iw dev wlan0 link" is about -65 dBm or worse. When signal is better, it associates fine.

By forcibly disabling 802.11n modes (patch below) the STA connects from positions it failed before, and the RSSI improves from -78 dBm to -60 dBm (approximate).

diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 9eea982..3a4c4e4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -832,6 +832,8 @@ static void ath9k_init_txpower_limits(struct ath_softc *sc)
 
 void ath9k_reload_chainmask_settings(struct ath_softc *sc)
 {
+#if 0
+forcibly disable all 802.11n modes
 	if (!(sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT))
 		return;
 
@@ -839,6 +841,7 @@ void ath9k_reload_chainmask_settings(struct ath_softc *sc)
 		setup_ht_cap(sc, &sc->sbands[IEEE80211_BAND_2GHZ].ht_cap);
 	if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_5GHZ)
 		setup_ht_cap(sc, &sc->sbands[IEEE80211_BAND_5GHZ].ht_cap);
+#endif
 }
 
 static const struct ieee80211_iface_limit if_limits[] = {
Comment 5 Sujith 2014-10-28 03:03:44 UTC
Do you still see this issue with the latest kernel ?
Comment 6 David Hubbard 2014-10-28 04:10:16 UTC
I will check tomorrow. I *think* so.
Comment 7 David Hubbard 2014-10-28 22:11:44 UTC
Still showing the same problem. See "Steps to Reproduce" from comment #0 with the following changes:

5. STA kernel: ubuntu-3.16.4-92a0e72 cloned from git://kernel.ubuntu.com/ubuntu/ubuntu-vivid.git

Problem:

1. Association only works when RSSI measures approx -78 dBm

2. The rest of the STA's I have access to report much better RSSI (approx -50 dBm) in the same physical location.

3. The link quality is poor at this location, approx 20KB/s and about 750ms latency.

4. The AP reports constant dissociations:

Tue Oct 28 22:03:28 2014 daemon.info hostapd: wlan0: STA 44:6d:57:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs
Tue Oct 28 22:03:29 2014 daemon.info hostapd: wlan0: STA 44:6d:57:xx:xx:Xx IEEE 802.11: authenticated
Tue Oct 28 22:03:29 2014 daemon.info hostapd: wlan0: STA 44:6d:57:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Oct 28 22:03:31 2014 daemon.info hostapd: wlan0: STA 44:6d:57:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Comment 8 Sujith 2014-10-29 04:53:19 UTC
Can you test the latest backports driver ?

http://www.kernel.org/pub/linux/kernel/projects/backports/2014/10/23/backports-20141023.tar.xz

Installation instructions are here:
https://backports.wiki.kernel.org/index.php/Documentation

Use the "ath9k-debug" config to build the driver:
make defconfig-ath9k-debug && make && sudo make install

With this driver, please post the contents of these files:

/sys/kernel/debug/ieee80211/phy*/ath9k/base_eeprom
/sys/kernel/debug/ieee80211/phy*/ath9k/modal_eeprom
/sys/kernel/debug/ieee80211/phy*/ath9k/interrupt
/sys/kernel/debug/ieee80211/phy*/ath9k/recv
/sys/kernel/debug/ieee80211/phy*/ath9k/phy_err
/sys/kernel/debug/ieee80211/phy*/ath9k/xmit
/sys/kernel/debug/ieee80211/phy*/ath9k/reset
/sys/kernel/debug/ieee80211/phy*/ath9k/misc
Comment 9 David Hubbard 2014-10-29 05:17:39 UTC
I'll do the build you suggest this weekend.
Comment 10 Kishan G 2016-05-03 06:04:21 UTC
(In reply to David Hubbard from comment #9)
> I'll do the build you suggest this weekend.

Have you looked further into it?
I am facing the same issue.

Note You need to log in before you can comment on or make changes to this bug.