[PATCH] mac80211: fix races between siwessid and siwencode

[PATCH] mac80211: fix races between siwessid and siwencode

[Joonwoo Park]

resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522

The function ieee80211_ioctl_siwencode shouldn't be called if
authentication process is not completed.
This patch makes the ieee80211_ioctl_siwessid to wait for authentication
is completed.

Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
---
 net/mac80211/ieee80211_ioctl.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
index 5024d37..55a29f6 100644
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -391,6 +391,7 @@ static int ieee80211_ioctl_siwessid(struct net_device *dev,
 	if (sdata->vif.type == IEEE80211_IF_TYPE_STA ||
 	    sdata->vif.type == IEEE80211_IF_TYPE_IBSS) {
 		int ret;
+		DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
 		if (sdata->flags & IEEE80211_SDATA_USERSPACE_MLME) {
 			if (len > IEEE80211_MAX_SSID_LEN)
 				return -EINVAL;
@@ -405,8 +406,15 @@ static int ieee80211_ioctl_siwessid(struct net_device *dev,
 		ret = ieee80211_sta_set_ssid(dev, ssid, len);
 		if (ret)
 			return ret;
+
+		set_bit(IEEE80211_STA_REQ_RUN, &sdata->u.sta.request);
+
 		ieee80211_sta_req_auth(dev, &sdata->u.sta);
-		return 0;
+
+		ret = wait_event_interruptible_timeout(wq,
+			!test_bit(IEEE80211_STA_REQ_RUN, &sdata->u.sta.request),
+				HZ);
+		return (ret == HZ) ? 0 : ret;
 	}
 
 	if (sdata->vif.type == IEEE80211_IF_TYPE_AP) {
-- 
1.5.4

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Joonwoo Park]

On Wed, Mar 05, 2008 at 06:40:09PM +0900, Joonwoo Park wrote:
> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
> 
> The function ieee80211_ioctl_siwencode shouldn't be called if
> authentication process is not completed.
> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
> is completed.
> 
> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>

Helge,

Can you please try this patch?
I believe this patch helps your problem.

Thanks,
Joonwoo

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Helge Hafting]

Joonwoo Park wrote:
> On Wed, Mar 05, 2008 at 06:40:09PM +0900, Joonwoo Park wrote:
>   
>> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
>>
>> The function ieee80211_ioctl_siwencode shouldn't be called if
>> authentication process is not completed.
>> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
>> is completed.
>>
>> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
>>     
>
> Helge,
>
> Can you please try this patch?
> I believe this patch helps your problem.
>   
I tried it, and still have problems. The messages may be slightly different:

I first bring up the interface with "ifconfig wlan0 up"
and then try "iwconfig wlan0 essid my_essid key s:password"
over and over till it works. This gave me:

Initial auth_alg=0
wlan0: authenticate with AP 00:14:1b:5e:13:40
wlan0: authenticate with AP 00:14:1b:5e:13:40
wlan0: authenticate with AP 00:14:1b:5e:13:40
wlan0: authentication with AP 00:14:1b:5e:13:40 timed out

A total of 5 tries went wrong. The sixth time it worked, with
different messages and a different access point.
(There are several access points at work.)
Initial auth_alg=0
wlan0: authenticate with AP 00:12:7f:ce:9c:e0
wlan0: RX authentication from 00:12:7f:ce:9c:e0 (alg=0 transaction=2 
status=0)
wlan0: authenticated
wlan0: associate with AP 00:12:7f:ce:9c:e0 (capab=0x431 status=0 aid=242)
wlan0: associated
wlan0: CTS protection enabled (BSSID=00:12:7f:ce:9c:e0)
wlan0: switched to long barker preamble (BSSID=BSSID=00:12:7f:ce:9c:e0)
wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0
wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0
wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
wlan0: link becomes ready


Only 6 attempts is an improvement, if it stays that way.  Still, the
old ipw3945 succeeded on first try. :-/
I hope the testing can be of help.

Helge Hafting

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Tomas Winkler]

On Wed, Mar 5, 2008 at 3:53 PM, Helge Hafting
<helge.hafting@aitel.hist.no> wrote:
> Joonwoo Park wrote:
>  > On Wed, Mar 05, 2008 at 06:40:09PM +0900, Joonwoo Park wrote:
>  >
>  >> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
>  >>
>  >> The function ieee80211_ioctl_siwencode shouldn't be called if
>  >> authentication process is not completed.
>  >> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
>  >> is completed.
>  >>
>  >> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
>  >>
>  >
>  > Helge,
>  >
>  > Can you please try this patch?
>  > I believe this patch helps your problem.
>  >
>  I tried it, and still have problems. The messages may be slightly different:
>
>  I first bring up the interface with "ifconfig wlan0 up"
>  and then try "iwconfig wlan0 essid my_essid key s:password"
>  over and over till it works. This gave me:
>
>  Initial auth_alg=0
>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>  wlan0: authentication with AP 00:14:1b:5e:13:40 timed out
>
>  A total of 5 tries went wrong. The sixth time it worked, with
>  different messages and a different access point.
>  (There are several access points at work.)
>  Initial auth_alg=0
>  wlan0: authenticate with AP 00:12:7f:ce:9c:e0
>  wlan0: RX authentication from 00:12:7f:ce:9c:e0 (alg=0 transaction=2
>  status=0)
>  wlan0: authenticated
>  wlan0: associate with AP 00:12:7f:ce:9c:e0 (capab=0x431 status=0 aid=242)
>  wlan0: associated
>  wlan0: CTS protection enabled (BSSID=00:12:7f:ce:9c:e0)
>  wlan0: switched to long barker preamble (BSSID=BSSID=00:12:7f:ce:9c:e0)
>  wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0
>  wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0
>  wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
>  wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
>  wlan0: link becomes ready
>
>
>  Only 6 attempts is an improvement, if it stays that way.  Still, the
>  old ipw3945 succeeded on first try. :-/
>  I hope the testing can be of help.
>
>  Helge Hafting
>
>
>
Is this shared or open authentication?
Do you happend to have a sniff capture of the association ?
>
>  --
>  To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Helge Hafting]

Tomas Winkler wrote:
> On Wed, Mar 5, 2008 at 3:53 PM, Helge Hafting
> <helge.hafting@aitel.hist.no> wrote:
>   
>> Joonwoo Park wrote:
>>  > On Wed, Mar 05, 2008 at 06:40:09PM +0900, Joonwoo Park wrote:
>>  >
>>  >> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
>>  >>
>>  >> The function ieee80211_ioctl_siwencode shouldn't be called if
>>  >> authentication process is not completed.
>>  >> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
>>  >> is completed.
>>  >>
>>  >> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
>>  >>
>>  >
>>  > Helge,
>>  >
>>  > Can you please try this patch?
>>  > I believe this patch helps your problem.
>>  >
>>  I tried it, and still have problems. The messages may be slightly different:
>>
>>  I first bring up the interface with "ifconfig wlan0 up"
>>  and then try "iwconfig wlan0 essid my_essid key s:password"
>>  over and over till it works. This gave me:
>>
>>  Initial auth_alg=0
>>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>>  wlan0: authentication with AP 00:14:1b:5e:13:40 timed out
>>
>>  A total of 5 tries went wrong. The sixth time it worked, with
>>  different messages and a different access point.
>>  (There are several access points at work.)
>>  Initial auth_alg=0
>>  wlan0: authenticate with AP 00:12:7f:ce:9c:e0
>>  wlan0: RX authentication from 00:12:7f:ce:9c:e0 (alg=0 transaction=2
>>  status=0)
>>  wlan0: authenticated
>>  wlan0: associate with AP 00:12:7f:ce:9c:e0 (capab=0x431 status=0 aid=242)
>>  wlan0: associated
>>  wlan0: CTS protection enabled (BSSID=00:12:7f:ce:9c:e0)
>>  wlan0: switched to long barker preamble (BSSID=BSSID=00:12:7f:ce:9c:e0)
>>  wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0
>>  wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0
>>  wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
>>  wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
>>  wlan0: link becomes ready
>>
>>
>>  Only 6 attempts is an improvement, if it stays that way.  Still, the
>>  old ipw3945 succeeded on first try. :-/
>>  I hope the testing can be of help.
>>
>>  Helge Hafting
>>
>>
>>
>>     
> Is this shared or open authentication?
> Do you happend to have a sniff capture of the association ?
I am not sure what you mean by the question.
This network uses WEP encryption (some users have older wireless equipment)
there is one essid and a single shared password that everybody uses.
Security is not that important, this is mostly to keep out outside bandwith
wasters/pirates.

