repeat scanning could cause disassoc
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
Hi,
Quoted 4 lines
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 passieee80211_rx_h_passive_scanwhich only will deliver
Quoted 8 lines
beacon and probe request, which what we want, except that we only update
last_rxin the functionieee80211_rx_h_sta_processwhich 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 updatelast_rxcausing 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...
Quoted 3 lines
I wonder if we can move
ieee80211_rx_h_sta_processbeforeieee80211_rx_h_passive_scanor at least therx_lastupdate 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
[could you turn off HTML mail please?]
Quoted 5 lines
I am not sure if the AP actually sending any data frame since we are scanning,
but the major problem is mac80211 does not updaterx_lastonce 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