User reported problems with driver_madwifi/driver_ipw

[Jouni Malinen]

On Fri, Feb 18, 2005 at 10:38:23AM -0500, Kyle McMartin wrote:

> I'm the maintainer of the Debian packages of wpa_supplicant. A few users
> reported needing the following patches to associate with open access points
> using wpa_supplicant. However, this morning, some other users have
> reported that the patch to driver_ipw breaks association with /ALL/
> access points, and only reverting the patch fixes things. Do you think this
> is plausible, or just a case of a problem on the users end?

The problems looks real, but the fix is not correct, neither for madwifi
nor ipw. The main problem is in having only disable WPA operation, not a
matching enable. In other words, if the card is configured even once for
plaintext mode, there is no way back to WPA-enabled state without
restarting wpa_supplicant.

In case of driver_madwifi, the only thing that needed to be done in
associate() is to set Privacy flag based on security policy, not the
full set_wpa(disabled). I ended up removing the separate set_wpa()
function (and actually even obsoleting it in the API) by moving other
parts to init()/deinit(). This seems to work now, both for plaintext and
WPA. The change is in CVS; development branch at the moment, likely to
go into 0.3.x and maybe also 0.2.x after some more testing. In other
words, I would like to hear from people using madwifi whether the
current development snapshot of wpa_supplicant works.


I do not have a test setup with ipw2100 or ipw2200, so the part about
driver_ipw.c is somewhat less clear to me. The change you mentioned is
here:

> diff -urNad a/driver_ipw.c b/driver_ipw.c
> --- a/driver_ipw.c	2005-02-06 12:06:23.000000000 -0500
> +++ b/driver_ipw.c	2005-02-15 00:45:59.000000000 -0500
> @@ -326,6 +326,9 @@
>  	int ret = 0;
>  	int unencrypted_eapol;
>  
> +	if ((params->key_mgmt_suite == KEY_MGMT_NONE) &&
> +			(wpa_driver_ipw_set_wpa(drv, 0) < 0))
> +		ret = -1;
>  	if (ipw_set_wpa_ie(drv, params->wpa_ie, params->wpa_ie_len) < 0)
>  		ret = -1;
>  	if (wpa_driver_wext_set_ssid(drv->wext, params->ssid,

In other words, this calls set_wpa(drv, 0) if key_mgmt is NONE. In
case of madwifi, this would not have been correct, since set_wpa() was
also enabling Privacy flag (which itself was not correct behavior). In
case of ipw2100/2200, I did not fully understand what set_wpa() ends up
doing because parts of it is in the firmware (I think). I would
appreciate it if someone working with the ipw2100/2200 driver would take
a closer look at this and test using wpa_supplicant in plaintext mode.
associate() handler should configure the driver to allow plaintext
associate if encryption is not enabled. set_wpa(0) may do more things
that could explain why something else gets broken.

-- 
Jouni Malinen                                            PGP id EFC895FA