I do not have a sniff of this association, but I can try to sniff the 
next time.
will wireshark be useful, or is some kind of wireless specific sniffer 
needed?


Helge Hafting

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Tomas Winkler]

On Thu, Mar 6, 2008 at 4:01 PM, Helge Hafting
<helgehaf@mail.aitel.hist.no> wrote:
>
> Tomas Winkler wrote:
>  > On Wed, Mar 5, 2008 at 3:53 PM, Helge Hafting
>  > <helge.hafting@aitel.hist.no> wrote:
>  >
>  >> Joonwoo Park wrote:
>  >>  > On Wed, Mar 05, 2008 at 06:40:09PM +0900, Joonwoo Park wrote:
>  >>  >
>  >>  >> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
>  >>  >>
>  >>  >> The function ieee80211_ioctl_siwencode shouldn't be called if
>  >>  >> authentication process is not completed.
>  >>  >> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
>  >>  >> is completed.
>  >>  >>
>  >>  >> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
>  >>  >>
>  >>  >
>  >>  > Helge,
>  >>  >
>  >>  > Can you please try this patch?
>  >>  > I believe this patch helps your problem.
>  >>  >
>  >>  I tried it, and still have problems. The messages may be slightly different:
>  >>
>  >>  I first bring up the interface with "ifconfig wlan0 up"
>  >>  and then try "iwconfig wlan0 essid my_essid key s:password"
>  >>  over and over till it works. This gave me:
>  >>
>  >>  Initial auth_alg=0
>  >>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>  >>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>  >>  wlan0: authenticate with AP 00:14:1b:5e:13:40
>  >>  wlan0: authentication with AP 00:14:1b:5e:13:40 timed out
>  >>
>  >>  A total of 5 tries went wrong. The sixth time it worked, with
>  >>  different messages and a different access point.
>  >>  (There are several access points at work.)
>  >>  Initial auth_alg=0
>  >>  wlan0: authenticate with AP 00:12:7f:ce:9c:e0
>  >>  wlan0: RX authentication from 00:12:7f:ce:9c:e0 (alg=0 transaction=2
>  >>  status=0)
>  >>  wlan0: authenticated
>  >>  wlan0: associate with AP 00:12:7f:ce:9c:e0 (capab=0x431 status=0 aid=242)
>  >>  wlan0: associated
>  >>  wlan0: CTS protection enabled (BSSID=00:12:7f:ce:9c:e0)
>  >>  wlan0: switched to long barker preamble (BSSID=BSSID=00:12:7f:ce:9c:e0)
>  >>  wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0
>  >>  wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0
>  >>  wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
>  >>  wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
>  >>  wlan0: link becomes ready
>  >>
>  >>
>  >>  Only 6 attempts is an improvement, if it stays that way.  Still, the
>  >>  old ipw3945 succeeded on first try. :-/
>  >>  I hope the testing can be of help.
>  >>
>  >>  Helge Hafting
>  >>
>  >>
>  >>
>  >>
>  > Is this shared or open authentication?
>  > Do you happend to have a sniff capture of the association ?
>  I am not sure what you mean by the question.


>  This network uses WEP encryption (some users have older wireless equipment)
>  there is one essid and a single shared password that everybody uses.
>  Security is not that important, this is mostly to keep out outside bandwith
>  wasters/pirates.
>
If also authentication uses WEP key (4 way handshake) or not (2 way
handshake) only data is encrypted.
You can know this from your AP configureation

>  I do not have a sniff of this association, but I can try to sniff the
>  next time.
>  will wireshark be useful, or is some kind of wireless specific sniffer
>  needed?

That would be enough if you can give us the capture of failed
association process.

Currently mac80211 has wrong implementation of static WEP key handling
but it shows up only in certain scenarios


>
>  Helge Hafting
>

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Dan Williams]

On Thu, 2008-03-06 at 15:01 +0100, Helge Hafting wrote:
> Tomas Winkler wrote:
> > On Wed, Mar 5, 2008 at 3:53 PM, Helge Hafting
> > <helge.hafting@aitel.hist.no> wrote:
> >   
> >> Joonwoo Park wrote:
> >>  > On Wed, Mar 05, 2008 at 06:40:09PM +0900, Joonwoo Park wrote:
> >>  >
> >>  >> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
> >>  >>
> >>  >> The function ieee80211_ioctl_siwencode shouldn't be called if
> >>  >> authentication process is not completed.
> >>  >> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
> >>  >> is completed.
> >>  >>
> >>  >> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
> >>  >>
> >>  >
> >>  > Helge,
> >>  >
> >>  > Can you please try this patch?
> >>  > I believe this patch helps your problem.
> >>  >
> >>  I tried it, and still have problems. The messages may be slightly different:
> >>
> >>  I first bring up the interface with "ifconfig wlan0 up"
> >>  and then try "iwconfig wlan0 essid my_essid key s:password"
> >>  over and over till it works. This gave me:
> >>
> >>  Initial auth_alg=0
> >>  wlan0: authenticate with AP 00:14:1b:5e:13:40
> >>  wlan0: authenticate with AP 00:14:1b:5e:13:40
> >>  wlan0: authenticate with AP 00:14:1b:5e:13:40
> >>  wlan0: authentication with AP 00:14:1b:5e:13:40 timed out
> >>
> >>  A total of 5 tries went wrong. The sixth time it worked, with
> >>  different messages and a different access point.
> >>  (There are several access points at work.)
> >>  Initial auth_alg=0
> >>  wlan0: authenticate with AP 00:12:7f:ce:9c:e0
> >>  wlan0: RX authentication from 00:12:7f:ce:9c:e0 (alg=0 transaction=2
> >>  status=0)
> >>  wlan0: authenticated
> >>  wlan0: associate with AP 00:12:7f:ce:9c:e0 (capab=0x431 status=0 aid=242)
> >>  wlan0: associated
> >>  wlan0: CTS protection enabled (BSSID=00:12:7f:ce:9c:e0)
> >>  wlan0: switched to long barker preamble (BSSID=BSSID=00:12:7f:ce:9c:e0)
> >>  wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0
> >>  wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0
> >>  wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
> >>  wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
> >>  wlan0: link becomes ready
> >>
> >>
> >>  Only 6 attempts is an improvement, if it stays that way.  Still, the
> >>  old ipw3945 succeeded on first try. :-/
> >>  I hope the testing can be of help.
> >>
> >>  Helge Hafting
> >>
> >>
> >>
> >>     
> > Is this shared or open authentication?
> > Do you happend to have a sniff capture of the association ?
> I am not sure what you mean by the question.
> This network uses WEP encryption (some users have older wireless equipment)
> there is one essid and a single shared password that everybody uses.
> Security is not that important, this is mostly to keep out outside bandwith
> wasters/pirates.

WEP has two authentication modes, "Shared Key" and "Open System".  He
wants to know which method your access point is using.  During
authentication, Open System is a simple two-frame request/response.  For
Shared Key, there's an additional challenge/response where the AP sends
a block of data, the client encrypts it with the WEP key, and sends it
back to the AP where it's verified.  Only if it verifies does the AP
complete association with the client.

