ath9k / ath9k_htc: strange behavior of the TSF value
Robert Felten
robert.felten at googlemail.com
Fri Feb 19 02:40:20 PST 2016
Hi Oleksij,
thanks for your fast reply. Indeed the strange behavior gone in
ath9k_htc fw v1.4.
Thanks! :)
BR
Robert
2016-02-18 16:19 GMT+01:00 Oleksij Rempel <linux at rempel-privat.de>:
> 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
>
More information about the ath9k_htc_fw
mailing list