iwl3945/mac80211 cannot connect to dynamic wep network

When trying to connect to a dynamic wep network using iwl3945 and mac80211 I get this errors in dmesg and it fails to acciotate:
-----
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:00:00:00:00:00
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:01:f4:75:16:74
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: RX authentication from 00:01:f4:75:16:74 (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:01:f4:75:16:74
eth1: mismatch in privacy configuration and mixed-cell disabled - abort association
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:01:f4:75:16:74
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:01:f4:75:16:74
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: RX disassociation from 00:01:f4:75:16:74 (reason=7)
eth1: RX authentication from 00:01:f4:75:16:74 (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:01:f4:75:16:74
eth1: mismatch in privacy configuration and mixed-cell disabled - abort association
eth1: authentication frame received from 00:01:f4:75:16:74, but not in authenticate state - ignored
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate ADDRCONF(NETDEV_UP): eth1: link is not ready
---

I really have bo idea what this means... with ipw3945 (ieee80211 based) the same network works just fine.

This is related to mac80211, not the driver. That's why ipw3945 works. Does this patch work for you?

http://marc.info/?l=linux-wireless&m=118715117523167&w=2

Thanks,
-yi

I thought this was already merged. Will build a new kernel with it and test again tomorrow.

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?

Thanks,
Dan

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

Could you educate me a bit more about the problem if you've got a bit of time?

A normal Dynamic WEP configuration should result in wpa_supplicant sending IW_AUTH_KEY_MGMT with IW_AUTH_KEY_MGMT_802_1X since ieee8021x is specified in the wpa_supplicant config. Is this not happening here? I seem to be seeing that wpa_supplicant _should_ be setting key management, and mac80211 _should_ be returning 0 from ieee80211_privacy_mismatch() because key management has been set, and therefore this should succeed...

Dan

As much as I've understood, the problem comes from the privacy mismatch function returning non-zero. This means that wpa_supplicant doesn't set IW_AUTH_KEY_MGMT_802_1X because if you check the function then the key_manegement_enabled variable is checked first thing.

Yes, it seems that wpa_supplicant is not setting key management properly, possibly because internally it only translates two of the key management possibilities into the right wext state.

johannes

Ok, I'll try to track it down starting with wpa_supplicant then.

Dan

If you have a network, it's probably as simple as putting a printk into the ioctl path and a printf into hostapd's conversion function to see what it returns.

johannes

This turned out to be a wpa_supplicant issue. wpa_supplicant uses KEY_MGMT_802_1X_NO_WPA (instead of KEY_MGMT_802_1X) to handle Dynamic WEP where the AP doesn't broadcast WPA IEs (ie, a pure Dynamic WEP network), and that value wasn't being handled correctly by wpa_driver_wext_keymgmt2wext().

This has been fixed on the wpa_supplicant 0.6.x branch but not backported to the 0.5.x branch yet. Tested with EAP-TLS and LEAP with iwl4965 on kernel-2.6.23.1-35.fc8.

For Fedora, I've built wpa_supplicant-0.5.7-15.fc8 to fix this issue.

Dan

Great, thanks for tracking this down.

Alright. Jouni, will you push this fix for 0.5.x?

johannes

While there is indeed a bug in wpa_supplicant 0.5.x, I think that another issue here is in mac80211 trying to do something that it was not supposed to do, i.e., to figure out whether privacy is enabled or not based on keymgmt value. This is decided in the supplicant and the value is configured with IW_AUTH_PRIVACY_INVOKED to the kernel. In other words, mac80211 should follow this parameter and not IW_AUTH_KEY_MGMT.

I merged the fix into 0.5.x branch, so it should be included in the next release. This was fixed as part of a more generic cleanup and it did not end up being flagged as a bug fix and consequently, not merged into 0.5.x branch.

Jouni Malinen                                            PGP id EFC895FA

Hmm. Is there a good explanation of all these values? I still haven't understood what all the IW_AUTH_* means. I'm fairly sure though that this particular instance hasn't changed in terms of behaviour since the original devicescape code (not that this means it's bug-free, of course)

Thanks.

johannes

The only documentation for these that I'm aware of is linux/wireless.h. The original code was not doing this right either (it was implemented before WE-18, if I remember correctly). The odd part is that I'm sure this used to work long time ago..

IW_AUTH_* values were designed to provide mechanism for notifying the driver on number of parameters related to authentication (and association, in practice). WPA_VERSION, CIPHER_PAIRWISE, CIPHER_GROUP, KEY_MGMT, 80211_AUTH_ALG, WPA_ENABLED, PRIVACY_INVOKED are parameters describing the enabled security configuration for associations. Number of these parameters are bitfields and can include multiple enabled modes (e.g., both TKIP and CCMP could be allowed as the group cipher). I would assume most of these parameters be obvious from the field and bitfield value names.

PRIVACY_INVOKED is describing whether any sort of encryption is to be used (boolean). If mixed-cell mode (for which there does not seem to be configuration options in WE) is enabled, any privacy flag combination is allowed. If mixed-cell is disabled, the PRIVACY_INVOKED has to match with the Privacy flag advertized in the Beacon/ProbeRsp frames.

TKIP_COUNTERMEASURES is used to notify the driver of a two Michael MIC failures within 60 seconds to trigger TKIP countermeasures (i.e., disable all TKIP encryption/decryption and prevent new associations that would use TKIP). For client mode, it is also possible that this is implemented in the driver, so some drivers do not need this. Anyway, for AP mode, the notification is needed since the driver would not get notifications of MIC errors detected at clients (which are reported to the AP in EAPOL-Key frames).

DROP_UNENCRYPTED is a flag for configuring whether any unencrypted non-EAPOL data frames are allowed through. There is a MIB variable for this for WEP, but this is of limited use nowadays. I would expect all WPA configuration to prevent unencrypted data frames (apart from initial EAPOL frames) anyway.

RX_UNENCRYPTED_EAPOL is used to configure whether unencrypted EAPOL frames are to be received when pairwise keys are set. This is needed for IEEE 802.1X (i.e., non-WPA) which never encrypted EAPOL frames. With WPA, EAPOL frames are encrypted when pairwise keys are set and as such, unencrypted EAPOL frames should be dropped after the pairwise keys are configured.

ROAMING_CONTROL can be used to enable/disable roaming decision in the driver/firmware. The original need for this came from the Prism2 firmware design that has a configuration option for indicating which component is responsible for roaming (selecting a new BSS if the current one is likely to end up getting out of range).

Jouni Malinen                                            PGP id EFC895FA

Jouni,

Thanks for the detailed explanations. Mind if I wrap these up in some comments and post a patch to add them to header file?

Whether it ever worked 'correctly' I cannot tell you. All I know it behaves this way currently.

Right.

Yeah, the actual values I have no problem with; I was rather unclear on the semantics of some of the parameters. The one thing I don't like about the API is that we have to accept all of these silently. Why is that required?

Should we add a mixed-mode flag to wext? I realise that I've been the biggest proponent of not posting any further changes for wext but as it turns out the nl80211 interface for this hasn't progressed any further, nobody else is helping out and this seems to be something we definitely need right now. On the other hand, iwconfig(1) cannot set the auth parameters at all, as far as I can tell.

In essence, however, you're saying that we should ignore IW_AUTH_KEY_MGMT in favour of IW_AUTH_PRIVACY_INVOKED; I'll post a patch.

It doesn't seem like mac80211 would care about this at all since hostapd handles all these things.

We still haven't quite decided what to do with EAPOL frames though. Should this influence the mac80211 variable sdata->drop_unencrypted? It is also set by the in-kernel IBSS code though so that's a bit confusing. It seems that currently drop_unencrypted defaults to off?!

Can you explain how this differs from PRISM2_PARAM_IEEE_802_1X?

Why would this be necessary? Or rephrasing, why does it matter (to userspace) whether the driver or the firmware is doing roaming?

Thanks,
johannes

I can't verify it right now (won't have access to the dynamic wep ap for ~10 days), but I tryed to find out whats wrong by reading the code (wpa_supplicant and mac80211).

