Hm? There are separate transmit and receive keys negotiated.
-adrian On 22 November 2013 01:18, Antonio Quartulli <[email protected]> wrote: > 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 _______________________________________________ ath9k-devel mailing list [email protected] https://lists.ath9k.org/mailman/listinfo/ath9k-devel
