From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antonio Quartulli Date: Mon, 18 Nov 2013 22:44:52 +0100 Subject: [ath9k-devel] GTK/PTK problem - key.c magic-bitshift In-Reply-To: References: <20131117110802.GD1381@neomailbox.net> Message-ID: <20131118214452.GB1443@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 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 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