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
On Wed, 2009-09-30 at 22:17 +0100, Hin-Tak Leung wrote:
> On Sat, Sep 26, 2009 at 12:39 PM, Johannes Berg
> <[email protected]> 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
On Mon, Sep 28, 2009 at 7:55 PM, Johannes Berg
<[email protected]> 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
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
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
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
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;
On Fri, Sep 25, 2009 at 7:22 AM, Johannes Berg
<[email protected]> 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
On Sat, Sep 26, 2009 at 12:39 PM, Johannes Berg
<[email protected]> 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
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
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
On Sat, Sep 26, 2009 at 12:39 PM, Johannes Berg
<[email protected]> 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
>
On Thu, Sep 24, 2009 at 9:05 AM, Johannes Berg
<[email protected]> 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.
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
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