Hello
While testing the iwlwifi driver I noticed that the mac80211 does
provide a wext interface but does not support wpa with it.
Why? Is this a known bug/limitation.
And if yes any plans to fix it? Fedora 7 uses mac80211 by default which
results into networkmanager and (unpatched)wpa_supplicant is useless for
people who use WPA/WPA2.
P.S: please CC me
On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
> Hello
> While testing the iwlwifi driver I noticed that the mac80211 does
> provide a wext interface but does not support wpa with it.
You must have done something wrong, it works well.
johannes
On Sat, Mar 31, 2007 at 01:48:53PM -0400, Dan Williams wrote:
> Take a look at ieee80211_sta_scan_result() in mac80211/ieee80211_sta.c.
> Note that it returns custom events for the WPA & RSN IEs. That's just
> wrong. We should be using already-defined events.
I don't think the "already-defined events" were defined when that code
was written.. Sure, now it should be updated to use the WEXT-18 -based
events.
> I don't quite get why mac80211/d80211 was so behind in wireless
> extensions support. Didn't Jouni and Devicescape basically _write_
> WE-18/19 WPA support? Did d80211 just not get the love that
> wpa_supplicant and the other drivers got when they were updated to WE-18
> and later?
Well, I may have added WPA support to WE-18, but only after having
implemented support for WPA using custom events (the only real option
available prior to WE-18). Devicescape code needed to work with number
of Linux kernels that did not include WE-18, so it had to continue using
those custom events. Looks like no one has had enough time or interest
to update it to use the events defined in WE-18. wpa_supplicant supports
both mechanisms for receiving the IEs.
--
Jouni Malinen PGP id EFC895FA
Dan Williams wrote:
> On Sat, 2007-03-31 at 12:00 +0200, Johannes Berg wrote:
>> On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
>>> Hello
>>> While testing the iwlwifi driver I noticed that the mac80211 does
>>> provide a wext interface but does not support wpa with it.
>> You must have done something wrong, it works well.
>
> Nope! This time it's really mac80211 :)
>
> Take a look at ieee80211_sta_scan_result() in mac80211/ieee80211_sta.c.
> Note that it returns custom events for the WPA & RSN IEs. That's just
> wrong. We should be using already-defined events.
>
> [ Hopefully in cfg80211 we'll have a very easy way to extend the defined
> tag-list for attributes returned from scan results. If you look at what
> various drivers have custom-defined for the CUSTOM tag, we weren't very
> aggressive about standardizing custom tags into IWEV* events. ]
>
> I'm not sure where the heck these bits of mac80211 came from; both
> hostap and ieee80211 do it right (also airo, libertas, and prism54,
> though I'm to blame for those). Plus, it's a net loss of code to do it
> with IWEVGENIE, and no additional kzalloc that can fail! Bonus+2!
>
> hostap:
> -------------
> if (bss && bss->wpa_ie_len > 0 && bss->wpa_ie_len <= MAX_WPA_IE_LEN) {
> memset(&iwe, 0, sizeof(iwe));
> iwe.cmd = IWEVGENIE;
> iwe.u.data.length = bss->wpa_ie_len;
> current_ev = iwe_stream_add_point(
> current_ev, end_buf, &iwe, bss->wpa_ie);
> }
>
> if (bss && bss->rsn_ie_len > 0 && bss->rsn_ie_len <= MAX_WPA_IE_LEN) {
> memset(&iwe, 0, sizeof(iwe));
> iwe.cmd = IWEVGENIE;
> iwe.u.data.length = bss->rsn_ie_len;
> current_ev = iwe_stream_add_point(
> current_ev, end_buf, &iwe, bss->rsn_ie);
> }
>
> ieee80211:
> -------------
>
> memset(&iwe, 0, sizeof(iwe));
> if (network->wpa_ie_len) {
> char buf[MAX_WPA_IE_LEN];
> memcpy(buf, network->wpa_ie, network->wpa_ie_len);
> iwe.cmd = IWEVGENIE;
> iwe.u.data.length = network->wpa_ie_len;
> start = iwe_stream_add_point(start, stop, &iwe, buf);
> }
>
> memset(&iwe, 0, sizeof(iwe));
> if (network->rsn_ie_len) {
> char buf[MAX_WPA_IE_LEN];
> memcpy(buf, network->rsn_ie, network->rsn_ie_len);
> iwe.cmd = IWEVGENIE;
> iwe.u.data.length = network->rsn_ie_len;
> start = iwe_stream_add_point(start, stop, &iwe, buf);
> }
>
> <rant>
>
> I don't quite get why mac80211/d80211 was so behind in wireless
> extensions support. Didn't Jouni and Devicescape basically _write_
> WE-18/19 WPA support? Did d80211 just not get the love that
> wpa_supplicant and the other drivers got when they were updated to WE-18
> and later?
>
> </rant>
>
> I can whip something up that _looks_ right but hasn't been compile
> tested if somebody else can test it.
>
I can test it. ATM, I cannot get NM to connect, which prevents any testing of mac80211.
Larry
On Saturday 31 March 2007 18:37, Michael Buesch wrote:
> On Saturday 31 March 2007 13:19, dragoran wrote:
> > Johannes Berg wrote:
> > > On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
> > >
> > >> Hello
> > >> While testing the iwlwifi driver I noticed that the mac80211 does
> > >> provide a wext interface but does not support wpa with it.
> > >>
> > >
> > > You must have done something wrong, it works well.
> > >
> > >
> > same also happens with the rt2x00 drivers....
> > it seems that I am not doing something wrong but that you are using a
> > ieee80211 based driver....
>
> I think you can trust Johannes, the author of the mac80211 configuratrion
> interface, in this matter. ;)
> mac80211 _does_ work with WPA. For sure. 100%.
Well, except for the WEXT breakage on platforms with 64bit kernel
and 32bit userland. But there WEXT doesn't work with ieee80211, either.
--
Greetings Michael.
On Sat, 2007-03-31 at 18:37 +0200, Michael Buesch wrote:
> On Saturday 31 March 2007 13:19, dragoran wrote:
> > Johannes Berg wrote:
> > > On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
> > >
> > >> Hello
> > >> While testing the iwlwifi driver I noticed that the mac80211 does
> > >> provide a wext interface but does not support wpa with it.
> > >>
> > >
> > > You must have done something wrong, it works well.
> > >
> > >
> > same also happens with the rt2x00 drivers....
> > it seems that I am not doing something wrong but that you are using a
> > ieee80211 based driver....
>
> I think you can trust Johannes, the author of the mac80211 configuratrion
> interface, in this matter. ;)
> mac80211 _does_ work with WPA. For sure. 100%.
> You are doing something wrong.
No, he's not, see my previous post. mac80211 doesn't use the right
WE-18 and later IWEVGENIE event to report IEs in scan results. Like
every other in-kernel driver/stack out there besides mac80211.
Dan
On Saturday 31 March 2007 13:19, dragoran wrote:
> Johannes Berg wrote:
> > On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
> >
> >> Hello
> >> While testing the iwlwifi driver I noticed that the mac80211 does
> >> provide a wext interface but does not support wpa with it.
> >>
> >
> > You must have done something wrong, it works well.
> >
> >
> same also happens with the rt2x00 drivers....
> it seems that I am not doing something wrong but that you are using a
> ieee80211 based driver....
I think you can trust Johannes, the author of the mac80211 configuratrion
interface, in this matter. ;)
mac80211 _does_ work with WPA. For sure. 100%.
You are doing something wrong.
--
Greetings Michael.
Johannes Berg wrote:
> On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
>
>> Hello
>> While testing the iwlwifi driver I noticed that the mac80211 does
>> provide a wext interface but does not support wpa with it.
>>
>
> You must have done something wrong, it works well.
>
>
same also happens with the rt2x00 drivers....
it seems that I am not doing something wrong but that you are using a
ieee80211 based driver....
> johannes
>
On Saturday 31 March 2007 13:48, Dan Williams wrote:
> On Sat, 2007-03-31 at 12:00 +0200, Johannes Berg wrote:
> > On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
> > > Hello
> > > While testing the iwlwifi driver I noticed that the mac80211 does
> > > provide a wext interface but does not support wpa with it.
> >
> > You must have done something wrong, it works well.
>
> Nope! This time it's really mac80211 :)
>
> Take a look at ieee80211_sta_scan_result() in mac80211/ieee80211_sta.c.
> Note that it returns custom events for the WPA & RSN IEs. That's just
> wrong. We should be using already-defined events.
>
What does that have to do with WPA not working? wpa_supplicant works fine with
the custom events on my system. Also works fine with the standard events
which the following patch makes mac80211 use.
--
mac80211: use IWEVGENIE
From: Michael Wu <[email protected]>
Use IWEVGENIE which was defined in WE-18.
Signed-off-by: Michael Wu <[email protected]>
---
net/mac80211/ieee80211_sta.c | 40 ++++++++++------------------------------
1 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index 087f176..a227c38 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -2839,39 +2839,19 @@ ieee80211_sta_scan_result(struct net_device *dev,
current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, "");
if (bss && bss->wpa_ie) {
- char *buf, *p;
- int i;
- buf = kmalloc(30 + bss->wpa_ie_len * 2, GFP_ATOMIC);
- if (buf) {
- p = buf;
- p += sprintf(p, "wpa_ie=");
- for (i = 0; i < bss->wpa_ie_len; i++)
- p+= sprintf(p, "%02x", bss->wpa_ie[i]);
- memset(&iwe, 0, sizeof(iwe));
- iwe.cmd = IWEVCUSTOM;
- iwe.u.data.length = strlen(buf);
- current_ev = iwe_stream_add_point(current_ev, end_buf,
- &iwe, buf);
- kfree(buf);
- }
+ memset(&iwe, 0, sizeof(iwe));
+ iwe.cmd = IWEVGENIE;
+ iwe.u.data.length = bss->wpa_ie_len;
+ current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe,
+ bss->wpa_ie);
}
if (bss && bss->rsn_ie) {
- char *buf, *p;
- int i;
- buf = kmalloc(30 + bss->rsn_ie_len * 2, GFP_ATOMIC);
- if (buf) {
- p = buf;
- p += sprintf(p, "rsn_ie=");
- for (i = 0; i < bss->rsn_ie_len; i++)
- p+= sprintf(p, "%02x", bss->rsn_ie[i]);
- memset(&iwe, 0, sizeof(iwe));
- iwe.cmd = IWEVCUSTOM;
- iwe.u.data.length = strlen(buf);
- current_ev = iwe_stream_add_point(current_ev, end_buf,
- &iwe, buf);
- kfree(buf);
- }
+ memset(&iwe, 0, sizeof(iwe));
+ iwe.cmd = IWEVGENIE;
+ iwe.u.data.length = bss->rsn_ie_len;
+ current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe,
+ bss->rsn_ie);
}
if (bss) {
Johannes Berg wrote:
> On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
>
>> Hello
>> While testing the iwlwifi driver I noticed that the mac80211 does
>> provide a wext interface but does not support wpa with it.
>>
>
> You must have done something wrong, it works well.
>
>
ok simple test case for me:
boot F7 livecd on a laptop with a ipw3945 card.
the iwlwifi driver got loaded....
try to selected WPA from the nm menu ... wait there aren't any :( ...
test with ipw3945 (ieee80211 based) wpa options are back ;)
so can you please tell me which driver you used and how you verifed that
it works?
> johannes
>
On Sat, 2007-03-31 at 12:00 +0200, Johannes Berg wrote:
> On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
> > Hello
> > While testing the iwlwifi driver I noticed that the mac80211 does
> > provide a wext interface but does not support wpa with it.
>
> You must have done something wrong, it works well.
Nope! This time it's really mac80211 :)
Take a look at ieee80211_sta_scan_result() in mac80211/ieee80211_sta.c.
Note that it returns custom events for the WPA & RSN IEs. That's just
wrong. We should be using already-defined events.
[ Hopefully in cfg80211 we'll have a very easy way to extend the defined
tag-list for attributes returned from scan results. If you look at what
various drivers have custom-defined for the CUSTOM tag, we weren't very
aggressive about standardizing custom tags into IWEV* events. ]
I'm not sure where the heck these bits of mac80211 came from; both
hostap and ieee80211 do it right (also airo, libertas, and prism54,
though I'm to blame for those). Plus, it's a net loss of code to do it
with IWEVGENIE, and no additional kzalloc that can fail! Bonus+2!
hostap:
-------------
if (bss && bss->wpa_ie_len > 0 && bss->wpa_ie_len <= MAX_WPA_IE_LEN) {
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = IWEVGENIE;
iwe.u.data.length = bss->wpa_ie_len;
current_ev = iwe_stream_add_point(
current_ev, end_buf, &iwe, bss->wpa_ie);
}
if (bss && bss->rsn_ie_len > 0 && bss->rsn_ie_len <= MAX_WPA_IE_LEN) {
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = IWEVGENIE;
iwe.u.data.length = bss->rsn_ie_len;
current_ev = iwe_stream_add_point(
current_ev, end_buf, &iwe, bss->rsn_ie);
}
ieee80211:
-------------
memset(&iwe, 0, sizeof(iwe));
if (network->wpa_ie_len) {
char buf[MAX_WPA_IE_LEN];
memcpy(buf, network->wpa_ie, network->wpa_ie_len);
iwe.cmd = IWEVGENIE;
iwe.u.data.length = network->wpa_ie_len;
start = iwe_stream_add_point(start, stop, &iwe, buf);
}
memset(&iwe, 0, sizeof(iwe));
if (network->rsn_ie_len) {
char buf[MAX_WPA_IE_LEN];
memcpy(buf, network->rsn_ie, network->rsn_ie_len);
iwe.cmd = IWEVGENIE;
iwe.u.data.length = network->rsn_ie_len;
start = iwe_stream_add_point(start, stop, &iwe, buf);
}
<rant>
I don't quite get why mac80211/d80211 was so behind in wireless
extensions support. Didn't Jouni and Devicescape basically _write_
WE-18/19 WPA support? Did d80211 just not get the love that
wpa_supplicant and the other drivers got when they were updated to WE-18
and later?
</rant>
I can whip something up that _looks_ right but hasn't been compile
tested if somebody else can test it.
Dan
On 4/10/07, Dan Williams <[email protected]> wrote:
> On Tue, 2007-04-10 at 09:13 +0200, dragoran wrote:
> > ok I tested it again with linvilles f7 test kernel (wireless-git + your
> > patches + iwlwifi).
> > again nm detect the card as wpa and it finds the wpa enabled network.
> > But it fails to connect (does not even ask for a key). So I tryed to use
> > wpa_supplicant by hand ( with a config that works fine with ipw3945 ;
> > ieee80211) . Its seems not to be related to iwlwifi but to a ioctl that
> > mac80211 does not support (when used with wext).
> > ----
> > Own MAC address: 00:18:de:05:f7:9e
> > wpa_driver_wext_set_wpa
> > wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
> > wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
> > wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
> > wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
> > wpa_driver_wext_set_countermeasures
> > ioctl[SIOCSIWAUTH]: Operation not supported
> > WEXT auth param 4 value 0x0 - wpa_driver_wext_set_drop_unencrypted
> > ioctl[SIOCSIWAUTH]: Operation not supported
> > ----
> > notice the *ioctl[SIOCSIWAUTH]: Operation not supported* what is
> > SIOCSIWAUTH and how does it not being supproted affect wpa/wext support?
>
> I'm not actually sure these are too much of a problem; some drivers
> don't support all options and wpa_supplicant should be able to continue
> without it. Is there any log out put _after_ the pieces you show?
>
yes see the attached file (same config works fine with ipw3945) sorry
for the resend but stupid gmail sends html mail wgich the list does
not accept
> Dan
>
>
>
On Sunday 08 April 2007 17:45, dragoran dragoran wrote:
> are you planning to submit this patches to wireless-dev ? so that distros
> (ex: fedora 7) can pick it up?
By CCing Jiri and Linville, I already did. Did this patch work for you?
-Michael Wu
dragoran wrote:
> ioctl[SIOCSIWAUTH]: Operation not supported
> WEXT auth param 4 value 0x0 - wpa_driver_wext_set_drop_unencrypted
> ioctl[SIOCSIWAUTH]: Operation not supported
> ----
> notice the *ioctl[SIOCSIWAUTH]: Operation not supported* what is
> SIOCSIWAUTH and how does it not being supproted affect wpa/wext support?
I agree with Dan Williams that this message is not critical. Michael Buesch uses WPA with mac80211,
and his version doesn't support SIOCSIWAUTH either.
I'm beginning to think that there is a problem with certain AP's. What is the make and model of
yours? What firmware version is it using? I cannot connect to my Linksys WRT54G V5 with or without
WPA enabled. I'm running v1.02.00 of the firmware (the latest).
Larry
On Sat, 2007-03-31 at 21:21 -0400, Michael Wu wrote:
> On Saturday 31 March 2007 20:55, Dan Williams wrote:
> > wpa_supplicant works fine with it because it parses the custom events.
> >
> > NetworkManager will not parse custom events by design, in the same way
> > that it will not allow WPA to be used on a card unless the driver
> > explicitly advertises WPA support, and requires the use of the
> > wpa_supplicant WEXT driver. I'm not going to spend my time implementing
> > stuff 3 different ways; we need to standardize this stuff and stick with
> > it.
> >
> > Draw a line in the sand and all that. Sure, it's made some people's
> > lives harder, but NetworkManager was the reason madwifi added WE-19
> > support, for example.
> >
> NetworkManager doesn't parse custom events? I'm pretty sure WPA/WPA2 was
> reported correctly in the scan results before.. maybe because of this little
> bit of code?
>
> NetworkManager-0.6.4/src/nm-device-802-11-wireless.c:
> case IWEVCUSTOM:
> clen = iwe->u.data.length;
> if (custom + clen > end)
> break;
> if (clen > 7 && ((strncmp (custom, "wpa_ie=", 7) == 0) || (strncmp
> (custom, "rsn_ie=", 7) == 0)))
> ...
>
> But that's besides the point. It is true that proper events should be used,
> but that issue has nothing to do with why WPA isn't working with
> NetworkManager. That was my point.
Huh; right. My bad :) What's probably going on here then is that since
the driver wasn't reporting WPA capability via enc_capa, the applet
wont' show WPA as an option, and NM won't allow you to connect to
WPA-enabled access points.
In any case, with 0.7 all the scanning code is ripped out in favor of
using the D-Bus interface to wpa_supplicant, so this goes away and its
wpa_supplicant's problem and not mine.
Dan
> > Patch looks good though; thanks! One thing I just thought of, which no
> > drivers probably do. Should mac80211 check that there's enough space
> > left in the WE stream to actually add the IE? There are usually checks
> > to ensure that there's enough space to add the next whole BSS, but I
> > don't know if we do checks to during the addition of each BSS. Maybe
> > I'm wrong and this isn't an issue.
> >
> iwe_stream_add_point(char * stream, /* Stream of events */
> char * ends, /* End of stream */
> struct iw_event *iwe, /* Payload length + flags */
> char * extra) /* More payload */
> {
> int event_len = IW_EV_POINT_LEN + iwe->u.data.length;
> /* Check if it's possible */
> if(likely((stream + event_len) < ends)) {
>
> -Michael Wu
On Tue, 2007-04-10 at 09:13 +0200, dragoran wrote:
> ok I tested it again with linvilles f7 test kernel (wireless-git + your
> patches + iwlwifi).
> again nm detect the card as wpa and it finds the wpa enabled network.
> But it fails to connect (does not even ask for a key). So I tryed to use
> wpa_supplicant by hand ( with a config that works fine with ipw3945 ;
> ieee80211) . Its seems not to be related to iwlwifi but to a ioctl that
> mac80211 does not support (when used with wext).
> ----
> Own MAC address: 00:18:de:05:f7:9e
> wpa_driver_wext_set_wpa
> wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
> wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
> wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
> wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
> wpa_driver_wext_set_countermeasures
> ioctl[SIOCSIWAUTH]: Operation not supported
> WEXT auth param 4 value 0x0 - wpa_driver_wext_set_drop_unencrypted
> ioctl[SIOCSIWAUTH]: Operation not supported
> ----
> notice the *ioctl[SIOCSIWAUTH]: Operation not supported* what is
> SIOCSIWAUTH and how does it not being supproted affect wpa/wext support?
I'm not actually sure these are too much of a problem; some drivers
don't support all options and wpa_supplicant should be able to continue
without it. Is there any log out put _after_ the pieces you show?
Dan
ok I tested it again with linvilles f7 test kernel (wireless-git + your
patches + iwlwifi).
again nm detect the card as wpa and it finds the wpa enabled network.
But it fails to connect (does not even ask for a key). So I tryed to use
wpa_supplicant by hand ( with a config that works fine with ipw3945 ;
ieee80211) . Its seems not to be related to iwlwifi but to a ioctl that
mac80211 does not support (when used with wext).
----
Own MAC address: 00:18:de:05:f7:9e
wpa_driver_wext_set_wpa
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_countermeasures
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 4 value 0x0 - wpa_driver_wext_set_drop_unencrypted
ioctl[SIOCSIWAUTH]: Operation not supported
----
notice the *ioctl[SIOCSIWAUTH]: Operation not supported* what is
SIOCSIWAUTH and how does it not being supproted affect wpa/wext support?
On 4/10/07, Larry Finger <[email protected]> wrote:
> dragoran wrote:
> > ioctl[SIOCSIWAUTH]: Operation not supported
> > WEXT auth param 4 value 0x0 - wpa_driver_wext_set_drop_unencrypted
> > ioctl[SIOCSIWAUTH]: Operation not supported
> > ----
> > notice the *ioctl[SIOCSIWAUTH]: Operation not supported* what is
> > SIOCSIWAUTH and how does it not being supproted affect wpa/wext support?
>
> I agree with Dan Williams that this message is not critical. Michael Buesch
> uses WPA with mac80211,
> and his version doesn't support SIOCSIWAUTH either.
>
> I'm beginning to think that there is a problem with certain AP's. What is
> the make and model of
> yours? What firmware version is it using? I cannot connect to my Linksys
> WRT54G V5 with or without
> WPA enabled. I'm running v1.02.00 of the firmware (the latest).
>
its a rt2500usb device used with hostapd (on FC6 x86_64)
> Larry
>
On Saturday 31 March 2007 20:55, Dan Williams wrote:
> wpa_supplicant works fine with it because it parses the custom events.
>
> NetworkManager will not parse custom events by design, in the same way
> that it will not allow WPA to be used on a card unless the driver
> explicitly advertises WPA support, and requires the use of the
> wpa_supplicant WEXT driver. I'm not going to spend my time implementing
> stuff 3 different ways; we need to standardize this stuff and stick with
> it.
>
> Draw a line in the sand and all that. Sure, it's made some people's
> lives harder, but NetworkManager was the reason madwifi added WE-19
> support, for example.
>
NetworkManager doesn't parse custom events? I'm pretty sure WPA/WPA2 was
reported correctly in the scan results before.. maybe because of this little
bit of code?
NetworkManager-0.6.4/src/nm-device-802-11-wireless.c:
case IWEVCUSTOM:
clen = iwe->u.data.length;
if (custom + clen > end)
break;
if (clen > 7 && ((strncmp (custom, "wpa_ie=", 7) == 0) || (strncmp
(custom, "rsn_ie=", 7) == 0)))
...
But that's besides the point. It is true that proper events should be used,
but that issue has nothing to do with why WPA isn't working with
NetworkManager. That was my point.
> Patch looks good though; thanks! One thing I just thought of, which no
> drivers probably do. Should mac80211 check that there's enough space
> left in the WE stream to actually add the IE? There are usually checks
> to ensure that there's enough space to add the next whole BSS, but I
> don't know if we do checks to during the addition of each BSS. Maybe
> I'm wrong and this isn't an issue.
>
iwe_stream_add_point(char * stream, /* Stream of events */
char * ends, /* End of stream */
struct iw_event *iwe, /* Payload length + flags */
char * extra) /* More payload */
{
int event_len = IW_EV_POINT_LEN + iwe->u.data.length;
/* Check if it's possible */
if(likely((stream + event_len) < ends)) {
-Michael Wu
On Sat, 2007-03-31 at 15:03 -0400, Michael Wu wrote:
> On Saturday 31 March 2007 13:48, Dan Williams wrote:
> > On Sat, 2007-03-31 at 12:00 +0200, Johannes Berg wrote:
> > > On Sat, 2007-03-31 at 11:36 +0200, dragoran wrote:
> > > > Hello
> > > > While testing the iwlwifi driver I noticed that the mac80211 does
> > > > provide a wext interface but does not support wpa with it.
> > >
> > > You must have done something wrong, it works well.
> >
> > Nope! This time it's really mac80211 :)
> >
> > Take a look at ieee80211_sta_scan_result() in mac80211/ieee80211_sta.c.
> > Note that it returns custom events for the WPA & RSN IEs. That's just
> > wrong. We should be using already-defined events.
> >
> What does that have to do with WPA not working? wpa_supplicant works fine with
> the custom events on my system. Also works fine with the standard events
> which the following patch makes mac80211 use.
wpa_supplicant works fine with it because it parses the custom events.
NetworkManager will not parse custom events by design, in the same way
that it will not allow WPA to be used on a card unless the driver
explicitly advertises WPA support, and requires the use of the
wpa_supplicant WEXT driver. I'm not going to spend my time implementing
stuff 3 different ways; we need to standardize this stuff and stick with
it.
Draw a line in the sand and all that. Sure, it's made some people's
lives harder, but NetworkManager was the reason madwifi added WE-19
support, for example.
Patch looks good though; thanks! One thing I just thought of, which no
drivers probably do. Should mac80211 check that there's enough space
left in the WE stream to actually add the IE? There are usually checks
to ensure that there's enough space to add the next whole BSS, but I
don't know if we do checks to during the addition of each BSS. Maybe
I'm wrong and this isn't an issue.
Dan
> --
>
> mac80211: use IWEVGENIE
>
> From: Michael Wu <[email protected]>
>
> Use IWEVGENIE which was defined in WE-18.
>
> Signed-off-by: Michael Wu <[email protected]>
> ---
>
> net/mac80211/ieee80211_sta.c | 40 ++++++++++------------------------------
> 1 files changed, 10 insertions(+), 30 deletions(-)
>
> diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
> index 087f176..a227c38 100644
> --- a/net/mac80211/ieee80211_sta.c
> +++ b/net/mac80211/ieee80211_sta.c
> @@ -2839,39 +2839,19 @@ ieee80211_sta_scan_result(struct net_device *dev,
> current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, "");
>
> if (bss && bss->wpa_ie) {
> - char *buf, *p;
> - int i;
> - buf = kmalloc(30 + bss->wpa_ie_len * 2, GFP_ATOMIC);
> - if (buf) {
> - p = buf;
> - p += sprintf(p, "wpa_ie=");
> - for (i = 0; i < bss->wpa_ie_len; i++)
> - p+= sprintf(p, "%02x", bss->wpa_ie[i]);
> - memset(&iwe, 0, sizeof(iwe));
> - iwe.cmd = IWEVCUSTOM;
> - iwe.u.data.length = strlen(buf);
> - current_ev = iwe_stream_add_point(current_ev, end_buf,
> - &iwe, buf);
> - kfree(buf);
> - }
> + memset(&iwe, 0, sizeof(iwe));
> + iwe.cmd = IWEVGENIE;
> + iwe.u.data.length = bss->wpa_ie_len;
> + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe,
> + bss->wpa_ie);
> }
>
> if (bss && bss->rsn_ie) {
> - char *buf, *p;
> - int i;
> - buf = kmalloc(30 + bss->rsn_ie_len * 2, GFP_ATOMIC);
> - if (buf) {
> - p = buf;
> - p += sprintf(p, "rsn_ie=");
> - for (i = 0; i < bss->rsn_ie_len; i++)
> - p+= sprintf(p, "%02x", bss->rsn_ie[i]);
> - memset(&iwe, 0, sizeof(iwe));
> - iwe.cmd = IWEVCUSTOM;
> - iwe.u.data.length = strlen(buf);
> - current_ev = iwe_stream_add_point(current_ev, end_buf,
> - &iwe, buf);
> - kfree(buf);
> - }
> + memset(&iwe, 0, sizeof(iwe));
> + iwe.cmd = IWEVGENIE;
> + iwe.u.data.length = bss->rsn_ie_len;
> + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe,
> + bss->rsn_ie);
> }
>
> if (bss) {