Warning when terminating wpa_supplicant (wext driver)

Warning when terminating wpa_supplicant (wext driver)

[Marcel Holtmann]

Hi guys,

so I am running the wireless-testing.git tree from today and when
terminating wpa_supplicant (wext driver), I get this warning in my
kernel logs:

------------[ cut here ]------------
WARNING: at net/mac80211/agg-tx.c:142 ___ieee80211_stop_tx_ba_session+0x6b/0x7e [mac80211]()
Hardware name: 7454CTO
Modules linked in: tun fuse sco bluetooth binfmt_misc uinput iwlagn snd_hda_codec_conexant snd_hda_intel iwlcore snd_hda_codec i2400m_usb mbm cdc_ether i2400m usbnet uvcvideo snd_pcm mii mac80211 cdc_acm cdc_wdm snd_timer snd cfg80211 wimax soundcore snd_page_alloc uhci_hcd ehci_hcd [last unloaded: microcode]
Pid: 2741, comm: wpa_supplicant Not tainted 2.6.30-rc4-wl #17
Call Trace:
 [<ffffffff80234b58>] warn_slowpath+0xb1/0xe5
 [<ffffffffa014bda4>] ? iwl_tx_agg_stop+0x297/0x2bd [iwlcore]
 [<ffffffffa018612c>] ? iwl_mac_ampdu_action+0x2ab/0x332 [iwlagn]
 [<ffffffffa0088b02>] ___ieee80211_stop_tx_ba_session+0x6b/0x7e [mac80211]
 [<ffffffffa0088c80>] __ieee80211_stop_tx_ba_session+0x63/0x7b [mac80211]
 [<ffffffffa008890c>] ieee80211_sta_tear_down_BA_sessions+0x1b/0x3b [mac80211]
 [<ffffffffa008f105>] ieee80211_stop+0x9f/0x561 [mac80211]
 [<ffffffff80548124>] ? _spin_unlock_bh+0x1e/0x20
 [<ffffffff804b4583>] ? dev_deactivate+0x156/0x186
 [<ffffffff804a72f3>] dev_close+0x74/0x96
 [<ffffffff804a6f93>] dev_change_flags+0xba/0x180
 [<ffffffff804e3008>] devinet_ioctl+0x278/0x604
 [<ffffffff804e423e>] inet_ioctl+0x92/0xaa
 [<ffffffff80497b8e>] sock_ioctl+0x1f1/0x21b
 [<ffffffff802a5970>] vfs_ioctl+0x2a/0x78
 [<ffffffff802a5dfa>] do_vfs_ioctl+0x43c/0x478
 [<ffffffff802a5e8b>] sys_ioctl+0x55/0x77
 [<ffffffff8020af6b>] system_call_fastpath+0x16/0x1b
---[ end trace 8a26567db4679b5c ]---

The hardware is an Intel 5350 card if that actually matters.

Regards

Marcel

Re: Warning when terminating wpa_supplicant (wext driver)

[Johannes Berg]

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

Copying Wey-Yi, but I think she's aware of this? It's definitely a
driver issue. I _suspect_, but am not sure, that the driver kills the
aggregation session when we disassoc or something and we only tell it
about the STA removal after that, when it already killed the STA. Thus
it would be a consequence of iwlwifi not implementing a proper
sta_notify() callback.

johannes