You need to ensure that the mode matches between clients and the AP.
Some APs have an "Auto" option that just accepts both methods from the
client.

Dan

> I do not have a sniff of this association, but I can try to sniff the 
> next time.
> will wireshark be useful, or is some kind of wireless specific sniffer 
> needed?
> 
> 
> Helge Hafting
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Helge Hafting]

Dan Williams wrote:
>> I am not sure what you mean by the question.
>> This network uses WEP encryption (some users have older wireless equipment)
>> there is one essid and a single shared password that everybody uses.
>> Security is not that important, this is mostly to keep out outside bandwith
>> wasters/pirates.
>>     
>
> WEP has two authentication modes, "Shared Key" and "Open System".  He
> wants to know which method your access point is using.  During
> authentication, Open System is a simple two-frame request/response.  For
> Shared Key, there's an additional challenge/response where the AP sends
> a block of data, the client encrypts it with the WEP key, and sends it
> back to the AP where it's verified.  Only if it verifies does the AP
> complete association with the client.
>   
Well, how can I know? The access point at home is set to support
WEP and WPA, and of course I can specify the key. There doesn't
seem to be much more than that. I have no control over the
access points at work, although I could ask the people involved.

> You need to ensure that the mode matches between clients and the AP.
> Some APs have an "Auto" option that just accepts both methods from the
> client.
>   
I have to ensure this? I thought this was a driver-internal thing, I 
have not
seen any mention of this in wireless documentation before.
'man iwconfig' doesn't seem to mention this, and it used to be sufficient
to get a connection before.

If this is debug stuff, please tell how I can get the information. I can
add debugging options to the kernel command line if need be. (The driver
is compiled-in, modules tend to cause bootup delays.)

I tried to sniff wlan0 with wireshark. I did not get anything there until
after the association completed. Then I got normal stuff like dhcp
and other traffic. So I don't have any sniff of the association itself.
Is there some special options for enabling this, or do I need a 
different tool?

The siwencode/siwessid patch has helped a lot. The machine sometimes
succeed to connect at first try (during bootup) and almost
always at the second try.  The driver is not perfect yet, but it improved
a _lot_ for me.  Thanks - and I hope this gets into the next regular 
linux kernel. :-)

Another problem is that going out of range for an hour means I have to
do something to get a net connection again. This does not seem to
happen automatic, although I have not yet checked if it merely is
a dhcp timeout problem.

Helge Hafting

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Dan Williams]

On Sun, 2008-03-09 at 12:52 +0100, Helge Hafting wrote:
> Dan Williams wrote:
> >> I am not sure what you mean by the question.
> >> This network uses WEP encryption (some users have older wireless equipment)
> >> there is one essid and a single shared password that everybody uses.
> >> Security is not that important, this is mostly to keep out outside bandwith
> >> wasters/pirates.
> >>     
> >
> > WEP has two authentication modes, "Shared Key" and "Open System".  He
> > wants to know which method your access point is using.  During
> > authentication, Open System is a simple two-frame request/response.  For
> > Shared Key, there's an additional challenge/response where the AP sends
> > a block of data, the client encrypts it with the WEP key, and sends it
> > back to the AP where it's verified.  Only if it verifies does the AP
> > complete association with the client.
> >   
> Well, how can I know? The access point at home is set to support
> WEP and WPA, and of course I can specify the key. There doesn't
> seem to be much more than that. I have no control over the
> access points at work, although I could ask the people involved.

With WEP, you can't know what authentication mode the AP is set to.
It's not broadcast in the beacons or probe responses.  You also can't
know whether the key length is 40 or 104 bits either.  WEP sucks.  You
just have to know what parameters your admin is using, or try a couple
times.

> > You need to ensure that the mode matches between clients and the AP.
> > Some APs have an "Auto" option that just accepts both methods from the
> > client.
> >   
> I have to ensure this? I thought this was a driver-internal thing, I 
> have not
> seen any mention of this in wireless documentation before.
> 'man iwconfig' doesn't seem to mention this, and it used to be sufficient
> to get a connection before.

You simply have to know what WEP authentication your wireless network is
using.

> If this is debug stuff, please tell how I can get the information. I can
> add debugging options to the kernel command line if need be. (The driver
> is compiled-in, modules tend to cause bootup delays.)

The way to associate with Shared Key is:

iwconfig wlan0 key xxxxxxx restricted essid foobar

Open System is:

iwconfig wlan0 key xxxxxxx open essid foobar

> I tried to sniff wlan0 with wireshark. I did not get anything there until
> after the association completed. Then I got normal stuff like dhcp
> and other traffic. So I don't have any sniff of the association itself.
> Is there some special options for enabling this, or do I need a 
> different tool?

You might need another machine that can sniff the traffic between your
first one and the AP.  I'm not completely up on the monitor mode/rtap
stuff.

> The siwencode/siwessid patch has helped a lot. The machine sometimes
> succeed to connect at first try (during bootup) and almost
> always at the second try.  The driver is not perfect yet, but it improved
> a _lot_ for me.  Thanks - and I hope this gets into the next regular 
> linux kernel. :-)

That's nice, but the patch is still wrong.  It's not going to go into
the next kernel release until it's right.  I'm certainly going to give
it a big fat NAK if it shows up again in its current form.  No driver
should ever block in the SIWESSID or SIWBSSID handlers; they have to
handle the options correctly.

> Another problem is that going out of range for an hour means I have to
> do something to get a net connection again. This does not seem to
> happen automatic, although I have not yet checked if it merely is
> a dhcp timeout problem.

The driver isn't supposed to contain a ton of logic and policy about
what networks you connect to and what ones you don't.  That's what
userspace does.  You'll likely need some userspace program
(NetworkManager, wpa_supplicant, etc) that stores that policy and
controls what you connect to, including reconnecting to your last used
networks.

Dan

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]


On Wed, 2008-03-05 at 18:40 +0900, Joonwoo Park wrote:
> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
> 
> The function ieee80211_ioctl_siwencode shouldn't be called if
> authentication process is not completed.
> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
> is completed.

This looks wrong. You could restart association when a key is set but
really the race is by design in WEXT so the only way to fix it is to set
the key first.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Joonwoo Park]

2008/3/5, Johannes Berg <johannes@sipsolutions.net>:
>
> On Wed, 2008-03-05 at 18:40 +0900, Joonwoo Park wrote:
> > resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
> >
> > The function ieee80211_ioctl_siwencode shouldn't be called if
> > authentication process is not completed.
> > This patch makes the ieee80211_ioctl_siwessid to wait for authentication
> > is completed.
>

Johannes,
Thank you for reviewing this.

> This looks wrong. You could restart association when a key is set but
> really the race is by design in WEXT so the only way to fix it is to set
> the key first.
>

Do you mean fix iwconfig to always do set key before set essid?
As you said, It could be a possible solution.
But, doing It cannot solve a race from two seperated iwconfig process, I think.
(eg: iwconfig essid ESSID; iwconfig enc ENC)
Moreover, now we just wake auth request task up and return when setting essid.
Don't we need to wait a moment until the task is scheduled to be
polite to iwconifg? :)

Thanks,
Joonwoo

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]


> > This looks wrong. You could restart association when a key is set but
> > really the race is by design in WEXT so the only way to fix it is to set
> > the key first.
> >
> 
> Do you mean fix iwconfig to always do set key before set essid?

Well, no, I think it's more of a user error, I always do 
   iwconfig enc ENC; iwconfig essid SSID
in that order.

> But, doing It cannot solve a race from two seperated iwconfig process, I think.
> (eg: iwconfig essid ESSID; iwconfig enc ENC)

Yeah, that's pretty ugly to start with.

> Moreover, now we just wake auth request task up and return when setting essid.
> Don't we need to wait a moment until the task is scheduled to be
> polite to iwconifg? :)

