Lost commit mail

Adrian Chadd adrian.chadd at gmail.com
Mon Nov 28 08:51:46 UTC 2016


... and FYI - one of them is wrong - i'll back it out once i figure
out why the FreeBSD AP side is being garbage and commit a better "spec
compliant" fix.

ugh.. :(


-a


On 27 November 2016 at 21:29, Peter Wemm <peter at wemm.org> wrote:
> There were two commits in the window where src-committers@ was broken.
>
> https://svnweb.freebsd.org/changeset/base/309222
> https://svnweb.freebsd.org/changeset/base/309223
>
> ------------------------------------------------------------------------
> r309223 | adrian | 2016-11-27 18:59:33 -0800 (Sun, 27 Nov 2016) | 54 lines
> Changed paths:
>    M /head/sys/dev/ath/if_ath_beacon.c
>
> [ath] fix target beacon interval programming for STA mode when in powersave.
>
> This bug has been bugging me for quite some time.  I finally sat down
> with enough coffee to figure it out.
>
> The short of it - rounding up to the next intval multiple of the TSF value
> only works if the AP is transmitting all its beacons on an interval of
> the TSF.  If it isn't - for example, doing staggered beacons on a multi-VAP
> setup with a single hardware TSF - then weird things occur.
>
> The long of it -
>
> When powersave is enabled, the MAC and PHY are partially powered off.
> They can't receive any packets (or transmit, for that matter.)
> The target beacon timer programming will wake up the MAC/PHY just before
> the beacon is supposed to be received (well, strictly speaking, at DTIM
> so it can see the TIM - traffic information map - telling the STA whether
> any traffic is there for it) and it happens automatically.
>
> However, this relies on the target beacon time being programmed correctly.
> If it isn't then the hardware will wake up and not hear any beacons -
> and then it'll be asleep for said beacons.  After enough of this, net80211
> will give up and assume the AP went away.
>
> This should fix both TSFOOR interrupts and disconnects from APs with powersave
> enabled.
>
> The annoying bit is that it only happens if APs stagger things or start
> on a non-zero TSF.  So, this would sometimes be fine and sometimes not be
> fine.
>
> What:
>
> * I don't know (yet) why the code rounds up to the next intval.
>   For now, just disable rounding it and trust the value we get.
>
> TODO:
>
> * If we do see a beacon miss in STA mode then we should transition
>   out of sleep for a while so we can hear beacons to resync against.
>   I'd love a patch from someone to enable that particular behaviour.
>   Note - that doesn't require that net80211 brings the chip out of
>   sleep state - only that we wake the chip up through to full-on and
>   then let it go to sleep again when we've seen a beacon.  The wifi
>   stack and AP can still completely just stay believing we're in sleep
>   mode.
>
> Tested:
>
> * AR9485, STA mode, powersave enabled
>
> MFC after:      1 week
> Relnotes:       Yes
>
> ------------------------------------------------------------------------
> r309222 | adrian | 2016-11-27 18:51:55 -0800 (Sun, 27 Nov 2016) | 5 lines
> Changed paths:
>    M /head/sys/dev/ath/if_ath_rx.c
>
> [ath] include logging of TU versions of the TSF values.
>
> The beacon programming side of things deals in TUs and 1/8th TUs, so
> it's good to se the TU value here when debugging beaconing issues.
>
> ------------------------------------------------------------------------
>
>
> --
> Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
> UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
>


More information about the freebsd-wireless mailing list