Comment # 11
on bug 9586
from Emburey
(In reply to comment #2) PLEASE SEE INLINED
> What do the bits in the "flags", "status", and "flagsN" (presumably meaning
> "802.11n flags") fields mean? Without being told that, we cannot dissect
> them.
>
[emburey] These 3 are few of the fields that internally represent a
combination of certain factors (like control frame indication, WEP, bandwidth
range..) of a packet. So a mere binary representation of them should be
sufficient.
> Are the "Data rate" fields both in units of 500 MHz?
>
[emburey] Data rate field is 500Kbps for legacy header, and so would be
2-byte. For the new header, it would range till 600Mbps, and so it is in a
4-byte field.
> What is the meaning of the "Band" field in the 55-byte header?
>
[emburey] It is bandwidth for 11n/11ac, and can be shown in decimal format
(would be always 300, 301, 400, 401, or 402)
> Do the numbers in the labels of the "Signal dBm{1,2,3,4}" and "Noise
> dBm{1,2,3,4}" refer to antennas?
>
[emburey] Not exactly. They can be ignored, since they all are hard-coded to 0
internally.
> What are the different possible values in the "Type" field?
>
[emburey] It would always have 6.
> In the 20-byte header, what are the units of the "Signal strength" and
> "Noise strength" fields, or are they just unitless numbers with no
> significance other than "larger means stronger"?
>
[emburey] Yes, 'signal strength' is unitless ranging between 0-100. Whereas,
'noise strength' is hard-coded; always 0.
> Are "Time secs" and "Time usecs" the "MAC timestamp" (Time Synchronization
> Function)?
[emburey] Yes, they come from time sync routines.
(In reply to comment #3)
> Joerg Mayer and I have checked in some changes to handle some of this; we
> still want answers to the earlier questions, and want a 55-byte header
> capture file (pcap/pcap-ng, *Peek, anything readable by Wireshark).
Pls let me know, if the recently added captures would be enough.
(In reply to comment #4)
> The decoding of the legacy header seems to be incorrect wrt
> timesec/timeusec. My legacy trace spans ~180s but the seconds value remains
> at 4. My best guess might be a 3 byte seconds and a 3 bytes useconds value -
> but even that didn't fit too well.
This is from a 64-bit get-time. So I think the 4-byte each, should work as
expected.
(In reply to comment #5)
> ...and, in the capture you made available, the "microseconds" value is >
> 1,000,000.
>
> Might those fields actually be a 64-bit count of microseconds?
Yes, like said in reply #4.
You are receiving this mail because:
- You are watching all bug changes.
