Problems with "cfg80211: fix SME connect" commit

Problems with "cfg80211: fix SME connect" commit

[Albert Herranz]

Hello,

Patch "cfg80211: fix SME connect" breaks my setup (WPA2/AES-CCMP between my b43 card and my AP).

When the patch is applied, the usual kernel messages "direct probe" and "authenticate" never happen, and IP address adquisition via dhcp fails:

[   12.709769] b43-phy0 debug: Chip initialized
[   12.725621] b43-phy0 debug: PIO initialized
[   12.733015] b43-phy0 debug: QoS disabled
[   12.913516] b43-phy0 debug: Wireless interface started
[   13.021170] b43-phy0 debug: Adding Interface type 2

When the patch is reverted everything works again:

[   13.222940] b43-phy0 debug: Chip initialized
[   13.291359] b43-phy0 debug: PIO initialized
[   13.330116] b43-phy0 debug: QoS disabled
[   13.861636] b43-phy0 debug: Wireless interface started
[   13.969153] b43-phy0 debug: Adding Interface type 2
[   16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
[   16.700998] wlan1 direct probe responded
[   16.707013] wlan1: authenticate with AP 00:12:17:15:e7:79 (try 1)
[   16.720205] wlan1: authenticated
[   16.726261] wlan1: associate with AP 00:12:17:15:e7:79 (try 1)
[   16.740697] wlan1: RX AssocResp from 00:12:17:15:e7:79 (capab=0x431 status=0 aid=1)
[   16.758042] wlan1: associated

Any clues?

Thanks,
Albert



      

Re: Problems with "cfg80211: fix SME connect" commit

[Holger Schurig]

Can you try "[PATCH] cfg80211: don't overwrite privacy setting" 
from [1]?

[1] http://marc.info/?l=linux-wireless&m=125323296617306&w=2


And can you use the mailing list archives?  This is now the third 
time this poppep up, I just copied Sedat's mail for you.

-- 
http://www.holgerschurig.de

Re: Problems with "cfg80211: fix SME connect" commit

[Albert Herranz]

Holger Schurig wrote:
> Can you try "[PATCH] cfg80211: don't overwrite privacy setting" 
> from [1]?
> 
> [1] http://marc.info/?l=linux-wireless&m=125323296617306&w=2
> 
> 
> And can you use the mailing list archives?  This is now the third 
> time this poppep up, I just copied Sedat's mail for you.
> 

Hi,

Thanks for the information.

Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't overwrite privacy setting" fixes the connection issue, but with a introduces a small difference vs the previous working version.
There is now an extra "deauthenticating by local choice (reason=3)" message in the logs.

* master-20090914

[   13.222940] b43-phy0 debug: Chip initialized
[   13.291359] b43-phy0 debug: PIO initialized
[   13.330116] b43-phy0 debug: QoS disabled
[   13.861636] b43-phy0 debug: Wireless interface started
[   13.969153] b43-phy0 debug: Adding Interface type 2
[   16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
[   16.700998] wlan1 direct probe responded
[   16.707013] wlan1: authenticate with AP 00:12:17:15:e7:79 (try 1)
[   16.720205] wlan1: authenticated
[   16.726261] wlan1: associate with AP 00:12:17:15:e7:79 (try 1)
[   16.740697] wlan1: RX AssocResp from 00:12:17:15:e7:79 (capab=0x431 status=0 aid=1)
[   16.758042] wlan1: associated

* master-20090916 + "cfg80211: don't overwrite privacy setting"

[   12.849778] b43-phy0 debug: Chip initialized
[   12.865561] b43-phy0 debug: PIO initialized
[   12.872482] b43-phy0 debug: QoS disabled
[   13.053373] b43-phy0 debug: Wireless interface started
[   13.218613] b43-phy0 debug: Adding Interface type 2
[   15.832582] wlan1: deauthenticating by local choice (reason=3)
[   16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
[   16.145589] wlan1 direct probe responded
[   16.154501] wlan1: authenticate with AP 00:12:17:15:e7:79 (try 1)
[   16.175640] wlan1: authenticated
[   16.181829] wlan1: associate with AP 00:12:17:15:e7:79 (try 1)
[   16.198990] wlan1: RX AssocResp from 00:12:17:15:e7:79 (capab=0x431 status=0 aid=1)
[   16.210791] wlan1: associated

Any comments on this?

Thanks,
Albert

Re: Problems with "cfg80211: fix SME connect" commit

[Johannes Berg]

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

On Mon, 2009-09-21 at 18:11 +0200, Albert Herranz wrote:

> Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't
> overwrite privacy setting" fixes the connection issue, but with a
> introduces a small difference vs the previous working version.
> There is now an extra "deauthenticating by local choice (reason=3)"
> message in the logs.

> [   13.969153] b43-phy0 debug: Adding Interface type 2
> [   16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)

> * master-20090916 + "cfg80211: don't overwrite privacy setting"

> [   13.218613] b43-phy0 debug: Adding Interface type 2
> [   15.832582] wlan1: deauthenticating by local choice (reason=3)
> [   16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)

Very odd. Can you edit the deauthenticating message to show the
BSSID/MAC address?

johannes

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

Re: Problems with "cfg80211: fix SME connect" commit

[Hin-Tak Leung]

On Thu, Sep 24, 2009 at 9:05 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2009-09-21 at 18:11 +0200, Albert Herranz wrote:
>
>> Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't
>> overwrite privacy setting" fixes the connection issue, but with a
>> introduces a small difference vs the previous working version.
>> There is now an extra "deauthenticating by local choice (reason=3)"
>> message in the logs.
>
>> [   13.969153] b43-phy0 debug: Adding Interface type 2
>> [   16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
>
>> * master-20090916 + "cfg80211: don't overwrite privacy setting"
>
>> [   13.218613] b43-phy0 debug: Adding Interface type 2
>> [   15.832582] wlan1: deauthenticating by local choice (reason=3)
>> [   16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
>
> Very odd. Can you edit the deauthenticating message to show the
> BSSID/MAC address?
>
> johannes
>

This seems to look like/relate to a little problem I have for the last
few days - lately I have authentication failure on first try and have
to click on NM a 2nd time for it to go through; blow away
compat-wireless & revert to as-shipped distro modules gives me the
older/smooth behavior  of NM just associating without me
clicking/asking.

v2.6.31-38294-ged3ac87 + 'cfg80211: don't set privacy w/o key' doesn't
improve my situation.

wpa_supplicant log:
--------- distro modules:
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Associated with <id>
CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

-------- compat-wireless
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Associated with <id>
CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]

------ dmesg distro modules
wlan2: direct probe to AP <id> try 1
wlan2 direct probe responded
wlan2: authenticate with AP <id>
wlan2: authenticated
wlan2: associate with AP <id>
wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
wlan2: associated

------ compat-wireless, note the extra deauth at the beginning, and
all those 'try 1''s.
wlan2: deauthenticating by local choice (reason=3)
wlan2: direct probe to AP <id> (try 1)
wlan2 direct probe responded
wlan2: authenticate with AP <id> (try 1)
wlan2: authenticated
wlan2: associate with AP <id> (try 1)
wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
wlan2: associated

my wpa_supplicant config has two configurations, one (the usual) wep,
and a catch-all generic open network, if that matters.

Most of the instances in wpa log are extra authentication timeouts
with 00:00:00:00:00:00 , but occasionally it is my AP's address.

Re: Problems with "cfg80211: fix SME connect" commit

[Johannes Berg]

Thanks for your analysis.

> This seems to look like/relate to a little problem I have for the last
> few days - lately I have authentication failure on first try and have
> to click on NM a 2nd time for it to go through; blow away
> compat-wireless & revert to as-shipped distro modules gives me the
> older/smooth behavior  of NM just associating without me
> clicking/asking.
> 
> v2.6.31-38294-ged3ac87 + 'cfg80211: don't set privacy w/o key' doesn't
> improve my situation.
> 
> wpa_supplicant log:
> --------- distro modules:
> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
> Associated with <id>
> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> 
> -------- compat-wireless
> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
> Authentication with 00:00:00:00:00:00 timed out.
> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
> Associated with <id>
> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
> 
> ------ dmesg distro modules
> wlan2: direct probe to AP <id> try 1
> wlan2 direct probe responded
> wlan2: authenticate with AP <id>
> wlan2: authenticated
> wlan2: associate with AP <id>
> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
> wlan2: associated
> 
> ------ compat-wireless, note the extra deauth at the beginning, and
> all those 'try 1''s.
> wlan2: deauthenticating by local choice (reason=3)
> wlan2: direct probe to AP <id> (try 1)
> wlan2 direct probe responded
> wlan2: authenticate with AP <id> (try 1)
> wlan2: authenticated
> wlan2: associate with AP <id> (try 1)
> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
> wlan2: associated

I've analysed this, and now know the reason for the extra deauth, but it
shouldn't hurt since we never send a wireless extensions event. The
reason is that once wpa_supplicant sets the SSID we already start to
connect with the new changes, but then setting the BSSID might require
restarting the process. This could be optimised, but I would prefer not
having to.

I can see a problem with the code and it trying to scan once more again
etc. Below patch seems to help for me. However, I only once managed to
reproduce the problem you were seeing with the authentication timeout in
wpa_supplicant.

Can you try this? The last hunk is most important, but the other stuff
helps debugging.

johannes

--- wireless-testing.orig/net/mac80211/mlme.c	2009-09-25 07:38:46.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c	2009-09-25 08:12:26.000000000 +0200
@@ -1675,7 +1675,7 @@ static void ieee80211_rx_mgmt_probe_resp
 
 	/* direct probe may be part of the association flow */
 	if (wk && wk->state == IEEE80211_MGD_STATE_PROBE) {
-		printk(KERN_DEBUG "%s direct probe responded\n",
+		printk(KERN_DEBUG "%s: direct probe responded\n",
 		       sdata->dev->name);
 		wk->tries = 0;
 		wk->state = IEEE80211_MGD_STATE_AUTH;
@@ -2411,6 +2411,9 @@ int ieee80211_mgd_auth(struct ieee80211_
 	list_add(&wk->list, &sdata->u.mgd.work_list);
 	mutex_unlock(&ifmgd->mtx);
 
+	printk(KERN_DEBUG "%s: starting authentication with %pM\n",
+	       sdata->dev->name, req->bss->bssid);
+
 	ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.work);
 	return 0;
 }
@@ -2485,6 +2488,9 @@ int ieee80211_mgd_assoc(struct ieee80211
 	else
 		ifmgd->flags &= ~IEEE80211_STA_CONTROL_PORT;
 
+	printk(KERN_DEBUG "%s: starting association with %pM\n",
+	       sdata->dev->name, req->bss->bssid);
+
 	ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.work);
 
 	err = 0;
@@ -2502,9 +2508,6 @@ int ieee80211_mgd_deauth(struct ieee8021
 	struct ieee80211_mgd_work *wk;
 	const u8 *bssid = NULL;
 
-	printk(KERN_DEBUG "%s: deauthenticating by local choice (reason=%d)\n",
-	       sdata->dev->name, req->reason_code);
-
 	mutex_lock(&ifmgd->mtx);
 
 	if (ifmgd->associated && &ifmgd->associated->cbss == req->bss) {
@@ -2532,6 +2535,9 @@ int ieee80211_mgd_deauth(struct ieee8021
 
 	mutex_unlock(&ifmgd->mtx);
 
+	printk(KERN_DEBUG "%s: deauthenticating from %pM by local choice (reason=%d)\n",
+	       sdata->dev->name, bssid, req->reason_code);
+
 	ieee80211_send_deauth_disassoc(sdata, bssid,
 			IEEE80211_STYPE_DEAUTH, req->reason_code,
 			cookie);
@@ -2545,9 +2551,6 @@ int ieee80211_mgd_disassoc(struct ieee80
 {
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 
-	printk(KERN_DEBUG "%s: disassociating by local choice (reason=%d)\n",
-	       sdata->dev->name, req->reason_code);
-
 	mutex_lock(&ifmgd->mtx);
 
 	/*
@@ -2561,6 +2564,9 @@ int ieee80211_mgd_disassoc(struct ieee80
 		return -ENOLINK;
 	}
 
+	printk(KERN_DEBUG "%s: disassociating from %pM by local choice (reason=%d)\n",
+	       sdata->dev->name, req->bss->bssid, req->reason_code);
+
 	ieee80211_set_disassoc(sdata, false);
 
 	mutex_unlock(&ifmgd->mtx);
--- wireless-testing.orig/net/wireless/sme.c	2009-09-25 08:05:20.000000000 +0200
+++ wireless-testing/net/wireless/sme.c	2009-09-25 08:13:42.000000000 +0200
@@ -762,9 +762,8 @@ int __cfg80211_connect(struct cfg80211_r
 		wdev->conn->params.ssid = wdev->ssid;
 		wdev->conn->params.ssid_len = connect->ssid_len;
 
-		/* don't care about result -- but fill bssid & channel */
-		if (!wdev->conn->params.bssid || !wdev->conn->params.channel)
-			bss = cfg80211_get_conn_bss(wdev);
+		/* see if we have the bss already */
+		bss = cfg80211_get_conn_bss(wdev);
 
 		wdev->sme_state = CFG80211_SME_CONNECTING;
 		wdev->connect_keys = connkeys;

Re: Problems with "cfg80211: fix SME connect" commit

[Hin-Tak Leung]

On Fri, Sep 25, 2009 at 7:22 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Thanks for your analysis.
>
>> This seems to look like/relate to a little problem I have for the last
>> few days - lately I have authentication failure on first try and have
>> to click on NM a 2nd time for it to go through; blow away
>> compat-wireless & revert to as-shipped distro modules gives me the
>> older/smooth behavior  of NM just associating without me
>> clicking/asking.
>>
>> v2.6.31-38294-ged3ac87 + 'cfg80211: don't set privacy w/o key' doesn't
>> improve my situation.
>>
>> wpa_supplicant log:
>> --------- distro modules:
>> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
>> Associated with <id>
>> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>>
>> -------- compat-wireless
>> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
>> Authentication with 00:00:00:00:00:00 timed out.
>> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
>> Associated with <id>
>> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
>>
>> ------ dmesg distro modules
>> wlan2: direct probe to AP <id> try 1
>> wlan2 direct probe responded
>> wlan2: authenticate with AP <id>
>> wlan2: authenticated
>> wlan2: associate with AP <id>
>> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
>> wlan2: associated
>>
>> ------ compat-wireless, note the extra deauth at the beginning, and
>> all those 'try 1''s.
>> wlan2: deauthenticating by local choice (reason=3)
>> wlan2: direct probe to AP <id> (try 1)
>> wlan2 direct probe responded
>> wlan2: authenticate with AP <id> (try 1)
>> wlan2: authenticated
>> wlan2: associate with AP <id> (try 1)
>> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
>> wlan2: associated
>
> I've analysed this, and now know the reason for the extra deauth, but it
> shouldn't hurt since we never send a wireless extensions event. The
> reason is that once wpa_supplicant sets the SSID we already start to
> connect with the new changes, but then setting the BSSID might require
> restarting the process. This could be optimised, but I would prefer not
> having to.
>
> I can see a problem with the code and it trying to scan once more again
> etc. Below patch seems to help for me. However, I only once managed to
> reproduce the problem you were seeing with the authentication timeout in
> wpa_supplicant.
>
> Can you try this? The last hunk is most important, but the other stuff
> helps debugging.

Great. The extra timeout in wap_spplicant.log is gone, so it is back
to NM does it all by itself.

Here is the dmesg from this patch on top of everything else so far:

wlan2: starting authentication with _id_
wlan2: deauthenticating from _id_ by local choice (reason=3)
wlan2: starting authentication with _id_
wlan2: direct probe to AP _id_ (try 1)
wlan2: direct probe responded
wlan2: authenticate with AP _id_ (try 1)
wlan2: authenticated
wlan2: starting association with _id_
wlan2: associate with AP _id_ (try 1)
wlan2: RX AssocResp from _id_ (capab=0x431 status=0 aid=1)
wlan2: associated

There is still the extra deauth at the beginning, but I guess I can
live with it, it doesn't require user action to deal with (unlike
without this latest patch) I suppose there might be more tuning before
commit?  Otherwise Tested-by:

Hmm, slightly side-tracked - was the original poster using NM on top
on wpa_supplicant, just curious?

Cheers,
Hin-Tak

Re: Problems with "cfg80211: fix SME connect" commit

[Johannes Berg]

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

On Fri, 2009-09-25 at 16:54 +0100, Hin-Tak Leung wrote:

> > Can you try this? The last hunk is most important, but the other stuff
> > helps debugging.
> 
> Great. The extra timeout in wap_spplicant.log is gone, so it is back
> to NM does it all by itself.

Interesting, thanks for the test. I'll go submit the patch.

> Here is the dmesg from this patch on top of everything else so far:
> 
> wlan2: starting authentication with _id_
> wlan2: deauthenticating from _id_ by local choice (reason=3)
> wlan2: starting authentication with _id_
> wlan2: direct probe to AP _id_ (try 1)
> wlan2: direct probe responded
> wlan2: authenticate with AP _id_ (try 1)
> wlan2: authenticated
> wlan2: starting association with _id_
> wlan2: associate with AP _id_ (try 1)
> wlan2: RX AssocResp from _id_ (capab=0x431 status=0 aid=1)
> wlan2: associated
> 
> There is still the extra deauth at the beginning, but I guess I can
> live with it, it doesn't require user action to deal with (unlike
> without this latest patch) I suppose there might be more tuning before
> commit? 

I think I'll just remove some of the printks again, but leave the ones
moving. Actually probably better to split it up into a mac80211 and a
cfg80211 patch.

The extra deauth is because cfg80211 already starts the auth with the
BSS before wpa_supplicant set the BSSID, and then when setting the BSSID
it asks for deauth, but before we ever actually did anything... I think
we'll just have to live with that, since it's hard to fix in the layered
design we have now.

>  Otherwise Tested-by:
> 
> Hmm, slightly side-tracked - was the original poster using NM on top
> on wpa_supplicant, just curious?

You mean Albert? I don't know.

johannes

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

Re: Problems with "cfg80211: fix SME connect" commit

[Hin-Tak Leung]

On Sat, Sep 26, 2009 at 12:39 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2009-09-25 at 16:54 +0100, Hin-Tak Leung wrote:
>
>> > Can you try this? The last hunk is most important, but the other stuff
>> > helps debugging.
>>
>> Great. The extra timeout in wap_spplicant.log is gone, so it is back
>> to NM does it all by itself.
>
> Interesting, thanks for the test. I'll go submit the patch.
>
>> Here is the dmesg from this patch on top of everything else so far:
>>
>> wlan2: starting authentication with _id_
>> wlan2: deauthenticating from _id_ by local choice (reason=3)
>> wlan2: starting authentication with _id_
>> wlan2: direct probe to AP _id_ (try 1)
>> wlan2: direct probe responded
>> wlan2: authenticate with AP _id_ (try 1)
>> wlan2: authenticated
>> wlan2: starting association with _id_
>> wlan2: associate with AP _id_ (try 1)
>> wlan2: RX AssocResp from _id_ (capab=0x431 status=0 aid=1)
>> wlan2: associated
>>
>> There is still the extra deauth at the beginning, but I guess I can
>> live with it, it doesn't require user action to deal with (unlike
>> without this latest patch) I suppose there might be more tuning before
>> commit?
>
> I think I'll just remove some of the printks again, but leave the ones
> moving. Actually probably better to split it up into a mac80211 and a
> cfg80211 patch.
>
> The extra deauth is because cfg80211 already starts the auth with the
> BSS before wpa_supplicant set the BSSID, and then when setting the BSSID
> it asks for deauth, but before we ever actually did anything... I think
> we'll just have to live with that, since it's hard to fix in the layered
> design we have now.

I suppose (together with some of the newly added printk you mentioned
could be removed in the final version) the dmesg messages are somewhat
confusing, because as a user, I would rather have a deauth message
that's actually associated with a user action (e.g. if I switch AP or
rfkill). Is it possible to distinguish situation where a user action
is involved versus one that isn't? or is the distinction between any
consequence of 'user-action' vs wpa_supplicant doing-it-on-its-own too
much buried down in the layers?

>>  Otherwise Tested-by:
>>
>> Hmm, slightly side-tracked - was the original poster using NM on top
>> on wpa_supplicant, just curious?
>
> You mean Albert? I don't know.

Yes - I meant Albert - wpa_spplicant runs directly probably behaves a
little differently from NM starting/stopping it.

>
> johannes
>

Re: Problems with "cfg80211: fix SME connect" commit

[Johannes Berg]

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

On Sun, 2009-09-27 at 00:57 +0100, Hin-Tak Leung wrote:

> I suppose (together with some of the newly added printk you mentioned
> could be removed in the final version) the dmesg messages are somewhat
> confusing, because as a user, I would rather have a deauth message
> that's actually associated with a user action (e.g. if I switch AP or
> rfkill). Is it possible to distinguish situation where a user action
> is involved versus one that isn't? or is the distinction between any
> consequence of 'user-action' vs wpa_supplicant doing-it-on-its-own too
> much buried down in the layers?

Yeah, it'd be nice to avoid that completely. Or even just avoid telling
the driver, maybe with some delay akin iwcommit. Alas, I haven't looked
at it yet and right now it seems to just be a message (and possibly a
deauth frame)

johannes

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

Re: Problems with "cfg80211: fix SME connect" commit

[Albert Herranz]

Johannes Berg wrote:
> On Mon, 2009-09-21 at 18:11 +0200, Albert Herranz wrote:
> 
>> Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't
>> overwrite privacy setting" fixes the connection issue, but with a
>> introduces a small difference vs the previous working version.
>> There is now an extra "deauthenticating by local choice (reason=3)"
>> message in the logs.
> 
>> [   13.969153] b43-phy0 debug: Adding Interface type 2
>> [   16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
> 
>> * master-20090916 + "cfg80211: don't overwrite privacy setting"
> 
>> [   13.218613] b43-phy0 debug: Adding Interface type 2
>> [   15.832582] wlan1: deauthenticating by local choice (reason=3)
>> [   16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
> 
> Very odd. Can you edit the deauthenticating message to show the
> BSSID/MAC address?
> 
> johannes

Hi,

Sorry if this comes too late (I was on vacation).

Here's the output showing the BSSID/MAC address for completeness.

[    1.307985] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[    1.344244] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[    1.372627] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
[    1.377416] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
[    1.417302] phy0: Selected rate control algorithm 'minstrel'
[    4.462416] udev: renamed network interface wlan0 to wlan1
[   11.064949] b43 ssb0:0: firmware: requesting b43/ucode5.fw
[   11.118177] b43 ssb0:0: firmware: requesting b43-open/ucode5.fw
[   11.197385] b43 ssb0:0: firmware: requesting b43-open/pcm5.fw
[   11.268949] b43 ssb0:0: firmware: requesting b43-open/b0g0initvals5.fw
[   11.347623] b43 ssb0:0: firmware: requesting b43-open/b0g0bsinitvals5.fw
[   12.353406] b43-phy0: Loading OpenSource firmware version 410.31754
[   12.359142] b43-phy0: Hardware crypto acceleration not supported by firmware
[   12.369827] b43-phy0: QoS not supported by firmware
[   12.741767] b43-phy0 debug: Chip initialized
[   12.757540] b43-phy0 debug: PIO initialized
[   12.764455] b43-phy0 debug: QoS disabled
[   12.945116] b43-phy0 debug: Wireless interface started
[   13.053151] b43-phy0 debug: Adding Interface type 2
[   15.624121] wlan1: starting authentication with 00:12:17:15:e7:79
[   15.630717] wlan1: deauthenticating from 00:12:17:15:e7:79 by local choice (reason=3)
[   15.645151] wlan1: starting authentication with 00:12:17:15:e7:79
[   15.665811] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
[   15.681132] wlan1: direct probe responded
[   15.687261] wlan1: authenticate with AP 00:12:17:15:e7:79 (try 1)
[   15.701105] wlan1: authenticated
[   15.707860] wlan1: starting association with 00:12:17:15:e7:79
[   15.713877] wlan1: associate with AP 00:12:17:15:e7:79 (try 1)
[   15.726949] wlan1: RX AssocResp from 00:12:17:15:e7:79 (capab=0x431 status=0 aid=1)
[   15.740953] wlan1: associated

I'm using wpa_supplicant _without_ NM.

Cheers,
Albert


      

Re: Problems with "cfg80211: fix SME connect" commit

[Johannes Berg]

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

On Mon, 2009-09-28 at 11:04 -0700, Albert Herranz wrote:

> [   15.624121] wlan1: starting authentication with 00:12:17:15:e7:79
> [   15.630717] wlan1: deauthenticating from 00:12:17:15:e7:79 by local choice (reason=3)
> [   15.645151] wlan1: starting authentication with 00:12:17:15:e7:79

> I'm using wpa_supplicant _without_ NM.

Yeah, I since figured out why that's happening, and it's not so strange
after all. Shouldn't be a big deal. At least I see you're getting
connected too now.

johannes

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

Re: Problems with "cfg80211: fix SME connect" commit

[Hin-Tak Leung]

On Mon, Sep 28, 2009 at 7:55 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2009-09-28 at 11:04 -0700, Albert Herranz wrote:
>
>> [   15.624121] wlan1: starting authentication with 00:12:17:15:e7:79
>> [   15.630717] wlan1: deauthenticating from 00:12:17:15:e7:79 by local choice (reason=3)
>> [   15.645151] wlan1: starting authentication with 00:12:17:15:e7:79
>
>> I'm using wpa_supplicant _without_ NM.
>
> Yeah, I since figured out why that's happening, and it's not so strange
> after all. Shouldn't be a big deal. At least I see you're getting
> connected too now.
>
> johannes
>

Yes, it looks like it is similar/same as my situation - the difference
being that I had wpa_supplicant talking to NM via D-bus and get the
extra user-prompt (not anymore with the latest patches) when the first
try from wpa_supplicant fails. When wpa_supplicant is run without -u
(the d-bus/NM option) it probably tries a bit harder on its own?

Hin-Tak

Re: Problems with "cfg80211: fix SME connect" commit

[Hin-Tak Leung]

On Sat, Sep 26, 2009 at 12:39 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:

> The extra deauth is because cfg80211 already starts the auth with the
> BSS before wpa_supplicant set the BSSID, and then when setting the BSSID
> it asks for deauth, but before we ever actually did anything... I think
> we'll just have to live with that, since it's hard to fix in the layered
> design we have now.

Hmm, I looked at the AP log, and the deauth is there... also I think
due to recent changes, association takes longer now. Is there
something that can be done in userland, for example?

Hin-Tak

Re: Problems with "cfg80211: fix SME connect" commit

[Johannes Berg]

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

On Wed, 2009-09-30 at 22:17 +0100, Hin-Tak Leung wrote:
> On Sat, Sep 26, 2009 at 12:39 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> 
> > The extra deauth is because cfg80211 already starts the auth with the
> > BSS before wpa_supplicant set the BSSID, and then when setting the BSSID
> > it asks for deauth, but before we ever actually did anything... I think
> > we'll just have to live with that, since it's hard to fix in the layered
> > design we have now.
> 
> Hmm, I looked at the AP log, and the deauth is there...

Yeah. I've thought of doing a fix in mac80211, but haven't gotten around
to it yet -- should be fairly easy tho.

>  also I think
> due to recent changes, association takes longer now. Is there
> something that can be done in userland, for example?

You can use -Dnl80211 with wpa_supplicant, but other than that we may or
may not scan a few times more or less, which is somewhat unfortunate.
Though it shouldn't be taking longer due to these specific recent
changes, in fact this should make it faster, if anything, I think.

johannes

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