[ath9k-devel] GTK/PTK problem - key.c magic-bitshift

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

Hello!

On Mon, Nov 18, 2013 at 01:29:14PM -0800, Adrian Chadd wrote:
> oh goodie! goodie!
> 
> You're likely hitting the "keycache is corrupted!" bug.

Yeah I had this feeling already and I have been discussing with Jouni in
the meanwhile (who confirmed my feeling) :-)

> 
> The keycache contents is throwing away a bit you don't actually need.
> Look at which bit that actually is in the OUI specification. It's
> something very specific.
> 

Yeah, I realised that after talking to Felix.

> There's a chip bug that's been (as far as I could tell whilst I was at
> QCA) around forever.

Oh. This is a really bad news..I hoped it was a bug in the driver....
However now I know there is no bug to look for in the code! :)


> 
> You need to add code to check for decryption failures and if so,
> trigger a periodic job to read all the keycache slots and validate
> them against what cached values you keep in userland.
> 
> If they don't match, log an error and reprogram the slot.
> 
> (I haven't yet done it for FreeBSD but it's on my "when I'm bored one
> weekend soon" project lits.)

Sounds ugly..but I understood what you mean.
But why a periodic job? Isn't it enough to run the task once when there is a
decryption problem ?

Thanks a lot for your feedback!

> 
> HTH,
> 
> 
> 
> -adrian
> 
> 
> 
> On 17 November 2013 03:08, Antonio Quartulli <antonio@open-mesh.com> wrote:
> > Hello list,
> >
> > I am debugging a strange problem which symptom is that the PTK of some station
> > is messed up right after hostapd has configured a new GTK. This happens both in
> > WPA2 only and WPA/WPA2 mixed mode. I have no real clue of what is going on and
> > so, after having given a look at the hostapd code, I am now checking the driver
> > (Ath9k).
> >
> > While digging I found a piece of code in key.c which I can't understand.
> > Here is the snippet:
> >
> > 111                 macLo = get_unaligned_le32(mac);
> > 112                 macHi = get_unaligned_le16(mac + 4);
> > 113                 macLo >>= 1;
> > 114                 macLo |= (macHi & 1) << 31;
> > 115                 macHi >>= 1;
> >
> > At drivers/net/wireless/ath/key.c:113 there is a right-bitshift operation
> > executed on macLo. Since macLo is a 4byte variable containing 4 out of 6
> > bytes of the MAC address passed as argument, it looks to me like the bitshift
> > is throwing away one bit that we will never recover.
> >
> > I don't want to claim that this is necessarily connected to the problem I am
> > experiencing, but I'd like to get a better understanding of this part in order
> > to continue my research.
> >
> > However the driver I am using is not the latest one, so if somebody knows
> > whether this GTK/PTK problem is known and fixed I would be glad if you could
> > tell me :-)
> >
> >
> > Thanks a lot for your time.
> >
> > Regards,
> >
> >
> > --
> > Antonio Quartulli
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >

-- 
Antonio Quartulli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131118/f4cce8f6/attachment.pgp