Oky! Meanwhile you get a reply from the MAC guys I will try to test again the "check & fix" approach. It is really strange that I can't recognize any corruption.
However, the problem of the TX key corruption still remains. It seems we can't do much about that. Cheers (and thanks a lot so far!), On 13/12/13 13:35, Adrian Chadd wrote: > 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 >> -- Antonio Quartulli
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
