Hi, > the spec of 11n makes the support on AES mandatory, but not TKIP. > Meaning that a NIC can support WPA2 and 11n separately, but not TKIP > in 11n. The RC4 encryption machine has a delay that makes difficult to > encrypt in TKIP (or WEP) in 11n rates. Intel's 11n are such NICs, 11n > + TKIP/WEP is not supported. > > The problem here is that the association (which can be 11n or not) > occurs before the 4-way handshake. Let's say that I have an AP that > publishes only TKIP in its WPA IE and 11n IE, I can understand that > there is no way I should do 11n association. But what happens with an > AP that publishes TKIP + AES in its RSN IE and 11n IE ? I could > associate in 11n, but then wpa_supplicant might be configured to > associate in TKIP (although the AP support AES), and I would be in an > unsupported mode. > > One solution would be to make wpa_supplicant understand what 11n is, > but that's not it's job. I would think that, indeed, it *is* its job since its job is key/algorithm selection and 11n limits the choices. How about we simply put the 11n information element into the generic IE and have mac80211 use that? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
