Date: Wed, 29 Jun 2011 13:21:52 +0000 (UTC) From: Adrian Chadd <adrian@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/dev/ath if_ath.c Message-ID: <201106291322.p5TDMCxX051484@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
adrian 2011-06-29 13:21:52 UTC
FreeBSD src repository
Modified files:
sys/dev/ath if_ath.c
Log:
SVN rev 223671 on 2011-06-29 13:21:52Z by adrian
Fix a corner case in STA beacon processing when a CSA is received but
the AP doesn't transmit beacons.
If the AP requests a CSA (ie, a channel switch) and then enters CAC
(channel availability check) for 60 seconds, it doesn't send beacons
and it just listens for radar events (and other things which we don't
do yet.)
Now, ath_newstate() was not resetting the beacon timer config on
a transition to the RUN state when in STA mode - it was setting
sc_syncbeacon, which simply updates the beacon config from the
contents of the next received beacon.
This means the STA never generates beacon miss events.
If the AP goes into CAC for 60 seconds and recovers, the STA will
happily receive the first beacon and reconfigure timers.
But if it gets a radar event after that, it'll change channel
again, not notify the station that it's changed channel..
and since the station is happily waiting for the first beacon
to configure the beacon timer details from, it won't ever
generate a beacon miss interrupt and it'll sit there forever
(or until the AP appears on that channel once again.)
This change forces the last known beacon timer config to be
written to hardware on a transition from CSA->RUN in STA mode.
This forces bmiss events to occur and the STA will eventually
(after a handful of beacon miss events) begin scanning for
another access point.
Revision Changes Path
1.329 +10 -0 src/sys/dev/ath/if_ath.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106291322.p5TDMCxX051484>