repeat scanning could cause disassoc

repeat scanning could cause disassoc

[mabbas]

Hi
If I keep repeating scanning for like 4 times in the raw, the mac80211 
can disassociated because No ProbeResp.
looking at the rx patch if we are scanning we wont pass 
ieee80211_rx_h_passive_scan which only will deliver
beacon and probe request, which what we want, except that we only update 
last_rx in the function
ieee80211_rx_h_sta_process which is two functions down rx handlers.
In iwlwifi we do perform hw scan, in this command if scan takes a long 
time, and we are associated, it will tunes to associated channel to
allow getting beacons for a period of time, then continue with scanning. 
we do receive beacons on the associated
channel but mac80211 never update last_rx causing the disassociation.
I wonder if we can move ieee80211_rx_h_sta_process before 
ieee80211_rx_h_passive_scan or at least the rx_last
update part.
Thanks
Mohamed

Re: repeat scanning could cause disassoc

[Johannes Berg]

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

Hi,

> If I keep repeating scanning for like 4 times in the raw, the mac80211 
> can disassociated because No ProbeResp.
> looking at the rx patch if we are scanning we wont pass 
> ieee80211_rx_h_passive_scan which only will deliver
> beacon and probe request, which what we want, except that we only update 
> last_rx in the function
> ieee80211_rx_h_sta_process which is two functions down rx handlers.
> In iwlwifi we do perform hw scan, in this command if scan takes a long 
> time, and we are associated, it will tunes to associated channel to
> allow getting beacons for a period of time, then continue with scanning. 
> we do receive beacons on the associated
> channel but mac80211 never update last_rx causing the disassociation.

Interesting. If the scan takes such a long time, what do you do when
there are actually data frames coming in during the time you listen on
the associated channel? I think you'd have to buffer them because they
also would be dropped by ieee80211_rx_h_passive_scan...

> I wonder if we can move ieee80211_rx_h_sta_process before 
> ieee80211_rx_h_passive_scan or at least the rx_last
> update part.

I guess we could, the intention of the check is probably to find going
out of range or such rather than disassociating when you've missed too
much traffic :)

Michael, you gave scanning and background scanning much more thought, I
can see the problem here but not the solution. Shouldn't we be doing
this back-tuning in mac80211 too then?

johannes

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

Re: repeat scanning could cause disassoc

[Johannes Berg]

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

[could you turn off HTML mail please?]
 
> I am not sure if the AP actually sending any data frame since we are
> scanning, 
> but the major problem is mac80211 does not update rx_last once
> recieved
> beacon during scanning causing the disconnect.

I'm somewhat confused now. What happens if we do background scanning in
mac80211 is that we tell the AP we want powersave mode and then go do
the scan.

Do you actually see the message "<device>: expiring inactive STA ..."?
Basically, what I can see happen is that the scan takes so long that the
check there in ieee80211_associated() (called from ieee80211_sta_work())
triggers, but that means the scan took on the order of two seconds. Is
that so?

I suppose we should update last_rx when we go out of the scan to avoid
this since there's no way we can determine whether the AP dropped off
during the time we scan. What you proposed was to update last_rx when we
see frames from our AP, but even then if we're the first channel of the
scan it doesn't really help. Then again you said that the firmware goes
back to the channel it's supposed to be on once a while, that is with
the hardware scan callback then?

johannes


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