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.
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
On Thu, 2007-10-25 at 15:57 +0200, Johannes Berg wrote:
> On Thu, 2007-10-25 at 09:49 -0400, Dan Williams wrote:
>
> > Ok, I'll try to track it down starting with wpa_supplicant then.
>
> 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.
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
Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:07 -0400, Dan Williams wrote:
>
>
>> Could you educate me a bit more about the problem if you've got a bit of
>> time?
>>
>
> 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.
>
>
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.
Signed-off-by: Adel Gadllah <[email protected]>
---
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,
On Tue, 2007-10-23 at 16:14 +0800, Zhu Yi wrote:
> On Tue, 2007-10-23 at 09:54 +0200, dragoran wrote:
> > 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
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
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?
> 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..
Whether it ever worked 'correctly' I cannot tell you. All I know it
behaves this way currently.
> IW_AUTH_* values were designed to provide mechanism for notifying the
> driver on number of parameters related to authentication (and
> association, in practice).
Right.
> 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.
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?
> 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.
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.
> 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).
It doesn't seem like mac80211 would care about this at all since hostapd
handles all these things.
> 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.
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?!
> 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.
Can you explain how this differs from PRISM2_PARAM_IEEE_802_1X?
> 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).
Why would this be necessary? Or rephrasing, why does it matter (to
userspace) whether the driver or the firmware is doing roaming?
Thanks,
johannes
(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.
Signed-off-by: Adel Gadllah <[email protected]>
---
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,
> 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 ...
Nope. Think again :) !! normalises to 0/1 rather than 0/!=0
> 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.
Are you sure it returns IW_AUTH_KEY_MGMT_802_1(X)? My assumption was
that this is what goes wrong.
> 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
Which is fine, privacy_mismatch() returns 0 if there's no "mismatch" and
we should hence proceed with the association.
> 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).
That's bogus, you misunderstood the return value of privacy_mismatch()
johannes
On Thu, 2007-10-25 at 09:49 -0400, Dan Williams wrote:
> Ok, I'll try to track it down starting with wpa_supplicant then.
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
On Wed, 2007-10-24 at 11:07 -0400, Dan Williams wrote:
> Could you educate me a bit more about the problem if you've got a bit of
> time?
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.
> 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...
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
On Sun, Oct 28, 2007 at 06:54:45PM +0100, Johannes Berg wrote:
> 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)
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
On Sun, Oct 28, 2007 at 11:28:14AM +0100, Johannes Berg wrote:
> > 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().
>
> Great, thanks for tracking this down.
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.
> > 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.
>
> Alright. Jouni, will you push this fix for 0.5.x?
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
On Thu, 2007-10-25 at 15:29 +0200, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:07 -0400, Dan Williams wrote:
>
> > Could you educate me a bit more about the problem if you've got a bit of
> > time?
>
> 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.
>
> > 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...
>
> 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.
Ok, I'll try to track it down starting with wpa_supplicant then.
Dan
As I said as a reply to the other mail, this is totally bogus, you
misunderstood the privacy_mismatch() return value.
> - sdata->u.sta.key_management_enabled = !!data->value;
> + sdata->u.sta.key_management_enabled = data->value;
This is just wrong, !! is there for a reason. I think
key_management_enabled is a smaller datatype so if data->value is large
enough you'll get 0 here for nonzero data->value without !!.
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().
Great, thanks for tracking this down.
> 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.
Alright. Jouni, will you push this fix for 0.5.x?
johannes
On 10/23/07, Zhu Yi <[email protected]> wrote:
>
> On Tue, 2007-10-23 at 09:54 +0200, dragoran wrote:
> > 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
I thought this was already merged. Will build a new kernel with it and
test again tomorrow.
> 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.
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)
> 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.
Thanks.
johannes
On Tue, 2007-10-23 at 09:54 +0200, dragoran wrote:
> 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
On Tue, 2007-10-23 at 19:37 +0200, Johannes Berg wrote:
> 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".
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
> 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
Johannes Berg wrote:
>> 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 ...
>>
>
> Nope. Think again :) !! normalises to 0/1 rather than 0/!=0
>
>
oh.. ok ;)
>> 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.
>>
>
> Are you sure it returns IW_AUTH_KEY_MGMT_802_1(X)? My assumption was
> that this is what goes wrong.
>
>
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)
>> 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
>>
>
> 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()
>
ok thx for explaing it.