>> I'd be glad if someone could take a look. If not, I'll have someone >> from our team to look at it, but I don't know how long it will take... > > Without looking too much - it seems to me that this is a fundamental > problem with PTK rekeying, in that it re-uses the key index that is > intended to avoid this. In this case, the AP is openWRT. I guess the Key idx is chosen in software, so maybe the proper fix would be to have openWRT increment the key index when it rekeys? > > The issue at hand here is likely a hardware decryption vs. key replacing > race, in that hardware decryption happens while the key replacing also > happens, and then the PN checking after key replace hits the wrong key > (due to the above-mentioned issue with not being able to change the key > index in PTK rekeying.) > > I don't see how we can fix this, except perhaps heuristically by > dropping packets that were encrypted with the *old* key and therefore > not updating the replay counter for them. However, detecting that they > were encrypted with the old key would only be possible by detecting a > large jump in PN, which could theoretically also happen in real > usage ... > > 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
