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
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
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).
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
On Wed, 7 Nov 2007 10:21:58 +0100
Stefano Brivio <[email protected]> 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
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