Bug 98391

Summary: ath9k: chance of failing to install unicast encryption key under heavy load
Product: Drivers Reporter: Alexis Green (agreen)
Component: network-wirelessAssignee: drivers_network-wireless (drivers_network-wireless)
Status: NEW ---    
Severity: normal CC: ath9k-devel, linville, szg00000, th0ma7, yuwen.huang
Priority: P1    
Hardware: Mips32   
OS: Linux   
Kernel Version: 3.18.11 (OpenWRT trunk r45676) Subsystem:
Regression: No Bisected commit-id:

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