> iwlwifi firmware also derive phase2 in RX path by itself since this is > not really possible to do in host level. Right. I just wonder why then it needs the host to derive the phase 2 key for TX, that seems pretty strange. Seems to me a bit like a "what can we do" design decision rather than "what makes sense". > However in case of non > matching iv32 such as wraparound it passes packet up unencrypted. That makes sense. > Therefore HW decryption > have to be always backed up by SW one. Obviously, yes. > Wraparound of Iv32 is reliable only if decryption of a the packet that > triggers it is correct. If this is not done and phase1 is advanced by > mistake it breaks traffic till the next wraparound actually it will > effectively cause disconnection. Good point. But let's not overload set_key() for it this way. This way, the driver needs to look up the key etc. and the semantics get quite mangled up. Also, your approach doesn't work for Broadcom hardware that only needs phase 1 keys for both RX and TX. How about instead we add a new "update_tkip_key()" callback that takes exactly the required parameters? It should also give the hardware-key-index so that the driver has less work to do. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
