* Problems with "cfg80211: fix SME connect" commit
@ 2009-09-20 18:03 Albert Herranz
2009-09-21 6:45 ` Holger Schurig
0 siblings, 1 reply; 15+ messages in thread
From: Albert Herranz @ 2009-09-20 18:03 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-20 18:03 Problems with "cfg80211: fix SME connect" commit Albert Herranz @ 2009-09-21 6:45 ` Holger Schurig 2009-09-21 16:11 ` Albert Herranz 0 siblings, 1 reply; 15+ messages in thread From: Holger Schurig @ 2009-09-21 6:45 UTC (permalink / raw) To: Albert Herranz; +Cc: johannes, linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-21 6:45 ` Holger Schurig @ 2009-09-21 16:11 ` Albert Herranz 2009-09-24 8:05 ` Johannes Berg 0 siblings, 1 reply; 15+ messages in thread From: Albert Herranz @ 2009-09-21 16:11 UTC (permalink / raw) To: Holger Schurig; +Cc: johannes, linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-21 16:11 ` Albert Herranz @ 2009-09-24 8:05 ` Johannes Berg 2009-09-24 19:13 ` Hin-Tak Leung 2009-09-28 18:04 ` Albert Herranz 0 siblings, 2 replies; 15+ messages in thread From: Johannes Berg @ 2009-09-24 8:05 UTC (permalink / raw) To: Albert Herranz; +Cc: Holger Schurig, linville, linux-wireless [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-24 8:05 ` Johannes Berg @ 2009-09-24 19:13 ` Hin-Tak Leung 2009-09-25 6:22 ` Johannes Berg 2009-09-28 18:04 ` Albert Herranz 1 sibling, 1 reply; 15+ messages in thread From: Hin-Tak Leung @ 2009-09-24 19:13 UTC (permalink / raw) To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-24 19:13 ` Hin-Tak Leung @ 2009-09-25 6:22 ` Johannes Berg 2009-09-25 15:54 ` Hin-Tak Leung 0 siblings, 1 reply; 15+ messages in thread From: Johannes Berg @ 2009-09-25 6:22 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless 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; ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-25 6:22 ` Johannes Berg @ 2009-09-25 15:54 ` Hin-Tak Leung 2009-09-26 11:39 ` Johannes Berg 0 siblings, 1 reply; 15+ messages in thread From: Hin-Tak Leung @ 2009-09-25 15:54 UTC (permalink / raw) To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-25 15:54 ` Hin-Tak Leung @ 2009-09-26 11:39 ` Johannes Berg 2009-09-26 23:57 ` Hin-Tak Leung 2009-09-30 21:17 ` Hin-Tak Leung 0 siblings, 2 replies; 15+ messages in thread From: Johannes Berg @ 2009-09-26 11:39 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-26 11:39 ` Johannes Berg @ 2009-09-26 23:57 ` Hin-Tak Leung 2009-09-28 14:41 ` Johannes Berg 2009-09-30 21:17 ` Hin-Tak Leung 1 sibling, 1 reply; 15+ messages in thread From: Hin-Tak Leung @ 2009-09-26 23:57 UTC (permalink / raw) To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-26 23:57 ` Hin-Tak Leung @ 2009-09-28 14:41 ` Johannes Berg 0 siblings, 0 replies; 15+ messages in thread From: Johannes Berg @ 2009-09-28 14:41 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-26 11:39 ` Johannes Berg 2009-09-26 23:57 ` Hin-Tak Leung @ 2009-09-30 21:17 ` Hin-Tak Leung 2009-09-30 21:20 ` Johannes Berg 1 sibling, 1 reply; 15+ messages in thread From: Hin-Tak Leung @ 2009-09-30 21:17 UTC (permalink / raw) To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-30 21:17 ` Hin-Tak Leung @ 2009-09-30 21:20 ` Johannes Berg 0 siblings, 0 replies; 15+ messages in thread From: Johannes Berg @ 2009-09-30 21:20 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-24 8:05 ` Johannes Berg 2009-09-24 19:13 ` Hin-Tak Leung @ 2009-09-28 18:04 ` Albert Herranz 2009-09-28 18:55 ` Johannes Berg 1 sibling, 1 reply; 15+ messages in thread From: Albert Herranz @ 2009-09-28 18:04 UTC (permalink / raw) To: Johannes Berg; +Cc: Holger Schurig, linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-28 18:04 ` Albert Herranz @ 2009-09-28 18:55 ` Johannes Berg 2009-09-28 19:22 ` Hin-Tak Leung 0 siblings, 1 reply; 15+ messages in thread From: Johannes Berg @ 2009-09-28 18:55 UTC (permalink / raw) To: Albert Herranz; +Cc: Holger Schurig, linville, linux-wireless [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with "cfg80211: fix SME connect" commit 2009-09-28 18:55 ` Johannes Berg @ 2009-09-28 19:22 ` Hin-Tak Leung 0 siblings, 0 replies; 15+ messages in thread From: Hin-Tak Leung @ 2009-09-28 19:22 UTC (permalink / raw) To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-09-30 21:20 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-20 18:03 Problems with "cfg80211: fix SME connect" commit Albert Herranz 2009-09-21 6:45 ` Holger Schurig 2009-09-21 16:11 ` Albert Herranz 2009-09-24 8:05 ` Johannes Berg 2009-09-24 19:13 ` Hin-Tak Leung 2009-09-25 6:22 ` Johannes Berg 2009-09-25 15:54 ` Hin-Tak Leung 2009-09-26 11:39 ` Johannes Berg 2009-09-26 23:57 ` Hin-Tak Leung 2009-09-28 14:41 ` Johannes Berg 2009-09-30 21:17 ` Hin-Tak Leung 2009-09-30 21:20 ` Johannes Berg 2009-09-28 18:04 ` Albert Herranz 2009-09-28 18:55 ` Johannes Berg 2009-09-28 19:22 ` Hin-Tak Leung
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.