On Wed, 2009-05-06 at 23:18 -0700, Marcel Holtmann wrote:
> Hi guys,
> 
> so I am running the wireless-testing.git tree from today and when
> terminating wpa_supplicant (wext driver), I get this warning in my
> kernel logs:
> 
> ------------[ cut here ]------------
> WARNING: at net/mac80211/agg-tx.c:142 ___ieee80211_stop_tx_ba_session+0x6b/0x7e [mac80211]()
> Hardware name: 7454CTO
> Modules linked in: tun fuse sco bluetooth binfmt_misc uinput iwlagn snd_hda_codec_conexant snd_hda_intel iwlcore snd_hda_codec i2400m_usb mbm cdc_ether i2400m usbnet uvcvideo snd_pcm mii mac80211 cdc_acm cdc_wdm snd_timer snd cfg80211 wimax soundcore snd_page_alloc uhci_hcd ehci_hcd [last unloaded: microcode]
> Pid: 2741, comm: wpa_supplicant Not tainted 2.6.30-rc4-wl #17
> Call Trace:
>  [<ffffffff80234b58>] warn_slowpath+0xb1/0xe5
>  [<ffffffffa014bda4>] ? iwl_tx_agg_stop+0x297/0x2bd [iwlcore]
>  [<ffffffffa018612c>] ? iwl_mac_ampdu_action+0x2ab/0x332 [iwlagn]
>  [<ffffffffa0088b02>] ___ieee80211_stop_tx_ba_session+0x6b/0x7e [mac80211]
>  [<ffffffffa0088c80>] __ieee80211_stop_tx_ba_session+0x63/0x7b [mac80211]
>  [<ffffffffa008890c>] ieee80211_sta_tear_down_BA_sessions+0x1b/0x3b [mac80211]
>  [<ffffffffa008f105>] ieee80211_stop+0x9f/0x561 [mac80211]
>  [<ffffffff80548124>] ? _spin_unlock_bh+0x1e/0x20
>  [<ffffffff804b4583>] ? dev_deactivate+0x156/0x186
>  [<ffffffff804a72f3>] dev_close+0x74/0x96
>  [<ffffffff804a6f93>] dev_change_flags+0xba/0x180
>  [<ffffffff804e3008>] devinet_ioctl+0x278/0x604
>  [<ffffffff804e423e>] inet_ioctl+0x92/0xaa
>  [<ffffffff80497b8e>] sock_ioctl+0x1f1/0x21b
>  [<ffffffff802a5970>] vfs_ioctl+0x2a/0x78
>  [<ffffffff802a5dfa>] do_vfs_ioctl+0x43c/0x478
>  [<ffffffff802a5e8b>] sys_ioctl+0x55/0x77
>  [<ffffffff8020af6b>] system_call_fastpath+0x16/0x1b
> ---[ end trace 8a26567db4679b5c ]---
> 
> The hardware is an Intel 5350 card if that actually matters.
> 
> Regards
> 
> Marcel
> 
> 
> --
> 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
> 

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

Re: Warning when terminating wpa_supplicant (wext driver)

[Marcel Holtmann]

Hi Johannes,

> Copying Wey-Yi, but I think she's aware of this? It's definitely a
> driver issue. I _suspect_, but am not sure, that the driver kills the
> aggregation session when we disassoc or something and we only tell it
> about the STA removal after that, when it already killed the STA. Thus
> it would be a consequence of iwlwifi not implementing a proper
> sta_notify() callback.

I don't see it with nl80211 driver, but that might be pure luck.

Regards

Marcel

Re: Warning when terminating wpa_supplicant (wext driver)

[Johannes Berg]

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

On Thu, 2009-05-07 at 06:53 -0700, Marcel Holtmann wrote:

> > Copying Wey-Yi, but I think she's aware of this? It's definitely a
> > driver issue. I _suspect_, but am not sure, that the driver kills the
> > aggregation session when we disassoc or something and we only tell it
> > about the STA removal after that, when it already killed the STA. Thus
> > it would be a consequence of iwlwifi not implementing a proper
> > sta_notify() callback.
> 
> I don't see it with nl80211 driver, but that might be pure luck.

Hmm, ok, that points to something else maybe... Now I wish I had my
ftrace-mac80211 patch ready. Well, the patch is almost ready but we
can't use ftrace in modules yet...

Maybe there's some timing issue. I still think it's iwlwifi getting
confused about what mac80211 is telling it as described, but it seems
it's a little more subtle than what I said.

johannes

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

Re: Warning when terminating wpa_supplicant (wext driver)

[Marcel Holtmann]

Hi Johannes,