I think the only way to properly handle it is to reset the association
state machine when a key is added. Dan, what's the expected behaviour?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Dan Williams]

On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote:
> > > This looks wrong. You could restart association when a key is set but
> > > really the race is by design in WEXT so the only way to fix it is to set
> > > the key first.
> > >
> > 
> > Do you mean fix iwconfig to always do set key before set essid?
> 
> Well, no, I think it's more of a user error, I always do 
>    iwconfig enc ENC; iwconfig essid SSID
> in that order.
> 
> > But, doing It cannot solve a race from two seperated iwconfig process, I think.
> > (eg: iwconfig essid ESSID; iwconfig enc ENC)
> 
> Yeah, that's pretty ugly to start with.

See below for a partial solution; but even with nl80211/cfg80211, if you
have more than one process trying to control the wireless card
concurrently you have already lost.  Don't Do That.

> > Moreover, now we just wake auth request task up and return when setting essid.
> > Don't we need to wait a moment until the task is scheduled to be
> > polite to iwconifg? :)
> 
> I think the only way to properly handle it is to reset the association
> state machine when a key is added. Dan, what's the expected behaviour?

The best way to implement the WEXT stuff is to have a timeout of about
500ms - 700ms or so to batch WEXT stuff together.  Each new WEXT command
that comes in before the timeout pushes the timeout back.  When the
timeout triggers, all the new commands are executed in the driver in the
order the driver expects.  That fixes most issues with chaining WEXT
commands and makes all of these Just Work:

iwconfig wlan0 essid foo key 253325353 open channel 11
iwconfig wlan0 key 253325353 open essid foo channel 11
iwconfig wlan0 channel 11 key 253325353 open essid foo

Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits
500ms, the timeout triggers, and the driver changes to channel 6 and
starts the association process all over with the current settings (keys,
BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event
on both success and failure.

If you just do 'iwconfig wlan0 rate 11' then of course the driver
doesn't need to trigger reassociation after the WEXT command timeout, it
just needs to lock the bitrate.

The _explicit_ triggers for association/reassociation are setting the
BSSID or the SSID.  In that case, the driver takes the new BSSID/SSID
and all the cached config, and tries to associate with that after the
timeout triggers.  The driver may choose to trigger reassociation if a
WEXT command would require so, but it shouldn't do the reassociation
until the timeout occurs.

I've implemented this in the libertas driver's assoc.c/wext.c if you
want to take a look at what's happening there.  The implementation isn't
perfect, but it's about what's required to work properly with WEXT.

Dan

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Tomas Winkler]

On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote:
>  > > > This looks wrong. You could restart association when a key is set but
>  > > > really the race is by design in WEXT so the only way to fix it is to set
>  > > > the key first.
>  > > >
>  > >
>  > > Do you mean fix iwconfig to always do set key before set essid?
>  >
>  > Well, no, I think it's more of a user error, I always do
>  >    iwconfig enc ENC; iwconfig essid SSID
>  > in that order.
>  >
>  > > But, doing It cannot solve a race from two seperated iwconfig process, I think.
>  > > (eg: iwconfig essid ESSID; iwconfig enc ENC)
>  >
>  > Yeah, that's pretty ugly to start with.
>
>  See below for a partial solution; but even with nl80211/cfg80211, if you
>  have more than one process trying to control the wireless card
>  concurrently you have already lost.  Don't Do That.
>
>
>  > > Moreover, now we just wake auth request task up and return when setting essid.
>  > > Don't we need to wait a moment until the task is scheduled to be
>  > > polite to iwconifg? :)
>  >
>  > I think the only way to properly handle it is to reset the association
>  > state machine when a key is added. Dan, what's the expected behaviour?
>
>  The best way to implement the WEXT stuff is to have a timeout of about
>  500ms - 700ms or so to batch WEXT stuff together.  Each new WEXT command
>  that comes in before the timeout pushes the timeout back.  When the
>  timeout triggers, all the new commands are executed in the driver in the
>  order the driver expects.  That fixes most issues with chaining WEXT
>  commands and makes all of these Just Work:
>
>  iwconfig wlan0 essid foo key 253325353 open channel 11
>  iwconfig wlan0 key 253325353 open essid foo channel 11
>  iwconfig wlan0 channel 11 key 253325353 open essid foo
>
>  Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits
>  500ms, the timeout triggers, and the driver changes to channel 6 and
>  starts the association process all over with the current settings (keys,
>  BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event
>  on both success and failure.
>
>  If you just do 'iwconfig wlan0 rate 11' then of course the driver
>  doesn't need to trigger reassociation after the WEXT command timeout, it
>  just needs to lock the bitrate.
>
>  The _explicit_ triggers for association/reassociation are setting the
>  BSSID or the SSID.

Currently there is a quite a mess that both BSSID and SSID triggers
association.
iwconfig essid AP1
iwconfig ap "00:....." - (bssid of myap)
iwconfig essid AP2

what will be result of this? will it try to associate with AP1:BSSID
but AP2 SSID


Tomas

>
>
>  --
>  To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Dan Williams]

On Wed, 2008-03-05 at 20:53 +0200, Tomas Winkler wrote:
> On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams <dcbw@redhat.com> wrote:
> > On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote:
> >  > > > This looks wrong. You could restart association when a key is set but
> >  > > > really the race is by design in WEXT so the only way to fix it is to set
> >  > > > the key first.
> >  > > >
> >  > >
> >  > > Do you mean fix iwconfig to always do set key before set essid?
> >  >
> >  > Well, no, I think it's more of a user error, I always do
> >  >    iwconfig enc ENC; iwconfig essid SSID
> >  > in that order.
> >  >
> >  > > But, doing It cannot solve a race from two seperated iwconfig process, I think.
> >  > > (eg: iwconfig essid ESSID; iwconfig enc ENC)
> >  >
> >  > Yeah, that's pretty ugly to start with.
> >
> >  See below for a partial solution; but even with nl80211/cfg80211, if you
> >  have more than one process trying to control the wireless card
> >  concurrently you have already lost.  Don't Do That.
> >
> >
> >  > > Moreover, now we just wake auth request task up and return when setting essid.
> >  > > Don't we need to wait a moment until the task is scheduled to be
> >  > > polite to iwconifg? :)
> >  >
> >  > I think the only way to properly handle it is to reset the association
> >  > state machine when a key is added. Dan, what's the expected behaviour?
> >
> >  The best way to implement the WEXT stuff is to have a timeout of about
> >  500ms - 700ms or so to batch WEXT stuff together.  Each new WEXT command
> >  that comes in before the timeout pushes the timeout back.  When the
> >  timeout triggers, all the new commands are executed in the driver in the
> >  order the driver expects.  That fixes most issues with chaining WEXT
> >  commands and makes all of these Just Work:
> >
> >  iwconfig wlan0 essid foo key 253325353 open channel 11
> >  iwconfig wlan0 key 253325353 open essid foo channel 11
> >  iwconfig wlan0 channel 11 key 253325353 open essid foo
> >
> >  Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits
> >  500ms, the timeout triggers, and the driver changes to channel 6 and
> >  starts the association process all over with the current settings (keys,
> >  BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event
> >  on both success and failure.
> >
> >  If you just do 'iwconfig wlan0 rate 11' then of course the driver
> >  doesn't need to trigger reassociation after the WEXT command timeout, it
> >  just needs to lock the bitrate.
> >
> >  The _explicit_ triggers for association/reassociation are setting the
> >  BSSID or the SSID.
> 
> Currently there is a quite a mess that both BSSID and SSID triggers
> association.
> iwconfig essid AP1
> iwconfig ap "00:....." - (bssid of myap)
> iwconfig essid AP2
> 
> what will be result of this? will it try to associate with AP1:BSSID
> but AP2 SSID

In the current, not-timeout situation, the driver would probably attempt
to associate to AP1/any, and be interrupted by the BSSID lock of the
second command, and then try to associate to AP1/00:..., then be
interrupted by the third command.

Then, it should fail if there is no BSSID "00:..." with an SSID of
"AP2".  The user must clear the BSSID lock by doing 'iwconfig ap any'
and then the driver is free to use any BSSID in it's scan list that
matches SSID AP2 and security settings currently configured in the
driver.

Remember, WEXT commands are _cumulative_ unless cleared by the user.

Dan

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Tomas Winkler]

