kern/165306: [ath] race conditions between scanning and beacon timeout programming

Adrian Chadd adrian at
Mon Feb 20 02:40:10 UTC 2012

>Number:         165306
>Category:       kern
>Synopsis:       [ath] race conditions between scanning and beacon timeout programming
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 20 02:40:09 UTC 2012
>Originator:     Adrian Chadd
>Release:        9.0-RELEASE i386 w/ HEAD net80211/ath
There seem to be issues where net80211 doesn't quite get the "beacon miss" notification. It stays associated, the beacon interrupt/notification isn't occuring.

Adding on reset/beacon debugging (0x20 + 0x80) on ath0 (sysctl dev.ath.0.debug=0xa0) didn't show any beacon miss interrupts, software or hardware.

This is with one VAP STA on an AR9280.

What I think is happening is:

* the transition to -> RUN doesn't program in any beacon timers by default - it waits for the first beacon to be RX'ed before it programs in timers;
* but if it loses connectivity during a scan, the beacon timers won't ever be reprogrammed, as no beacons will occur.

So it stays associated.
The above should be doable to reproduce - just enable beacon debugging, then do a scan and kill the AP whilst the station is scanning.

It may be that we need to:

* program in some beacon TSF value for the initial state transition to RUN, and hope that a new beacon will come in and reprogram the timers.
* .. or also enable swbeacon support too for single-VAP STA mode?


More information about the freebsd-bugs mailing list