On Wed, 2007-08-22 at 13:57 -0400, Volker Braun wrote: > Thats PRISM2_PARAM_MIXED_CELL=1039, which you removed in your > 023-remove-unused-ioctls-3.patch. If I revert that then I'm sure your > iwpriv call would work around my problem. Oh right, but I dropped that patch now that Jouni complained about it :) > Note that I'm not in a mixed cell! iee80211_privacy_mismatch checks > the > wrong mismatch. In my case, the AP broadcasts privacy, but I do not > (yet) have a WEP key. So far I understand, that's exactly what happens with WPA as well. > But really mixed cell support is about the AP > _not_ broadcasting privacy, yet the user _having_ a WEP key > configured. Ah, so that's mixed cell. Had me wondering anyway :) > So say we fix iee80211_privacy_mismatch in checking for the right > mismatch only. Then everybody would be happy, except some poor soul on > a > mixed cell network who would probably never figure out how to enable > mixed cell mode. Why do we hate him so much? ;-) There is no security > implication in enabling mixed mode by default --- management frames > stay > unencrypted and data frames with privacy mismatch continue to be > dropped. That's true. However, I'm trying to figure out why wpa_supplicant doesn't tell mac80211 it's doing key management in your case. The first check in privacy_mismatch() should make it return 0 if wpa_supplicant sets key management, which works fine with WPA. I'm wondering if there's actually a bug in wpa_supplicant here. > ------------------ snip -------------------------------- > Mixed Cells Mode thanks for that, where did you get that from? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