On Wed, Mar 5, 2008 at 9:19 PM, Dan Williams <dcbw@redhat.com> wrote:
>
> On Wed, 2008-03-05 at 20:53 +0200, Tomas Winkler wrote:
>  > On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams <dcbw@redhat.com> wrote:
>  > > On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote:
>  > >  > > > This looks wrong. You could restart association when a key is set but
>  > >  > > > really the race is by design in WEXT so the only way to fix it is to set
>  > >  > > > the key first.
>  > >  > > >
>  > >  > >
>  > >  > > Do you mean fix iwconfig to always do set key before set essid?
>  > >  >
>  > >  > Well, no, I think it's more of a user error, I always do
>  > >  >    iwconfig enc ENC; iwconfig essid SSID
>  > >  > in that order.
>  > >  >
>  > >  > > But, doing It cannot solve a race from two seperated iwconfig process, I think.
>  > >  > > (eg: iwconfig essid ESSID; iwconfig enc ENC)
>  > >  >
>  > >  > Yeah, that's pretty ugly to start with.
>  > >
>  > >  See below for a partial solution; but even with nl80211/cfg80211, if you
>  > >  have more than one process trying to control the wireless card
>  > >  concurrently you have already lost.  Don't Do That.
>  > >
>  > >
>  > >  > > Moreover, now we just wake auth request task up and return when setting essid.
>  > >  > > Don't we need to wait a moment until the task is scheduled to be
>  > >  > > polite to iwconifg? :)
>  > >  >
>  > >  > I think the only way to properly handle it is to reset the association
>  > >  > state machine when a key is added. Dan, what's the expected behaviour?
>  > >
>  > >  The best way to implement the WEXT stuff is to have a timeout of about
>  > >  500ms - 700ms or so to batch WEXT stuff together.  Each new WEXT command
>  > >  that comes in before the timeout pushes the timeout back.  When the
>  > >  timeout triggers, all the new commands are executed in the driver in the
>  > >  order the driver expects.  That fixes most issues with chaining WEXT
>  > >  commands and makes all of these Just Work:
>  > >
>  > >  iwconfig wlan0 essid foo key 253325353 open channel 11
>  > >  iwconfig wlan0 key 253325353 open essid foo channel 11
>  > >  iwconfig wlan0 channel 11 key 253325353 open essid foo
>  > >
>  > >  Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits
>  > >  500ms, the timeout triggers, and the driver changes to channel 6 and
>  > >  starts the association process all over with the current settings (keys,
>  > >  BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event
>  > >  on both success and failure.
>  > >
>  > >  If you just do 'iwconfig wlan0 rate 11' then of course the driver
>  > >  doesn't need to trigger reassociation after the WEXT command timeout, it
>  > >  just needs to lock the bitrate.
>  > >
>  > >  The _explicit_ triggers for association/reassociation are setting the
>  > >  BSSID or the SSID.
>  >
>  > Currently there is a quite a mess that both BSSID and SSID triggers
>  > association.
>  > iwconfig essid AP1
>  > iwconfig ap "00:....." - (bssid of myap)
>  > iwconfig essid AP2
>  >
>  > what will be result of this? will it try to associate with AP1:BSSID
>  > but AP2 SSID
>
>  In the current, not-timeout situation, the driver would probably attempt
>  to associate to AP1/any, and be interrupted by the BSSID lock of the
>  second command, and then try to associate to AP1/00:..., then be
>  interrupted by the third command.
>
>  Then, it should fail if there is no BSSID "00:..." with an SSID of
>  "AP2".  The user must clear the BSSID lock by doing 'iwconfig ap any'
>  and then the driver is free to use any BSSID in it's scan list that
>  matches SSID AP2 and security settings currently configured in the
>  driver.
>
>  Remember, WEXT commands are _cumulative_ unless cleared by the user.

It's mac80211 decision when to start association. I suggest to
associate only on SSID command
if someone wants to trigger BSSID association it would call SSID ANY
call explicitly. This will definitely reduce the mess
I'm seeing now.

I'm using Fedora 8 for development and I'm still cannot figure what
services are trying to access wireless
devices but association is always failing because SSID is switched
between authentication and association frames.
It started to work a bit when I've disabled avahi and disabled dhcp on
the device. (dhcp running after association is fine)





Thanks
Tomas

>  Dan
>
>
>

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Dan Williams]

