There's a work around, yeah. Much like I've/we've described.
-adrian On 12 December 2013 01:17, Antonio Quartulli <anto...@open-mesh.com> wrote: > Hi Adrian! > > but as far as you know, isn't the internal Atheros driver applying any > workaround or strange hack to circumvent this problem? > Or simply there is no "clear" workaround at all? (maybe this is what you > expect to be told from the MAC guys?) > > > > Cheers, > > > On 09/12/13 20:38, Adrian Chadd wrote: >> Hi! >> >> I've emailed them - they're tossing it around internally. >> >> >> -a >> >> On 9 December 2013 02:17, Antonio Quartulli <anto...@open-mesh.com> wrote: >> 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 <anto...@open-mesh.com> >>>>> 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 > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