ieee80211_ioctl_siwauth in ieee80211_ioctl.c sets the key_management_enabled variable if the value passed to the ioctl is not 0 to true:
sdata->u.sta.key_management_enabled = !!data->value;
why !!data->value ? that should be the same as data->value ...

later its in the array ieee80211_handler (same file)
(iw_handler) ieee80211_ioctl_siwauth, /* SIOCSIWAUTH */

now to wpa_supplicant:
wpa_driver_wext_keymgmt2wext in driver_wext.c returns IW_AUTH_KEY_MGMT_802_1 (which is defined as 1) (when dynamic wep is used) wpa_driver_wext_set_auth_param than passes the value using ioctl(drv->ioctl_sock, SIOCSIWAUTH, &iwr) to mac80211.

ieee80211_privacy_mismatch checks for
if (!ifsta || (ifsta->flags & IEEE80211_STA_MIXED_CELL) ||

       ifsta->key_management_enabled)

and returns 0 because ifsta->key_management_enabled true in this case !!1 -> 1
so the attached patch should fix it by doing !data->value (which would result in ifsta->key_management_enabled to be 0 here and therefor ieee80211_privacy_mismatch won't return 0).

so the problem is that it returns 0 when ifsta->key_management_enabled is enabled (resturns 0 for dynamic wep).

the attached (untested!) patch (against 2.6.24-rc1) should fix it:
(I will build a kernel and test with static wep later today to see if I broke something)

also please correct me if I am completly wrong.

---

Fix handling of key_management_enabled to make dynamic wep work.

---

diff -upNr linux-2.6.23.orign/net/mac80211/ieee80211_ioctl.c linux-2.6.23/net/mac80211/ieee80211_ioctl.c
@@ -938,7 +938,7 @@ static int ieee80211_ioctl_siwauth(struc
             * that has privacy enabled regardless of not
             * having a key.
             */
-            sdata->u.sta.key_management_enabled = !!data->value;
+            sdata->u.sta.key_management_enabled = data->value;
        }
        break;
    case IW_AUTH_80211_AUTH_ALG:

diff -upNr linux-2.6.23.orign/net/mac80211/ieee80211_sta.c linux-2.6.23/net/mac80211/ieee80211_sta.c
@@ -707,7 +707,7 @@ static int ieee80211_privacy_mismatch(st
    int res = 0;
 
    if (!ifsta || (ifsta->flags & IEEE80211_STA_MIXED_CELL) ||
-        ifsta->key_management_enabled)
+        !ifsta->key_management_enabled)
        return 0;
 
    bss = ieee80211_rx_bss_get(dev, ifsta->bssid, local->hw.conf.channel,

Nope. Think again :) !! normalises to 0/1 rather than 0/!=0

Are you sure it returns IW_AUTH_KEY_MGMT_802_1(X)? My assumption was that this is what goes wrong.

Which is fine, privacy_mismatch() returns 0 if there's no "mismatch" and we should hence proceed with the association.

That's bogus, you misunderstood the return value of privacy_mismatch()

johannes

oh.. ok ;)

