Search Linux Wireless

[PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux Kernel]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]     [Free Dating]     [M2M Wireless]

Add to Google Powered by Linux