> > > Copying Wey-Yi, but I think she's aware of this? It's definitely a
> > > driver issue. I _suspect_, but am not sure, that the driver kills the
> > > aggregation session when we disassoc or something and we only tell it
> > > about the STA removal after that, when it already killed the STA. Thus
> > > it would be a consequence of iwlwifi not implementing a proper
> > > sta_notify() callback.
> > 
> > I don't see it with nl80211 driver, but that might be pure luck.
> 
> Hmm, ok, that points to something else maybe... Now I wish I had my
> ftrace-mac80211 patch ready. Well, the patch is almost ready but we
> can't use ftrace in modules yet...
> 
> Maybe there's some timing issue. I still think it's iwlwifi getting
> confused about what mac80211 is telling it as described, but it seems
> it's a little more subtle than what I said.

something similar now happened during normal operation:

phy0: AddBA: ssn=277, dialog_token=1 tid=0 timeout=0ba_policy=1
addba: d0 08 40 01 00 16 eb 05 46 5c 00 1c f0 62 88 5b 
addba: 00 1c f0 62 88 5b e0 54 03 00 01 02 10 00 00 50 
addba: 11 
Rx A-MPDU request on tid 0 result 0
wlan0: CTS protection enabled (BSSID=00:1c:f0:xx:xx:xx)
wlan0: CTS protection disabled (BSSID=00:1c:f0:xx:xx:xx)
wlan0: no probe response from AP 00:1c:f0:xx:xx:xx - disassociating
Tx BA session stop requested for 00:1c:f0:xx:xx:xx tid 0
iwlagn 0000:03:00.0: Invalid station for AGG tid 0
------------[ cut here ]------------
WARNING: at net/mac80211/agg-tx.c:142 ___ieee80211_stop_tx_ba_session+0x6b/0x7e [mac80211]()
Hardware name: 7454CTO
Modules linked in: usb_storage option usbserial iwlagn iwlcore mac80211 cfg80211 tun fuse sco bluetooth binfmt_misc uinput snd_hda_codec_conexant snd_hda_inte
l snd_hda_codec snd_pcm snd_timer snd mbm uvcvideo soundcore cdc_ether i2400m usbnet cdc_acm cdc_wdm mii wimax snd_page_alloc uhci_hcd ehci_hcd [last unloaded
: cfg80211]
Pid: 27738, comm: phy0 Tainted: G        W  2.6.30-rc4-wl #17
Call Trace:
 [<ffffffff80234b58>] warn_slowpath+0xb1/0xe5
 [<ffffffffa0412bd2>] ? iwl_tx_agg_stop+0xc5/0x2bd [iwlcore]
 [<ffffffffa043612c>] ? iwl_mac_ampdu_action+0x2ab/0x332 [iwlagn]
 [<ffffffffa03d2b02>] ___ieee80211_stop_tx_ba_session+0x6b/0x7e [mac80211]
 [<ffffffffa03d2c80>] __ieee80211_stop_tx_ba_session+0x63/0x7b [mac80211]
 [<ffffffffa03d290c>] ieee80211_sta_tear_down_BA_sessions+0x1b/0x3b [mac80211]
 [<ffffffffa03d5a66>] ieee80211_set_disassoc+0xe4/0x2c9 [mac80211]
 [<ffffffffa03d6c77>] ieee80211_associated+0x18b/0x1b0 [mac80211]
 [<ffffffffa03d89c6>] ieee80211_sta_work+0x85d/0x8bb [mac80211]
 [<ffffffff80548227>] ? _spin_unlock_irqrestore+0x8/0x30
 [<ffffffffa03d8169>] ? ieee80211_sta_work+0x0/0x8bb [mac80211]
 [<ffffffff80244081>] worker_thread+0x132/0x1d8
 [<ffffffff80247c7e>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff80243f4f>] ? worker_thread+0x0/0x1d8
 [<ffffffff80243f4f>] ? worker_thread+0x0/0x1d8
 [<ffffffff8024791a>] kthread+0x56/0x83
 [<ffffffff8020bf6a>] child_rip+0xa/0x20
 [<ffffffff802478c4>] ? kthread+0x0/0x83
 [<ffffffff8020bf60>] ? child_rip+0x0/0x20
