From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antonio Quartulli Date: Thu, 12 Dec 2013 10:17:50 +0100 Subject: [ath9k-devel] Key Cache corruption In-Reply-To: References: <20131117110802.GD1381@neomailbox.net> <20131118215127.GC1443@open-mesh.com> <20131122091848.GF1443@open-mesh.com> <529F2CE0.4080009@open-mesh.com> <52A598AE.9020603@open-mesh.com> Message-ID: <52A97F3E.4010606@open-mesh.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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 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 >>>> 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 -------------- 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/20131212/915710c2/attachment.pgp