This is a pretty terrible hack, but here goes.
The atheros NICs have this annoying old bug - occasional CCMP PN
corruption. It shows up as a bit flipped somewhere in the PN
space. I remember looking into this years ago and IIRC it's
a receiver bug, NOT a transmitter side bug.
Anyway, it shows up as a bit flipped, but decryption is OK.
The next packet is almost always back to the original PN sequence
number space. However if it's a bit flipped high in the 48
bit PN space, every subsequent frame is going to be marked as
CCMP replay and dropped and this won't be fixed without reassociating.
Now, this solution works - and yeah, should be done for TKIP too -
but it likely should be done only for hardware that requires it.
But doing it in the driver is .. not very nice.
So the solution:
- If a big PN jump is seen, tag it as suspect and accept
- If the next seen PN is between the suspect PN and previous received PN, that's the new received PN and accept
- If the next seen PN is above the suspect PN, that's the new received PN and accept
- Anything else? It's lower than either and is rejected as a replay.
I've seen corruption in PN bits all throughout the 48 bit address
space. It's quite annoying.
I'm not sure I want to land this patch in its current state but it
does fix a problem that I can reproduce with a few hours of watching
a video stream, so it's not exactly uncommon with today's traffic
patterns.