---[ end trace b434b88b93a5b684 ]---
Rx BA session stop requested for 00:1c:f0:xx:xx:xx tid 0
iwlagn 0000:03:00.0: Invalid station for AGG tid 0
HW problem - can not stop rx aggregation for tid 0
phy0: device now idle
phy0: Removed STA 00:1c:f0:xx:xx:xx
mac80211-phy0: failed to remove key (0, 00:1c:f0:xx:xx:xx) from hardware (-22)
phy0: Destroyed STA 00:1c:f0:xx:xx:xx
phy0: device no longer idle - scanning
phy0: device now idle
phy0: device no longer idle - in use
wlan0: authenticate with AP 00:1c:f0:xx:xx:xx
wlan0: authenticate with AP 00:1c:f0:xx:xx:xx
wlan0: authenticated
phy0: device now idle
phy0: device no longer idle - in use
wlan0: associate with AP 00:1c:f0:xx:xx:xx
wlan0: RX ReassocResp from 00:1c:f0:xx:xx:xx (capab=0x431 status=0 aid=4)
wlan0: associated
phy0: Allocated STA 00:1c:f0:xx:xx:xx
phy0: Inserted STA 00:1c:f0:xx:xx:xx
wmaster0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
wmaster0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
wmaster0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
wmaster0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
wlan0: switched to short barker preamble (BSSID=00:1c:f0:xx:xx:xx)
wlan0: switched to short slot time (BSSID=00:1c:f0:xx:xx:xx)
Open BA session requested for 00:1c:f0:xx:xx:xx tid 0
iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:1c:f0:xx:xx:xx tid = 0
activated addBA response timer on tid 0
switched off addBA timer for tid 0 
Aggregation is on for tid 0 
phy0: AddBA: ssn=118, dialog_token=1 tid=0 timeout=0ba_policy=1
addba: d0 00 40 01 00 16 eb 05 46 5c 00 1c f0 62 88 5b 
addba: 00 1c f0 62 88 5b 30 8e 03 00 01 02 10 00 00 60 
addba: 07 
Rx A-MPDU request on tid 0 result 0

Regards

Marcel

Re: Warning when terminating wpa_supplicant (wext driver)

[Luis R. Rodriguez]

On Fri, May 8, 2009 at 5:02 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johannes,
>
>> > > Copying Wey-Yi, but I think she's aware of this? It's definitely a
>> > > driver issue. I _suspect_, but am not sure, that the driver kills the
>> > > aggregation session when we disassoc or something and we only tell it
>> > > about the STA removal after that, when it already killed the STA. Thus
>> > > it would be a consequence of iwlwifi not implementing a proper
>> > > sta_notify() callback.
>> >
>> > I don't see it with nl80211 driver, but that might be pure luck.
>>
>> Hmm, ok, that points to something else maybe... Now I wish I had my
>> ftrace-mac80211 patch ready. Well, the patch is almost ready but we
>> can't use ftrace in modules yet...
>>
>> Maybe there's some timing issue. I still think it's iwlwifi getting
>> confused about what mac80211 is telling it as described, but it seems
>> it's a little more subtle than what I said.
>
> something similar now happened during normal operation:

Just curious, have you applied johill's latest idle fix patch? I've
been running iperf overnight with it and my woes are gone. I tested RX
though, I'm leaving TX running now but haven't yet seen any warn.

  Luis

Re: Warning when terminating wpa_supplicant (wext driver)

[Luis R. Rodriguez]

On Fri, May 8, 2009 at 6:13 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, May 8, 2009 at 5:02 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>> Hi Johannes,
>>
>>> > > Copying Wey-Yi, but I think she's aware of this? It's definitely a
>>> > > driver issue. I _suspect_, but am not sure, that the driver kills the
>>> > > aggregation session when we disassoc or something and we only tell it
>>> > > about the STA removal after that, when it already killed the STA. Thus
>>> > > it would be a consequence of iwlwifi not implementing a proper
>>> > > sta_notify() callback.
>>> >
>>> > I don't see it with nl80211 driver, but that might be pure luck.
>>>
>>> Hmm, ok, that points to something else maybe... Now I wish I had my
>>> ftrace-mac80211 patch ready. Well, the patch is almost ready but we
>>> can't use ftrace in modules yet...
>>>
>>> Maybe there's some timing issue. I still think it's iwlwifi getting
>>> confused about what mac80211 is telling it as described, but it seems
>>> it's a little more subtle than what I said.
>>
>> something similar now happened during normal operation:
>
> Just curious, have you applied johill's latest idle fix patch? I've
> been running iperf overnight with it and my woes are gone. I tested RX
> though, I'm leaving TX running now but haven't yet seen any warn.

