mac80211 doesn't reassociate after failed ProbeResp

mac80211 doesn't reassociate after failed ProbeResp

[Stefano Brivio]

I got a quite reproducible bug with mac80211. Sometimes, this happens
(phy0 is a b43 PHY):

Nov  7 02:06:23 morte [123784.591945] wlan0: No ProbeResp from current AP 00:14:c1:35:8d:eb - assume out of range
Nov  7 02:06:23 morte [123784.591968] phy0: Removed STA 00:14:c1:35:8d:eb

then, instead of trying to reassociate, mac80211 acts like this:
Nov  7 02:06:25 morte [123785.138041] wlan0: dropped data frame to not associated station 00:14:c1:35:8d:eb
Nov  7 02:06:25 morte [123785.138243] wlan0: dropped data frame to not associated station 00:14:c1:35:8d:eb
Nov  7 02:06:55 morte [123798.704732] wlan0: No STA entry for own AP 00:14:c1:35:8d:eb

I guess that's a mac80211 bug. I'll be happy to provide you with more
testing.


-- 
Ciao
Stefano

Re: mac80211 doesn't reassociate after failed ProbeResp

[Stefano Brivio]

On Wed, 7 Nov 2007 10:21:58 +0100
Stefano Brivio <stefano.brivio@polimi.it> wrote:

> I got a quite reproducible bug with mac80211. Sometimes, this happens
> (phy0 is a b43 PHY):
> 
> Nov  7 02:06:23 morte [123784.591945] wlan0: No ProbeResp from current AP
> 00:14:c1:35:8d:eb - assume out of range Nov  7 02:06:23 morte
> [123784.591968] phy0: Removed STA 00:14:c1:35:8d:eb
> 
> then, instead of trying to reassociate, mac80211 acts like this:
> Nov  7 02:06:25 morte [123785.138041] wlan0: dropped data frame to not
> associated station 00:14:c1:35:8d:eb Nov  7 02:06:25 morte
> [123785.138243] wlan0: dropped data frame to not associated station
> 00:14:c1:35:8d:eb Nov  7 02:06:55 morte [123798.704732] wlan0: No STA
> entry for own AP 00:14:c1:35:8d:eb

BTW, what I have to do to get mac80211 to associate is to set a bogus ESSID
and then the correct one back, then it will associate.


-- 
Ciao
Stefano

Re: mac80211 doesn't reassociate after failed ProbeResp

[Stefano Brivio]

This fixes the issue for me. Note that this is a dirty hack and may break
roaming and everything badly. Will try to fix this better.

--- net/mac80211/ieee80211_sta.c~       2007-11-07 12:08:08.847346973 +0100
+++ net/mac80211/ieee80211_sta.c        2007-11-07 12:08:08.848346821 +0100
@@ -785,7 +785,7 @@
                                       "range\n",
                                       dev->name, print_mac(mac, ifsta->bssid));
                                disassoc = 1;
-                               sta_info_free(sta);
+//                             sta_info_free(sta);
                        } else
                                ieee80211_send_probe_req(dev, ifsta->bssid,
                                                         local->scan_ssid,


-- 
Ciao
Stefano

Re: mac80211 doesn't reassociate after failed ProbeResp

[Claudio Matsuoka]

On Wednesday 07 November 2007 07:21:58 Stefano Brivio wrote:

> then, instead of trying to reassociate, mac80211 acts like this:
> Nov  7 02:06:25 morte [123785.138041] wlan0: dropped data frame to not
> associated station 00:14:c1:35:8d:eb Nov  7 02:06:25 morte [123785.138243]

I confirm this problem with the b43, and also rtl8187 (which sometimes 
reassociates spontaneously, sometimes not).

Re: mac80211 doesn't reassociate after failed ProbeResp

[drago01]

Claudio Matsuoka wrote:
> On Wednesday 07 November 2007 07:21:58 Stefano Brivio wrote:
>
>   
>> then, instead of trying to reassociate, mac80211 acts like this:
>> Nov  7 02:06:25 morte [123785.138041] wlan0: dropped data frame to not
>> associated station 00:14:c1:35:8d:eb Nov  7 02:06:25 morte [123785.138243]
>>     
>
> I confirm this problem with the b43, and also rtl8187 (which sometimes 
> reassociates spontaneously, sometimes not).
>
>   
I have also seen some reports where this happened with iwl3945/4965

Re: mac80211 doesn't reassociate after failed ProbeResp

[Stefano Brivio]

I tried another test. I switched my radio off for less than five seconds,
then on again. I then had to force reassociation manually. I think I hit
the following if-clause:

	if (time_after(jiffies,
		       sta->last_rx + IEEE80211_MONITORING_INTERVAL)) {

in ieee80211_sta.c, with IEEE80211_MONITORING_INTERVAL being 2 * HZ.

I would argue that this is far away from the acceptable behaviour for a
wireless stack. I'm sorry I can't provide a patch, but I really can't read
the code. Using an higher value for IEEE80211_MONITORING_INTERVAL could
result in decreased risks of peptic ulcer, but I don't think this is the
right fix. Any clues? Thanks.


-- 
Ciao
Stefano