ath9k / ath9k_htc: strange behavior of the TSF value

Oleksij Rempel linux at rempel-privat.de
Thu Feb 18 07:19:15 PST 2016


Hi Robert,

Am 18.02.2016 um 16:00 schrieb Robert Felten:
> Hi all,
> 
> in my understanding, the TSF value is used to synchronize the medium
> access in a BSS. Also my expectation the TSF value would just increase
> monotonic (until rollover).
> 
> But the TSF value (provided by the radiotap headers) shows a strange
> behavior on my machine:
> Sometimes the value increases a lot, and shortly after, in decreases
> almost by the same amount.
> 
> To understand this behavior, I set up my TL-WN722N (AR9271, ath9k_htc)
> device in STA mode (connected it to an AP) and dumped ~200k packets in
> Wireshark.
> Then I extracted the of TSF the STA and the TSF in the of the beacon
> frames via tshark:
> 
>  $ tshark -nr dump.pcapng -T fields  -e frame.number -e
> radiotap.mactime -e wlan_mgt.fixed.timestamp -R 'wlan.bssid == <AP's
> MAC>  and wlan.fc.subtype == 8'"
> 
> The AP's TSF shows the expected monotonic behavior, but the local STA
> TSF "jumps" somehow, for instance on the frame # 121641 or 224784:
> 
> Frame#   STA TSF                AP TSF
> 121594    2160015947309    0x000000c7ec26f9b2
> 121614    2160016082477    0x000000c7ec2889b1
> 121626    2160016152108    0x000000c7ec2a19b2
> 121641    2160032998968    0x000000c7ec2ba9bf   <-- STA TSF ???
> 121657    2160016356907    0x000000c7ec2d39b4
> 121684    2160016459308    0x000000c7ec2ec9b4
> 121714    2160016594080    0x000000c7ec305828
> ...
> 224473    2160099843558    0x000000c7f126a380
> 224550    2160099913188    0x000000c7f1283380
> 224683    2160100015591    0x000000c7f129c380
> 224784    2160368520676    0x000000c7f12b5380  <-- STA TSF ???
> 224872    2160100222543    0x000000c7f12cebeb
> 224890    2160100355555    0x000000c7f12e7380
> 225252    2160100629986    0x000000c7f1332380
> ...
> 
> The STA TSF value only "jumps" on beacon packets (I tested w/o the
> filter 'wlan.fc.subtype == 8' ) and the "jumps" differs a lot in
> magnitude. I seems that the next beacon set the value back to an
> expected value.
> 
> I would be very happy if someone could versify / falsify of this
> behavior on his/hers machine and/or point me to an explanation. :)
> 
> My kernel is 3.19.0-49-generic #55~14.04.1-Ubuntu SMP and an ath9k_htc
> based TL-WRN722N WiFi device. Further details of any level could be
> provided on request.
> 

There was a Firmware fix for this issue. It should be in FW version 1.4
I assume you are using 1.3.
Please update your kernel and FW.

-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/ath9k_htc_fw/attachments/20160218/504e2fac/attachment.sig>


More information about the ath9k_htc_fw mailing list