as I said before I don't have access to the ap right now but here:

static int wpa_driver_wext_keymgmt2wext(int keymgmt) {
switch (keymgmt) {
case KEY_MGMT_802_1X:

       return IW_AUTH_KEY_MGMT_802_1X;

that should be tha case for dynamic wep. (key_mgmt=IEEE8021X needed in wpa_supplicant.conf)

ok thx for explaing it.

(resend please ignore last mail I mixed two things in it)

I can't verify it right now (won't have access to the dynamic wep ap for ~10 days), but I tryed to find out whats wrong by reading the code (wpa_supplicant and mac80211).

ieee80211_ioctl_siwauth in ieee80211_ioctl.c sets the key_management_enabled variable if the value passed to the ioctl is not 0 to true:
sdata->u.sta.key_management_enabled = !!data->value;
why !!data->value ? that should be the same as data->value ...

later its in the array ieee80211_handler (same file)
(iw_handler) ieee80211_ioctl_siwauth, /* SIOCSIWAUTH */

now to wpa_supplicant:
wpa_driver_wext_keymgmt2wext in driver_wext.c returns IW_AUTH_KEY_MGMT_802_1 (which is defined as 1) (when dynamic wep is used) wpa_driver_wext_set_auth_param than passes the value using ioctl(drv->ioctl_sock, SIOCSIWAUTH, &iwr) to mac80211.

ieee80211_privacy_mismatch checks for
if (!ifsta || (ifsta->flags & IEEE80211_STA_MIXED_CELL) ||

       ifsta->key_management_enabled)

and returns 0 because ifsta->key_management_enabled true in this case !!1 -> 1

so the problem is that it returns 0 when ifsta->key_management_enabled is enabled (ie. returns 0 for dynamic wep).

the attached (untested!) patch (against 2.6.24-rc1) should fix it:
(I will build a kernel and test with static wep later today to see if I broke something)

also please correct me if I am completly wrong.

---

Fix handling of key_management_enabled to make dynamic wep work.

---
diff -upNr linux-2.6.23.orign/net/mac80211/ieee80211_ioctl.c linux-2.6.23/net/mac80211/ieee80211_ioctl.c
--- linux-2.6.23.orign/net/mac80211/ieee80211_ioctl.c 2007-10-26
11:14:00.000000000 +0200
+++ linux-2.6.23/net/mac80211/ieee80211_ioctl.c 2007-10-26
12:23:25.000000000 +0200
@@ -938,7 +938,7 @@ static int ieee80211_ioctl_siwauth(struc
* that has privacy enabled regardless of not
* having a key.
*/
- sdata->u.sta.key_management_enabled = !!data->value;

+            sdata->u.sta.key_management_enabled = data->value;
        }
        break;
    case IW_AUTH_80211_AUTH_ALG:

diff -upNr linux-2.6.23.orign/net/mac80211/ieee80211_sta.c linux-2.6.23/net/mac80211/ieee80211_sta.c
--- linux-2.6.23.orign/net/mac80211/ieee80211_sta.c 2007-10-26
11:14:00.000000000 +0200
+++ linux-2.6.23/net/mac80211/ieee80211_sta.c 2007-10-26
12:23:35.000000000 +0200
@@ -707,7 +707,7 @@ static int ieee80211_privacy_mismatch(st

    int res = 0;

    if (!ifsta || (ifsta->flags & IEEE80211_STA_MIXED_CELL) ||
-        ifsta->key_management_enabled)
+        !ifsta->key_management_enabled)
        return 0;

    bss = ieee80211_rx_bss_get(dev, ifsta->bssid, local->hw.conf.channel,

As I said as a reply to the other mail, this is totally bogus, you misunderstood the privacy_mismatch() return value.