[resending in plan text] On Mon, May 21, 2012 at 12:26 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Fri, 2012-05-18 at 13:49 -0700, Gary Morain wrote: > > When a nullfunc probe fails for lack of an ACK, it is retried > > almost immediately. The current setting of 2 retries completes > > in about 4 ms. If an AP is off-channel scanning, this is not > > enough time for the AP to return to the operating channel and > > ACK the nullfunc. As a result, the client disconnects when the > > AP is still there and operating. > > AP is off-channel, scanning? It can't be unless it's a GO and then you > have GO powersave, right? Scenario: 1. Client connects to a managed AP. 2. Client goes off-channel to scan for APs. 3. AP goes off-channel to scan for rogue APs. The client misses any signaling the AP may have sent. 4. The client returns to its home channel before the AP does. 5. The client immediately probes the AP with a nullfunc. (ieee80211_mlme_notify_scan_completed()). 6. The AP does not respond to the nullfunc because it is off-channel. 7. The client retries the nullfunc, which also does not get an ACK, and the client disconnects from the AP (ieee80211_sta_work). It's worth noticing that the client never detects beacon loss because the AP is not off-channel long enough to miss sending multiple beacons. > > > > -static int max_nullfunc_tries = 2; > > +static int max_nullfunc_tries = 100; > > 100? That seems insanely high compared to the other one. 100 retries take about 200 ms. In my testing, the range of time that the AP was off-channel after the client returned home ranged from 20 to 104 ms. I did a test with the retry set to 50, but it was too low some of the time. 100 gives plenty of headroom. > > > johannes > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