On Wed, 2008-03-05 at 22:50 +0200, Tomas Winkler wrote:
> On Wed, Mar 5, 2008 at 9:19 PM, Dan Williams <dcbw@redhat.com> wrote:
> >
> > On Wed, 2008-03-05 at 20:53 +0200, Tomas Winkler wrote:
> >  > On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams <dcbw@redhat.com> wrote:
> >  > > On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote:
> >  > >  > > > This looks wrong. You could restart association when a key is set but
> >  > >  > > > really the race is by design in WEXT so the only way to fix it is to set
> >  > >  > > > the key first.
> >  > >  > > >
> >  > >  > >
> >  > >  > > Do you mean fix iwconfig to always do set key before set essid?
> >  > >  >
> >  > >  > Well, no, I think it's more of a user error, I always do
> >  > >  >    iwconfig enc ENC; iwconfig essid SSID
> >  > >  > in that order.
> >  > >  >
> >  > >  > > But, doing It cannot solve a race from two seperated iwconfig process, I think.
> >  > >  > > (eg: iwconfig essid ESSID; iwconfig enc ENC)
> >  > >  >
> >  > >  > Yeah, that's pretty ugly to start with.
> >  > >
> >  > >  See below for a partial solution; but even with nl80211/cfg80211, if you
> >  > >  have more than one process trying to control the wireless card
> >  > >  concurrently you have already lost.  Don't Do That.
> >  > >
> >  > >
> >  > >  > > Moreover, now we just wake auth request task up and return when setting essid.
> >  > >  > > Don't we need to wait a moment until the task is scheduled to be
> >  > >  > > polite to iwconifg? :)
> >  > >  >
> >  > >  > I think the only way to properly handle it is to reset the association
> >  > >  > state machine when a key is added. Dan, what's the expected behaviour?
> >  > >
> >  > >  The best way to implement the WEXT stuff is to have a timeout of about
> >  > >  500ms - 700ms or so to batch WEXT stuff together.  Each new WEXT command
> >  > >  that comes in before the timeout pushes the timeout back.  When the
> >  > >  timeout triggers, all the new commands are executed in the driver in the
> >  > >  order the driver expects.  That fixes most issues with chaining WEXT
> >  > >  commands and makes all of these Just Work:
> >  > >
> >  > >  iwconfig wlan0 essid foo key 253325353 open channel 11
> >  > >  iwconfig wlan0 key 253325353 open essid foo channel 11
> >  > >  iwconfig wlan0 channel 11 key 253325353 open essid foo
> >  > >
> >  > >  Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits
> >  > >  500ms, the timeout triggers, and the driver changes to channel 6 and
> >  > >  starts the association process all over with the current settings (keys,
> >  > >  BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event
> >  > >  on both success and failure.
> >  > >
> >  > >  If you just do 'iwconfig wlan0 rate 11' then of course the driver
> >  > >  doesn't need to trigger reassociation after the WEXT command timeout, it
> >  > >  just needs to lock the bitrate.
> >  > >
> >  > >  The _explicit_ triggers for association/reassociation are setting the
> >  > >  BSSID or the SSID.
> >  >
> >  > Currently there is a quite a mess that both BSSID and SSID triggers
> >  > association.
> >  > iwconfig essid AP1
> >  > iwconfig ap "00:....." - (bssid of myap)
> >  > iwconfig essid AP2
> >  >
> >  > what will be result of this? will it try to associate with AP1:BSSID
> >  > but AP2 SSID
> >
> >  In the current, not-timeout situation, the driver would probably attempt
> >  to associate to AP1/any, and be interrupted by the BSSID lock of the
> >  second command, and then try to associate to AP1/00:..., then be
> >  interrupted by the third command.
> >
> >  Then, it should fail if there is no BSSID "00:..." with an SSID of
> >  "AP2".  The user must clear the BSSID lock by doing 'iwconfig ap any'
> >  and then the driver is free to use any BSSID in it's scan list that
> >  matches SSID AP2 and security settings currently configured in the
> >  driver.
> >
> >  Remember, WEXT commands are _cumulative_ unless cleared by the user.
> 
> It's mac80211 decision when to start association. I suggest to

Ultimately, yes the driver controls association, but in WEXT association
is triggered by setting the SSID or the BSSID.  Outside of SSID/BSSID,
the driver should trigger reassociation when it needs to.  But BSSID and
SSID MUST always trigger a new association.

> associate only on SSID command
> if someone wants to trigger BSSID association it would call SSID ANY
> call explicitly. This will definitely reduce the mess
> I'm seeing now.

No, that's not enough for implementing WEXT.  I don't really see what
the problem is here?  Why is it currently a mess (other than that WEXT
is a mess)?  It's pretty clear to me; if you ever execute an 'iwconfig'
call that is not 'any' or '0', that attribute is locked in the driver
until you unlock it.  End of story.

That's the conformant case; not all drivers implement it that way.

If you do:

iwconfig wlan0 essid "foobar"
iwconfig wlan0 bssid 12:34:56:78:90:12
iwconfig wlan0 essid "baz"

and there is no AP of SSID=baz and BSSID=12:34:56:78:90:12, then the
association MUST fail because both the SSID and BSSID attributes are
locked in the driver.  They MUST be locked in the driver until one or
more of them is cleared or changed, at which point another association
must occur.

> I'm using Fedora 8 for development and I'm still cannot figure what
> services are trying to access wireless
> devices but association is always failing because SSID is switched
> between authentication and association frames.
> It started to work a bit when I've disabled avahi and disabled dhcp on
> the device. (dhcp running after association is fine)

How about:

/sbin/service NetworkManager stop

and:

killall -TERM wpa_supplicant

If either NM or wpa_supplicant are running, commands from iwconfig will
likely fail because there are two things trying to drive the wireless
device.  Just don't do that; because during driver development you need
to control the environment obviously.

another problem is drivers that do autoassociation; like ipw2200's
'associate=x' parameter.  That allows the driver to automatically
associate to anything it can find, which causes no end of problems.
That's wrong.

Dan

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Tomas Winkler]

On Wed, Mar 5, 2008 at 11:23 PM, Dan Williams <dcbw@redhat.com> wrote:
>
> On Wed, 2008-03-05 at 22:50 +0200, Tomas Winkler wrote:
>  > On Wed, Mar 5, 2008 at 9:19 PM, Dan Williams <dcbw@redhat.com> wrote:
>  > >
>  > > On Wed, 2008-03-05 at 20:53 +0200, Tomas Winkler wrote:
>  > >  > On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams <dcbw@redhat.com> wrote:
>  > >  > > On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote:
>  > >  > >  > > > This looks wrong. You could restart association when a key is set but
>  > >  > >  > > > really the race is by design in WEXT so the only way to fix it is to set
>  > >  > >  > > > the key first.
>  > >  > >  > > >
>  > >  > >  > >
>  > >  > >  > > Do you mean fix iwconfig to always do set key before set essid?
>  > >  > >  >
>  > >  > >  > Well, no, I think it's more of a user error, I always do
>  > >  > >  >    iwconfig enc ENC; iwconfig essid SSID
>  > >  > >  > in that order.
>  > >  > >  >
>  > >  > >  > > But, doing It cannot solve a race from two seperated iwconfig process, I think.
>  > >  > >  > > (eg: iwconfig essid ESSID; iwconfig enc ENC)
>  > >  > >  >
>  > >  > >  > Yeah, that's pretty ugly to start with.
>  > >  > >
>  > >  > >  See below for a partial solution; but even with nl80211/cfg80211, if you
>  > >  > >  have more than one process trying to control the wireless card
>  > >  > >  concurrently you have already lost.  Don't Do That.
>  > >  > >
>  > >  > >
>  > >  > >  > > Moreover, now we just wake auth request task up and return when setting essid.
>  > >  > >  > > Don't we need to wait a moment until the task is scheduled to be
>  > >  > >  > > polite to iwconifg? :)
>  > >  > >  >
>  > >  > >  > I think the only way to properly handle it is to reset the association
>  > >  > >  > state machine when a key is added. Dan, what's the expected behaviour?
>  > >  > >
>  > >  > >  The best way to implement the WEXT stuff is to have a timeout of about
>  > >  > >  500ms - 700ms or so to batch WEXT stuff together.  Each new WEXT command
>  > >  > >  that comes in before the timeout pushes the timeout back.  When the
>  > >  > >  timeout triggers, all the new commands are executed in the driver in the
>  > >  > >  order the driver expects.  That fixes most issues with chaining WEXT
>  > >  > >  commands and makes all of these Just Work:
>  > >  > >
>  > >  > >  iwconfig wlan0 essid foo key 253325353 open channel 11
>  > >  > >  iwconfig wlan0 key 253325353 open essid foo channel 11
>  > >  > >  iwconfig wlan0 channel 11 key 253325353 open essid foo
>  > >  > >
>  > >  > >  Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits
>  > >  > >  500ms, the timeout triggers, and the driver changes to channel 6 and
>  > >  > >  starts the association process all over with the current settings (keys,
>  > >  > >  BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event
>  > >  > >  on both success and failure.
>  > >  > >
>  > >  > >  If you just do 'iwconfig wlan0 rate 11' then of course the driver
>  > >  > >  doesn't need to trigger reassociation after the WEXT command timeout, it
>  > >  > >  just needs to lock the bitrate.
>  > >  > >
>  > >  > >  The _explicit_ triggers for association/reassociation are setting the
>  > >  > >  BSSID or the SSID.
>  > >  >
>  > >  > Currently there is a quite a mess that both BSSID and SSID triggers
>  > >  > association.
>  > >  > iwconfig essid AP1
>  > >  > iwconfig ap "00:....." - (bssid of myap)
>  > >  > iwconfig essid AP2
>  > >  >
>  > >  > what will be result of this? will it try to associate with AP1:BSSID
>  > >  > but AP2 SSID
>  > >
>  > >  In the current, not-timeout situation, the driver would probably attempt
>  > >  to associate to AP1/any, and be interrupted by the BSSID lock of the
>  > >  second command, and then try to associate to AP1/00:..., then be
>  > >  interrupted by the third command.
>  > >
>  > >  Then, it should fail if there is no BSSID "00:..." with an SSID of
>  > >  "AP2".  The user must clear the BSSID lock by doing 'iwconfig ap any'
>  > >  and then the driver is free to use any BSSID in it's scan list that
>  > >  matches SSID AP2 and security settings currently configured in the
>  > >  driver.
>  > >
>  > >  Remember, WEXT commands are _cumulative_ unless cleared by the user.
>  >
>  > It's mac80211 decision when to start association. I suggest to
>
>  Ultimately, yes the driver controls association, but in WEXT association
>  is triggered by setting the SSID or the BSSID.  Outside of SSID/BSSID,
>  the driver should trigger reassociation when it needs to.  But BSSID and
>  SSID MUST always trigger a new association.
>
>
>  > associate only on SSID command
>  > if someone wants to trigger BSSID association it would call SSID ANY
>  > call explicitly. This will definitely reduce the mess
>  > I'm seeing now.
>
>  No, that's not enough for implementing WEXT.  I don't really see what
>  the problem is here?  Why is it currently a mess (other than that WEXT
>  is a mess)?  It's pretty clear to me; if you ever execute an 'iwconfig'
>  call that is not 'any' or '0', that attribute is locked in the driver
>  until you unlock it.  End of story.
>
>  That's the conformant case; not all drivers implement it that way.

I'm not talking about any driver I'm specific of mac80211

>  If you do:
>
>  iwconfig wlan0 essid "foobar"
>  iwconfig wlan0 bssid 12:34:56:78:90:12
>  iwconfig wlan0 essid "baz"
>
>  and there is no AP of SSID=baz and BSSID=12:34:56:78:90:12, then the
>  association MUST fail because both the SSID and BSSID attributes are
>  locked in the driver.  They MUST be locked in the driver until one or
>  more of them is cleared or changed, at which point another association
>  must occur.

wireless-tools also provide 'commit' command for these cases so you
know when you are done with configuration.
It is mac80211 current choice not to implemented it that way.

Currently either there is some problem in mac80211 auto selection and
different SSID from bss list from what it
was configured. or some service I don't know about is trying also
configure the device to SSID any.
What I see that association frame has different SSID set then what was
configured usually it's first SSID
in BSS list so association is failing.



>  > I'm using Fedora 8 for development and I'm still cannot figure what
>  > services are trying to access wireless
>  > devices but association is always failing because SSID is switched
>  > between authentication and association frames.
>  > It started to work a bit when I've disabled avahi and disabled dhcp on
>  > the device. (dhcp running after association is fine)
>
>  How about:
>
>  /sbin/service NetworkManager stop
>
>  and:
>
>  killall -TERM wpa_supplicant
>
>  If either NM or wpa_supplicant are running, commands from iwconfig will
>  likely fail because there are two things trying to drive the wireless
>  device.  Just don't do that; because during driver development you need
>  to control the environment obviously.
>

Those are not running for sure in my setup.

>  another problem is drivers that do autoassociation; like ipw2200's
>  'associate=x' parameter.  That allows the driver to automatically
>  associate to anything it can find, which causes no end of problems.
>  That's wrong.
>
ipw2200 doesn't run under mac80211.

Tomas

>
>

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Dan Williams]