BTW the patch is

mac80211: fix scan channel race

  Luis

Re: Warning when terminating wpa_supplicant (wext driver)

[Marcel Holtmann]

Hi Johannes,

> >> > > Copying Wey-Yi, but I think she's aware of this? It's definitely a
> >> > > driver issue. I _suspect_, but am not sure, that the driver kills the
> >> > > aggregation session when we disassoc or something and we only tell it
> >> > > about the STA removal after that, when it already killed the STA. Thus
> >> > > it would be a consequence of iwlwifi not implementing a proper
> >> > > sta_notify() callback.
> >> >
> >> > I don't see it with nl80211 driver, but that might be pure luck.
> >>
> >> Hmm, ok, that points to something else maybe... Now I wish I had my
> >> ftrace-mac80211 patch ready. Well, the patch is almost ready but we
> >> can't use ftrace in modules yet...
> >>
> >> Maybe there's some timing issue. I still think it's iwlwifi getting
> >> confused about what mac80211 is telling it as described, but it seems
> >> it's a little more subtle than what I said.
> >
> > something similar now happened during normal operation:
> 
> Just curious, have you applied johill's latest idle fix patch? I've
> been running iperf overnight with it and my woes are gone. I tested RX
> though, I'm leaving TX running now but haven't yet seen any warn.

this is still running wireless-testing.git from yesterday with the debug
addBA patch from Johannes.

Regards

Marcel

Re: Warning when terminating wpa_supplicant (wext driver)

[Luis R. Rodriguez]

On Fri, May 8, 2009 at 6:18 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johannes,
>
>> >> > > Copying Wey-Yi, but I think she's aware of this? It's definitely a
>> >> > > driver issue. I _suspect_, but am not sure, that the driver kills the
>> >> > > aggregation session when we disassoc or something and we only tell it
>> >> > > about the STA removal after that, when it already killed the STA. Thus
>> >> > > it would be a consequence of iwlwifi not implementing a proper
>> >> > > sta_notify() callback.
>> >> >
>> >> > I don't see it with nl80211 driver, but that might be pure luck.
>> >>
>> >> Hmm, ok, that points to something else maybe... Now I wish I had my
>> >> ftrace-mac80211 patch ready. Well, the patch is almost ready but we
>> >> can't use ftrace in modules yet...
>> >>
>> >> Maybe there's some timing issue. I still think it's iwlwifi getting
>> >> confused about what mac80211 is telling it as described, but it seems
>> >> it's a little more subtle than what I said.
>> >
>> > something similar now happened during normal operation:
>>
>> Just curious, have you applied johill's latest idle fix patch? I've
>> been running iperf overnight with it and my woes are gone. I tested RX
>> though, I'm leaving TX running now but haven't yet seen any warn.
>
> this is still running wireless-testing.git from yesterday with the debug
> addBA patch from Johannes.

Ok yeah wl from yesterday didn't have johill's patch applied yet.

>From the looks of it the intel hardware doesn't want to stop the
aggregation session which is API-breakage -- which is why you get the
WARN_ON. This is happening when you are disassociating. I have a
feeling johill's other patch will fix your issue but regardless I
believe this just highlights more we should flush our queues (both RX
and TX) before scanning.

  Luis

Re: Warning when terminating wpa_supplicant (wext driver)

[Johannes Berg]

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

On Fri, 2009-05-08 at 18:23 -0700, Luis R. Rodriguez wrote:

> From the looks of it the intel hardware doesn't want to stop the
> aggregation session which is API-breakage -- which is why you get the
> WARN_ON.

Yup.

>  This is happening when you are disassociating. 

Exactly. But not always, it seems.

