> -----Original Message----- > From: linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless- > owner@xxxxxxxxxxxxxxx] On Behalf Of Johannes Berg > Sent: Sunday, May 17, 2015 23:22 > To: Emmanuel Grumbach > Cc: alexander.wetzel@xxxxxx; Jouni Malinen; linux-wireless > Subject: Re: mac80211 drops packet with old IV after rekeying > > On Sun, 2015-05-17 at 23:13 +0300, Emmanuel Grumbach wrote: > > > >> Yeah - ok. But how come we *already* set the pointer to the new key > > >> while the HW is still successfully decrypting with the old key. > > >> This is the point I can' figure out. I'd expect the transmitting > > >> side to stop using the old key prior to sending the EAPOL (which There is probably no synchronization between the 4way HS and other data traffic on the transmitter side, as these are different processes. So it is possible that after receiving message 3 and before setting the keys, the HW would be able to decrypt additional frames with the old key. > > >> #triggers the set key pointer line). So those 2 lines don't make sense to > me: > > >> > > >> > # set key pointer to new key > > >> > * data RX in HW, decrypt w/ old key, PN=999 > > >> > > >> After all, the Rx path is serialized all the way through from the > > >> air to mac80211. The only thing I can think about is that the > > >> sending side is still using the old key *after* it already sent its EAPOL > frames. > > > > > > Not sure, isn't the key only installed on EAPOL acknowledgement or so? > > > With PTK rekeying, I'm not really sure what the timing is, and > > > there's not really any way it can be correct (without extended key > > > ID support.) > > > > Whatever the timing is, since the Rx path is serialized, there > > shouldn't be any timing issues. Or at least, I can't figure out how > > these lines above could be in the order you put them. > > I agree that it'll depend on how the key is installed on the sender, however, I > have no idea how that's done and how much potential delay there is between > sending the EAPOL frame and installing the key there. > If you're looking at RX path synchronisation only then you're assuming a > perfect sender, but that clearly cannot be the case. > AFAIK, the PTK is installed immediately after the 4th message is sent without waiting to ACK or any other delay. As the AP (should) installs the keys only after processing the 4th message, so a delay is expected. Regards, Ilan. ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