On Thu, 2008-03-06 at 00:28 +0200, Tomas Winkler wrote:
> On Wed, Mar 5, 2008 at 11:23 PM, Dan Williams <dcbw@redhat.com> wrote:
> >
> > On Wed, 2008-03-05 at 22:50 +0200, Tomas Winkler wrote:
> >  > On Wed, Mar 5, 2008 at 9:19 PM, Dan Williams <dcbw@redhat.com> wrote:
> >  > >
> >  > > On Wed, 2008-03-05 at 20:53 +0200, Tomas Winkler wrote:
> >  > >  > On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams <dcbw@redhat.com> wrote:
> >  > >  > > On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote:
> >  > >  > >  > > > This looks wrong. You could restart association when a key is set but
> >  > >  > >  > > > really the race is by design in WEXT so the only way to fix it is to set
> >  > >  > >  > > > the key first.
> >  > >  > >  > > >
> >  > >  > >  > >
> >  > >  > >  > > Do you mean fix iwconfig to always do set key before set essid?
> >  > >  > >  >
> >  > >  > >  > Well, no, I think it's more of a user error, I always do
> >  > >  > >  >    iwconfig enc ENC; iwconfig essid SSID
> >  > >  > >  > in that order.
> >  > >  > >  >
> >  > >  > >  > > But, doing It cannot solve a race from two seperated iwconfig process, I think.
> >  > >  > >  > > (eg: iwconfig essid ESSID; iwconfig enc ENC)
> >  > >  > >  >
> >  > >  > >  > Yeah, that's pretty ugly to start with.
> >  > >  > >
> >  > >  > >  See below for a partial solution; but even with nl80211/cfg80211, if you
> >  > >  > >  have more than one process trying to control the wireless card
> >  > >  > >  concurrently you have already lost.  Don't Do That.
> >  > >  > >
> >  > >  > >
> >  > >  > >  > > Moreover, now we just wake auth request task up and return when setting essid.
> >  > >  > >  > > Don't we need to wait a moment until the task is scheduled to be
> >  > >  > >  > > polite to iwconifg? :)
> >  > >  > >  >
> >  > >  > >  > I think the only way to properly handle it is to reset the association
> >  > >  > >  > state machine when a key is added. Dan, what's the expected behaviour?
> >  > >  > >
> >  > >  > >  The best way to implement the WEXT stuff is to have a timeout of about
> >  > >  > >  500ms - 700ms or so to batch WEXT stuff together.  Each new WEXT command
> >  > >  > >  that comes in before the timeout pushes the timeout back.  When the
> >  > >  > >  timeout triggers, all the new commands are executed in the driver in the
> >  > >  > >  order the driver expects.  That fixes most issues with chaining WEXT
> >  > >  > >  commands and makes all of these Just Work:
> >  > >  > >
> >  > >  > >  iwconfig wlan0 essid foo key 253325353 open channel 11
> >  > >  > >  iwconfig wlan0 key 253325353 open essid foo channel 11
> >  > >  > >  iwconfig wlan0 channel 11 key 253325353 open essid foo
> >  > >  > >
> >  > >  > >  Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits
> >  > >  > >  500ms, the timeout triggers, and the driver changes to channel 6 and
> >  > >  > >  starts the association process all over with the current settings (keys,
> >  > >  > >  BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event
> >  > >  > >  on both success and failure.
> >  > >  > >
> >  > >  > >  If you just do 'iwconfig wlan0 rate 11' then of course the driver
> >  > >  > >  doesn't need to trigger reassociation after the WEXT command timeout, it
> >  > >  > >  just needs to lock the bitrate.
> >  > >  > >
> >  > >  > >  The _explicit_ triggers for association/reassociation are setting the
> >  > >  > >  BSSID or the SSID.
> >  > >  >
> >  > >  > Currently there is a quite a mess that both BSSID and SSID triggers
> >  > >  > association.
> >  > >  > iwconfig essid AP1
> >  > >  > iwconfig ap "00:....." - (bssid of myap)
> >  > >  > iwconfig essid AP2
> >  > >  >
> >  > >  > what will be result of this? will it try to associate with AP1:BSSID
> >  > >  > but AP2 SSID
> >  > >
> >  > >  In the current, not-timeout situation, the driver would probably attempt
> >  > >  to associate to AP1/any, and be interrupted by the BSSID lock of the
> >  > >  second command, and then try to associate to AP1/00:..., then be
> >  > >  interrupted by the third command.
> >  > >
> >  > >  Then, it should fail if there is no BSSID "00:..." with an SSID of
> >  > >  "AP2".  The user must clear the BSSID lock by doing 'iwconfig ap any'
> >  > >  and then the driver is free to use any BSSID in it's scan list that
> >  > >  matches SSID AP2 and security settings currently configured in the
> >  > >  driver.
> >  > >
> >  > >  Remember, WEXT commands are _cumulative_ unless cleared by the user.
> >  >
> >  > It's mac80211 decision when to start association. I suggest to
> >
> >  Ultimately, yes the driver controls association, but in WEXT association
> >  is triggered by setting the SSID or the BSSID.  Outside of SSID/BSSID,
> >  the driver should trigger reassociation when it needs to.  But BSSID and
> >  SSID MUST always trigger a new association.
> >
> >
> >  > associate only on SSID command
> >  > if someone wants to trigger BSSID association it would call SSID ANY
> >  > call explicitly. This will definitely reduce the mess
> >  > I'm seeing now.
> >
> >  No, that's not enough for implementing WEXT.  I don't really see what
> >  the problem is here?  Why is it currently a mess (other than that WEXT
> >  is a mess)?  It's pretty clear to me; if you ever execute an 'iwconfig'
> >  call that is not 'any' or '0', that attribute is locked in the driver
> >  until you unlock it.  End of story.
> >
> >  That's the conformant case; not all drivers implement it that way.
> 
> I'm not talking about any driver I'm specific of mac80211

I'm stating what all drivers should do, irregardless of whether they are
mac80211 or fullmac or whatever.  What I wrote is the expected behavior
of mac80211 (or any other driver for that matter) in response to WEXT
commands.

> >  If you do:
> >
> >  iwconfig wlan0 essid "foobar"
> >  iwconfig wlan0 bssid 12:34:56:78:90:12
> >  iwconfig wlan0 essid "baz"
> >
> >  and there is no AP of SSID=baz and BSSID=12:34:56:78:90:12, then the
> >  association MUST fail because both the SSID and BSSID attributes are
> >  locked in the driver.  They MUST be locked in the driver until one or
> >  more of them is cleared or changed, at which point another association
> >  must occur.
> 
> wireless-tools also provide 'commit' command for these cases so you
> know when you are done with configuration.
> It is mac80211 current choice not to implemented it that way.
> 
> Currently either there is some problem in mac80211 auto selection and
> different SSID from bss list from what it
> was configured. or some service I don't know about is trying also
> configure the device to SSID any.
> What I see that association frame has different SSID set then what was
> configured usually it's first SSID
> in BSS list so association is failing.

Yeah; that's really odd.  But if neither NetworkManager or
wpa_supplicant are running, then it appears there's a driver/stack
problem if the driver is attempting to associate with an SSID or BSSID
that is not the latest SSID/BSSID the user specified with iwconfig.

> >  > I'm using Fedora 8 for development and I'm still cannot figure what
> >  > services are trying to access wireless
> >  > devices but association is always failing because SSID is switched
> >  > between authentication and association frames.
> >  > It started to work a bit when I've disabled avahi and disabled dhcp on
> >  > the device. (dhcp running after association is fine)
> >
> >  How about:
> >
> >  /sbin/service NetworkManager stop
> >
> >  and:
> >
> >  killall -TERM wpa_supplicant
> >
> >  If either NM or wpa_supplicant are running, commands from iwconfig will
> >  likely fail because there are two things trying to drive the wireless
> >  device.  Just don't do that; because during driver development you need
> >  to control the environment obviously.
> >
> 
> Those are not running for sure in my setup.
> 
> >  another problem is drivers that do autoassociation; like ipw2200's
> >  'associate=x' parameter.  That allows the driver to automatically
> >  associate to anything it can find, which causes no end of problems.
> >  That's wrong.
> >
> ipw2200 doesn't run under mac80211.

Right; but I thought the same behavior was present in mac80211, or at
least it used to be.  People have in the past wanted drivers to
automatically associate to any open network that the driver can find;
that's wrong and must stop :)  I picked ipw2200 because it's the worst
offender here.  At least it should have associate=0 by default.

We need to ensure that mac80211 doesn't autoassociate because it's first
a security issue and second just plain wrong.

Dan

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Dan Williams]

