Hey Adrian, Sounds like an idea, although up to this point I have not been able to detect whether replumbing is necessary. decrypt_errors does not increment exponentially on the receive path, as far as I saw only one decrypt_error comes through, which could just as well be a corrupted frame. I have not seen any other indicators of this issue, other than a complete lack of connectivity on unicast frames. So this attempt was to see if I could get the link stable, in any way possible, by blankly replumbing on every rekey. This should, in theory "solve" the issue, although at the cost of huge packet loss. So far, no go. I agree that some form of key caching may be necessary. It is a pity, because the mac80211 layer does have an interface for grabbing the keys, although it requires the rtnl_lock. As far as I saw, only the Intel wireless driver uses it to write the keys back into the chip upon resuming from a low-power state. Kind regards, Fugro Intersite B.V. Michel Stam -----Original Message----- From: adrian.chadd@xxxxxxxxx [mailto:adrian.chadd@xxxxxxxxx] On Behalf Of Adrian Chadd Sent: Tuesday, November 15, 2016 0:25 AM To: Stam, Michel [FINT] Cc: Johannes Berg; Sebastian Gottschall; Kalle Valo; Antonio Quartulli; ath9k-devel@xxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx; Antonio Quartulli Subject: Re: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption Hiya, maybe the right thing to do is to set a flag that says "please replumb", then do a reset, and have the reset path see if we need to replumb keys and do so? To make locking less terrible, maybe we need to cache the keys in the ath9k driver somewhere so replumbing doesn't require reaching into mac82011. -adrian
