Re: [PATCH 1/2] mac80211: Remove ieee80211_privacy_mismatch

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]