Gary Morain wrote: > 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. If this is with ath9k, there is a much more fundamental issue - the HW beacon timers are never re-programmed with the correct values, which can be done only after a TSF sync. The sequence is like this: * ath9k associates to an AP * A scan is started on the station side. * The HW is reset as part of the scan. * The scan completes. * ath9k sets the BSSID and configures beacon timers - but, without waiting for the HW TSF sync, so the timers end up being programmed incorrectly. This is with wireless-testing. Sujith -- 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
