-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hoi Adrian,
I don't want to push (I am just polling here ;-)), but have you been able to squeeze any information out of the MAC guys? Cheers, On 04/12/13 18:08, Adrian Chadd wrote: > Hi, > > I'll see if I can organise a chat with the MAC guys this week at > Atheros and ask them about this. Stay tuned... > > > -a > > On 4 December 2013 05:23, Antonio Quartulli <[email protected]> > wrote: Hi list, hi Adrian, hi Sujith (just added to the cc list), > > sorry for the silence, but I have been busy testing different > approaches on how to solve this. > > On 22/11/13 10:42, Adrian Chadd wrote: > > > Mh, that is true with TKIP. > > This means we have no way to recognize a TX key corruption. For > this reason a periodic worker that unconditionally checks the cache > and possibly refresh it looked like the best solution. > > However, after testing this strategy I realised that the worker is > not able to see the cache corruption: what it reads from the memory > always matches what we have in mac80211 (but I am sure we had a > corruption). > > My opinion is that the corruption is really happening at a low-low > level and so the memory content is not even altered. This may be > one of the reasons why this bug is so difficult to catch. > > The only solution I see to this problem is to make the periodic > worker refresh the key cache every second, no matter if a > corruption is found or not. > > However it does not sound like a good solution..any thought? > > > > Another experiment I have done was to refresh the whole key cache > each time a new key is pushed into ath9k. I did this because I > observed that the corruption was triggered upon GTK upload (on > re-keying). This fix seemed to make things better. > > So another plausible strategy could be a mix of the above > solutions: > > 1) refresh the entire cache on each set_key(cmd=SET_KEY) call 2) > upon detection of a number of RX decrypt errors schedule a worker > that refresh the entire cache (not the single slot...because that > could be the cause for another corruption...). > > > Still we have the problem of the TX key corruption with TKIP. If > this happens we can't detect it and we need to wait for the next > set_key() before the key can be properly restored..... > > > Any better idea? > > > Regards, > > - -- Antonio Quartulli -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJSpZitAAoJEEKTMo6mOh1VSLYQAIPCr6j6YJd0WiVeO23xGS75 hO7kfSm2y+zMJvl8WYFY5mKrUUssXYfp9YvDOUZV1KSK3cxHt93dzlEnvyhLCAQc RpHsbg0DPcuxIKzH4hQVl6mYyzAqMm2/icRXome+6H2Fz8fcGNy+4FGwiAhvAZdx 3WIj773EwE8m2/M4Kpa5HHIrcmJ305EFopAXZMEP9N37V1ANTGkJDhWI9gU3sqC/ XQmeNsTY3m0LG/CTyhoT0RvkW284pGxQkVPd29QDQFYKAQv0DcrPmohcprPcfQmA Bf1MIKTV734RQ+bU/TPw5lpCpUnGPhILwiijsnwNWGKSBEgjydS7LXp9/F+QMHHi inUOY9zVJHvETCJ+4cI/xKOYU1UCAsqnKldBmY63BrJr/MhJ1JiPsKVbd6rIyGmP KuQ9J4y+yP+y6TOYFoyFNlLFWRS+tbY2XPm51nV7aaYvmKZi+GgA8i1per3xmNAl 28Qwqnerjl+gyF0+IpU+61uMkx9wg3jIs2PtW9Ek7tSLOPb5vjyCmRvw8N+Djyax fr57lMwqV/yKZJlv5NA6i04WoocHn3IM2WaS7BeO/7h4sDKY2BOprpc4YxFw9rPF ZwhDNrVpMOWJzpnBwFyNNjXofQ6iVdtDmzHuUG98Y+WvEbMMV4Rq5sMu7rq03Mz7 w2IPW9twgtvcXUc2V7R3 =GZj5 -----END PGP SIGNATURE----- _______________________________________________ ath9k-devel mailing list [email protected] https://lists.ath9k.org/mailman/listinfo/ath9k-devel
