|Summary:||[ath] race conditions between scanning and beacon timeout programming|
|Product:||Base System||Reporter:||Adrian Chadd <adrian>|
|Component:||wireless||Assignee:||freebsd-wireless (Nobody) <wireless>|
|Severity:||Affects Only Me|
Description Adrian Chadd 2012-02-20 02:40:09 UTC
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. Fix: 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? How-To-Repeat: The above should be doable to reproduce - just enable beacon debugging, then do a scan and kill the AP whilst the station is scanning.
Comment 1 Adrian Chadd 2012-02-20 02:42:58 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-wireless Reassign
Comment 2 Eitan Adler 2018-05-28 19:47:01 UTC
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.