On Wed, 2008-03-05 at 18:40 +0900, Joonwoo Park wrote:
> resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
> 
> The function ieee80211_ioctl_siwencode shouldn't be called if
> authentication process is not completed.
> This patch makes the ieee80211_ioctl_siwessid to wait for authentication
> is completed.
> 
> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
> ---
>  net/mac80211/ieee80211_ioctl.c |   10 +++++++++-
>  1 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
> index 5024d37..55a29f6 100644
> --- a/net/mac80211/ieee80211_ioctl.c
> +++ b/net/mac80211/ieee80211_ioctl.c
> @@ -391,6 +391,7 @@ static int ieee80211_ioctl_siwessid(struct net_device *dev,
>  	if (sdata->vif.type == IEEE80211_IF_TYPE_STA ||
>  	    sdata->vif.type == IEEE80211_IF_TYPE_IBSS) {
>  		int ret;
> +		DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
>  		if (sdata->flags & IEEE80211_SDATA_USERSPACE_MLME) {
>  			if (len > IEEE80211_MAX_SSID_LEN)
>  				return -EINVAL;
> @@ -405,8 +406,15 @@ static int ieee80211_ioctl_siwessid(struct net_device *dev,
>  		ret = ieee80211_sta_set_ssid(dev, ssid, len);
>  		if (ret)
>  			return ret;
> +
> +		set_bit(IEEE80211_STA_REQ_RUN, &sdata->u.sta.request);
> +
>  		ieee80211_sta_req_auth(dev, &sdata->u.sta);
> -		return 0;
> +
> +		ret = wait_event_interruptible_timeout(wq,
> +			!test_bit(IEEE80211_STA_REQ_RUN, &sdata->u.sta.request),
> +				HZ);
> +		return (ret == HZ) ? 0 : ret;

NAK; setting the SSID should never block for long; it _certainly_
shouldn't block waiting on other WEXT calls.  The association process
needs to be asynchronous.

Dan

>  	}
>  
>  	if (sdata->vif.type == IEEE80211_IF_TYPE_AP) {

Re: [PATCH] mac80211: fix races between siwessid and siwencode

[Michael Buesch]

On Wednesday 05 March 2008 19:22:31 Dan Williams wrote:
> On Wed, 2008-03-05 at 18:40 +0900, Joonwoo Park wrote:
> > resolve: http://bughost.org/bugzilla/show_bug.cgi?id=1522
> > 
> > The function ieee80211_ioctl_siwencode shouldn't be called if
> > authentication process is not completed.
> > This patch makes the ieee80211_ioctl_siwessid to wait for authentication
> > is completed.
> > 
> > Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
> > ---
> >  net/mac80211/ieee80211_ioctl.c |   10 +++++++++-
> >  1 files changed, 9 insertions(+), 1 deletions(-)
> > 
> > diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
> > index 5024d37..55a29f6 100644
> > --- a/net/mac80211/ieee80211_ioctl.c
> > +++ b/net/mac80211/ieee80211_ioctl.c
> > @@ -391,6 +391,7 @@ static int ieee80211_ioctl_siwessid(struct net_device *dev,
> >  	if (sdata->vif.type == IEEE80211_IF_TYPE_STA ||
> >  	    sdata->vif.type == IEEE80211_IF_TYPE_IBSS) {
> >  		int ret;
> > +		DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> >  		if (sdata->flags & IEEE80211_SDATA_USERSPACE_MLME) {
> >  			if (len > IEEE80211_MAX_SSID_LEN)
> >  				return -EINVAL;
> > @@ -405,8 +406,15 @@ static int ieee80211_ioctl_siwessid(struct net_device *dev,
> >  		ret = ieee80211_sta_set_ssid(dev, ssid, len);
> >  		if (ret)
> >  			return ret;
> > +
> > +		set_bit(IEEE80211_STA_REQ_RUN, &sdata->u.sta.request);
> > +
> >  		ieee80211_sta_req_auth(dev, &sdata->u.sta);
> > -		return 0;
> > +
> > +		ret = wait_event_interruptible_timeout(wq,
> > +			!test_bit(IEEE80211_STA_REQ_RUN, &sdata->u.sta.request),
> > +				HZ);
> > +		return (ret == HZ) ? 0 : ret;
> 
> NAK; setting the SSID should never block for long; it _certainly_
> shouldn't block waiting on other WEXT calls.  The association process
> needs to be asynchronous.

Doesn't this also cause a RTNL-lock deadlock?

-- 
Greetings Michael.