Re: mac80211 drops packet with old IV after rekeying

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2015-05-18 at 21:47 +0200, Alexander Wetzel wrote:

> For my understanding that has already be done. And at least for me it
> looks like we have hard evidence for that fact.
[...]
> The Key information used to decrypt the packets is added in the same
> section as the key index, if you have problems finding it.

[building a new wireshark was awkward ... between their git being really
slow and the build needing to be completely deleted first ...]

I agree with you - what you can see in the capture, assuming the TK/PMK
display is correct, is that

packet 11: PN 0x11F2B, old key
packet 15: PN 0x11F40, old key 
packet 19: PN 0x11F2C, new key

Note how packet 15, since it's VO priority, goes out far before packet
19, although packet 19 got the sequence number immediately after packet
11.

So... I guess we can, for now, go back to my earlier email and look at
the transmitter problem after all. I still think the receiver has a
similar issue though.

To be honest though, I'm not sure how to really solve this. Without
multi index capability, the spec doesn't really support PTK rekeying
well. With it, this is clearly no problem, but that would depend on more
code and driver support etc. and perhaps can't even be done with all
drivers/devices.

The first idea here would be to stop using HW crypto for TX while
changing the key, but I think at least ath10k wouldn't support that, not
sure what would happen though? Either way, it'd need a TX path flush, so
I guess it doesn't really make a difference.

So really, I guess what we need to do - and this will suck for
performance - is to stop queues and flush the TX path while the old key
is still programmed into the device, reinstall the key, and only then
restart transmission...

johannes