> I have a
> feeling johill's other patch will fix your issue but regardless I
> believe this just highlights more we should flush our queues (both RX
> and TX) before scanning.

It might fix the disassoc, but I don't think it'll fix this issue. Might
make it disappear anyway though.

johannes

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

Re: Warning when terminating wpa_supplicant (wext driver)

[Johannes Berg]

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

On Fri, 2009-05-08 at 17:02 -0700, Marcel Holtmann wrote:

> phy0: AddBA: ssn=277, dialog_token=1 tid=0 timeout=0ba_policy=1

> Rx A-MPDU request on tid 0 result 0
> wlan0: CTS protection enabled (BSSID=00:1c:f0:xx:xx:xx)
> wlan0: CTS protection disabled (BSSID=00:1c:f0:xx:xx:xx)
> wlan0: no probe response from AP 00:1c:f0:xx:xx:xx - disassociating

At this point we tell the driver we're no longer associated. I think the
driver takes that as a reason to remove the station struct it keeps
track of in the driver. However,

> Tx BA session stop requested for 00:1c:f0:xx:xx:xx tid 0

now we stop the TX BA session

> iwlagn 0000:03:00.0: Invalid station for AGG tid 0

and iwlwifi no longer finds the station for it, returns an error

> ------------[ cut here ]------------
> WARNING: at net/mac80211/agg-tx.c:142 ___ieee80211_stop_tx_ba_session+0x6b/0x7e [mac80211]()

which causes the warning

> Rx BA session stop requested for 00:1c:f0:xx:xx:xx tid 0
> iwlagn 0000:03:00.0: Invalid station for AGG tid 0
> HW problem - can not stop rx aggregation for tid 0

same here -- but it's not a WARN_ON (though it probably should be!)

> phy0: device now idle
> phy0: Removed STA 00:1c:f0:xx:xx:xx

_Now_ mac80211 starts removing the station info.

> mac80211-phy0: failed to remove key (0, 00:1c:f0:xx:xx:xx) from hardware (-22)

before it asks the driver to remove the station with sta_notify, it
removes the key for the station. But even that fails, since iwlwifi
knows nothing about the station.

> phy0: Destroyed STA 00:1c:f0:xx:xx:xx

Now mac80211 has gotten rid of the sta struct completely.


I really really think the problem is that iwlwifi insists on keeping
track of station information with the wrong callback. It should be using
the sta_notify() callback, but it uses the bss_info_changed() callback,
which leads to ordering issues because we first tell the driver that we
disassociated, and _then_ remove all the information about the STA.

Now, I guess it's debatable whether or not we should tell the driver
that we disassociated _before_ we remove the station for the AP. But if
we reorder, other drivers might get confused because, well, we first
remove the AP STA and then tell them we disassociated -- but what from?

Therefore, I think disassociating first and then removing the station
information is correct.

However, to test my theory, you could apply the below patch. I suspect
it will no longer happen with this patch and iwlwifi.

Ultimately though I think iwlwifi just needs to be fixed wrt. station
handling. A whole lot of complex lookup code will go away because
mac80211 passes station structs wherever needed, which will improve
performance and reduce code size significantly.

johannes

--- wireless-testing.orig/net/mac80211/mlme.c	2009-05-09 13:06:54.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c	2009-05-09 13:07:59.000000000 +0200
@@ -1062,9 +1062,6 @@ static void ieee80211_set_disassoc(struc
 		config_changed |= IEEE80211_CONF_CHANGE_PS;
 	}
 
-	ieee80211_hw_config(local, config_changed);
-	ieee80211_bss_info_change_notify(sdata, changed);
-
 	rcu_read_lock();
 
 	sta = sta_info_get(local, ifmgd->bssid);
@@ -1078,6 +1075,9 @@ static void ieee80211_set_disassoc(struc
 	rcu_read_unlock();
 
 	sta_info_destroy(sta);
+
+	ieee80211_hw_config(local, config_changed);
+	ieee80211_bss_info_change_notify(sdata, changed);
 }
 
 static int ieee80211_sta_wep_configured(struct ieee80211_sub_if_data *sdata)


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