Bug 98391 - ath9k: chance of failing to install unicast encryption key under heavy load
Summary: ath9k: chance of failing to install unicast encryption key under heavy load
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: Mips32 Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
Depends on:
Reported: 2015-05-14 23:42 UTC by Alexis Green
Modified: 2016-02-15 21:54 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.18.11 (OpenWRT trunk r45676)
Tree: Mainline
Regression: No


Description Alexis Green 2015-05-14 23:42:44 UTC
When testing encrypted mesh functionality under heavy load (maxing out the channel), there is a strong possibility that unicast key does not get installed properly into hardware.

This test has been done using OpenWRT trunk @ svn revision r45676 Repros on TP-Link WDR-4300 hardware, specifically 5Ghz phy ( Atheros AR9340 Rev:2 ). It also reproduces on another piece of hardware running earlier version of OpenWRT ( Atheros AR9280 Rev:2 )

To reproduce, set authsae "lifetime" to a small number of seconds (I've used 30 seconds) then initiate TCP iperf test across the mesh link. With iperf in the background, initiate ICMP ping between the two nodes. Observe pings stop at the rekeying and coming back on the next rekey. Loading ath9k with "nohwcrypt=1" resolves the issue at cost of greatly reduced throughput.

Instrumented code to print out key being installed at authsae, mac80211, and ath9k levels show that correct key is passed all the way down to hardware. Performing REG_READ on the installed key immediately after REGWRITE_BUFFER_FLUSH in ath_hw_set_keycache_entry() indicates that correct key is in the key register. Making authsae daemon instal same key again after waiting for one second reduces the occurrence of the problem, but does not eliminate it.

This build of OpenWRT uses compat-wireless-2015-03-09

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