[ath9k-devel] Key Cache corruption

[Antonio Quartulli <antonio@open-mesh.com>]

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 <antonio@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 <antonio@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 <antonio@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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131213/e7f2777d/attachment.pgp