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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
