[ath9k-devel] ath9k: chance of failing to install unicast encryption key under heavy load

[ath9k-devel] ath9k: chance of failing to install unicast encryption key under heavy load

[Alexis Green]

Good <time of day>,

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.

I can provide my openwrt build .config, image, and node configuration if
that helps.

P.S. Possibly manifestation of the same problem -
http://lists.shmoo.com/pipermail/hostap/2014-November/031377.html

Thank you all,
Alexis Green
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20150514/47431c8a/attachment.htm 

[ath9k-devel] ath9k: chance of failing to install unicast encryption key under heavy load

[Adrian Chadd]

Hi,

Try writing something that periodically checks if the key is in there.
I have a feeling that I've seen this bug in the reference driver, and
they "fixed" it by noticing decrypt failures for a given destination
and replumbing the key if it didn't match. :(

(I always wondered if this would ever surface as a real issue..)


-adrian

[ath9k-devel] ath9k: chance of failing to install unicast encryption key under heavy load

[Alexis Green]

Thank you Adrian,

Could you point me towards the reference driver? Also, any idea where in
ath9k is a good place to check for decryption failures?
Instrumenting ath9k_cmn_rx_accept in ath9k/common.c showed some decrypt
errors, but it was about same amount for working and broken states.

Alexis

On Thu, May 14, 2015 at 5:49 PM, Adrian Chadd <adrian@freebsd.org> wrote:

> Hi,
>
> Try writing something that periodically checks if the key is in there.
> I have a feeling that I've seen this bug in the reference driver, and
> they "fixed" it by noticing decrypt failures for a given destination
> and replumbing the key if it didn't match. :(
>
> (I always wondered if this would ever surface as a real issue..)
>
>
> -adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20150515/bc1d6c94/attachment-0001.htm