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: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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) > > iQIcBAEBCAAGBQJSnyzgAAoJEEKTMo6mOh1VxggP/jzp+UB8lPiFItwMPXwob8ik > qNd1WcQhcShft8MrmK9kfjzp91t/uBby/QVsqwxKu8sVIpuQJaGI4ikOtIZ6/8b6 > FGkn+JouKY+gmEsT6U4Hfq6v4Ri/xKkUt5JfPN7moQr3OszitbnDGlO3gr9qY3Vv > YjDGkZPlAmGCpnLUY1nHiBrEhj0WX2GrFXQC06wskk5UYEyvE5PDy9LUt1ASQkxe > qa6rBWaanVT0YpLhoHXNldSu6aF1r1HXaG+lKnBMgJlBcLSBta7oxzYjxj6oPtLQ > J+QYkdkkwrEGqVR8JL+54tAYkJ0TZvw+DKuJ6PcWE/Z74LiiVczrEZ0yf5oQm8Ki > EgQUay8X3gOT9ZFIrnYUK3i2PdA8UsBv/xmIOhlRHqx2Au7bcekM+9c7tIZjxz0V > QVspKLaRefvP4thcB0Sni56D05vHdV69wFPui+d+Y2Z/i72NjP4x2AXylfOmVNsV > 9tI135f8see5wQOQN7WJFuM67h7GlyeSIeAZWFjwhdDBWSmWDtal9w9930MZgAVe > Oh1oLCoboi3gywiN4bpL59Thvt164prDQA6aA9uu90Ytbzxept0ZUITd+z5XQVbb > BLBWLSrZme0BDCqkJw55Z/ypl4TlXIIdWK935YDNMPRl1RGo86KUDSoCbFZNjc4J > w8WBV7CS7jmU+E2DjLzy > =gnO4 > -----END PGP SIGNATURE----- _______________________________________________ ath9k-devel mailing list [email protected] https://lists.ath9k.org/mailman/listinfo/ath9k-devel
