On Mon, Mar 17, 2008 at 1:39 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > 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". The reason is solely engineering. It can be done safely in host so it's done there. > > 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. Can you elaborate why it doesn't cover bcom case? > 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. It's viable but I actually prefer not opening too many interfaces. Please give me some more detailed sketch how do you see that and we sure get to some acceptable solution. Thanks Tomas > 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
