On Tue, 2007-10-23 at 10:07 -0400, Dan Williams wrote:
> Was there ever a conclusion to this patch? ISTR it went through a
> couple comments and was more or less rejected as the wrong approach.
> Can anyone comment as to what the _right_ approach is? Not being able
> to connect to dynamic WEP networks is not acceptable, what needs to be
> done to make this work?
My take on it is that it's a wpa_supplicant/wext bug.
See, the log says:
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
So that means ieee80211_privacy_mismatch() returned non-zero. However,
ieee80211_privacy_mismatch() will return 0 instantly when key management
is enabled, which is obviously true with dynamic WEP.
Hence, IMHO wpa_supplicant should be telling us that it enabled key
management. But the wext interface is crappy enough to not have a
definition for dynamic WEP which probably means that in the
wpa_driver_wext_keymgmt2wext() function in wpa_supplicant's
driver_wext.c 0 is returned, while we take anything but zero to be "key
management is enabled".
The proper fix would be to
(a) remove the crap about IW_AUTH_KEY_MGMT values from wext,
no drivers except mac80211 care and that cares only about
enabled/disabled
(b) make the parameter to IW_AUTH_KEY_MGMT a boolean
(no code changes required, only comment updates, since no driver
cares one bit except mac80211 which treats it as a bool already)
(c) update wpa_supplicant's wpa_driver_wext_keymgmt2wext function to
return 0 for KEY_MGMT_NONE and 1 for everything else
I'm not going to do it though. Dynamic WEP is just too uninteresting to
me.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
