From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antonio Quartulli Date: Fri, 22 Nov 2013 10:18:48 +0100 Subject: [ath9k-devel] GTK/PTK problem - key.c magic-bitshift In-Reply-To: References: <20131117110802.GD1381@neomailbox.net> <20131118215127.GC1443@open-mesh.com> Message-ID: <20131122091848.GF1443@open-mesh.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Wed, Nov 20, 2013 at 12:41:07AM -0800, Adrian Chadd wrote: > I don't know exactly what triggers it. Ok > > I suggested a periodic event so you only do it say, max every second > or two, but you trigger it when you get more than a bunch of decrypt > errors. That way if you keep getting decrypt errors, you only get it > scheduled every second or two, rather than on each decrypt error. > Yeah, sounds good. Right now I am simply trying to "refresh" the key cache right after a key is uploaded and if I observe decryption error I disable the HW acceleration for that STA (waiting for the next GTK rekey to refresh the cache and re-enable the accel again). However there is something I don't understand. In the packet dump I obtained from the network where I observe the bug, I see that after this possible "cache corruption event" ARP requests from the STA to the AP are properly decrypted (only ARP replies going in the other direction are not). If the cache is really compromised, how can this happen? I would expect the AP to not be able to decrypt the requests as well...don't you think so? Cheers, -- Antonio Quartulli -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131122/51140b96/attachment.pgp