Hi, I am currently inspecting 802.11 beacon frames captured by tcpdump. There are two timestamps associated with each beacon frame. The first one is the timestamp embedded in the beacon frame which represents the time the beacon was sent. The second one is the local timestamp that tcpdump tags the received beacon with. Now if I examine two consecutive beacons, and subtract each of the timestamps types from each other, I see a slight difference in the results. For example, the difference between the timestamps embedded into the beacon might be 100.123 milliseconds, while the difference between the receiving sides stamps might be 100.323 milliseconds. I am now wondering where this difference of a couple of hundred microseconds may result from. Could it simply be the inaccuracy/drift of the two clocks at sender and receiver side? Note that for capturing the packets using tcpdump, I realize there is a -j to choose timestamps generated by the host or the network adapter. I noticed this deviation in times with both -j host as well as -j adapter. Thanks a lot for your help. asked 29 Jul '15, 06:51  madmax1 |
2 Answers:
Read the following link: https://www.wireshark.org/lists/wireshark-dev/201203/msg00168.html Basically you are looking at 2 different timestamps:
Make sense? answered 29 Jul '15, 07:19  Amato_C showing 5 of 7 show 2 more comments |
To which tcpdump documentation are you referring here? The tcpdump man page on my machine says which says nothing about it being the time the first bit of the packet was received" - it says it was “the time the kernel first saw the packet”, which could be an arbitrary amount of time after the point at which the first bit of the packet was received by the hardware - as it also explicitly says, “No attempt is made to account for the time lag between when the Ethernet interface removed the packet from the wire and when the kernel serviced the ‘new packet’ interrupt.” (because there’s no way that tcpdump or libpcap can make such an attempt - the duration of that time lag simply isn’t available to it!). And even that’s not 100% accurate - the kernel might execute some code after it sees the packet but before it applies the time stamp. And, yes, there will definitely be non-deterministic delays between the time “first bit of the MPDU [arrives] at the MAC” and the time the kernel time-stamps the packet. So, if you want time stamps more closely tied to the time at which the packet arrived at the adapter, you would want If I run tcpdump with edited 29 Jul ‘15, 09:43 Hi Guy Harris, thanks for your answer. I was actually referring to the pcap-tstamp(7) man page, which is referred to in the tcpdump man page. It can be found here: http://www.tcpdump.org/manpages/pcap-tstamp.7.html It says “Some capture devices on some platforms can provide time stamps for packets; those time stamps are usually high-resolution [..] and are usually applied to the packet when the first or last bit of the packet arrives” I also checked for the warning that you described, however my adapter seems to support providing timestamps, I am not getting this warning. It is also listed as supported timestamp type when checking for it with tcpdump -J (30 Jul ‘15, 01:19) madmax1 What version of the Linux kernel do you have, what version of libpcap is tcpdump using, and what type of Wi-Fi adapter are you capturing with and what driver does it use? Older versions of the Linux kernel didn’t allow userland to inquire what types of time stamping is available, so libpcap punts and says that host and adapter timestamps are available and relies on the kernel and driver to report errors - which they might not do. (30 Jul ‘15, 12:19) Guy Harris ♦♦ |
Hello Amato, thank you for your answer. I realize that the values of the timestamps are not related in any way. This is why I examine only differences between two timestamps for each type. I am trying to figure out the reason for the deviations between those differences. According to the tcpdump documentation, the receiver's timestamp is the time the "first bit of the packet was received", and should be highly accurate. Do you by chance know if there might be (non-deterministic) delays between the time "first bit of the MPDU [arrives] at the MAC" and the time "the first bit of the packet enters the air"? Thanks a lot
Which 2 time stamps are you examining in the packet? Can you provide the field name, or even better, provide a sample capture?
You can post your sample capture on Cloudshark or Google drive. Then we can examine the fields together.
Unfortunately, I cannot share the captures files, however I uploaded screenshots of two sample packets: https://drive.google.com/folderview?id=0B_QzbEVR4w8_fmZKUzdjSWV4eDJHSGI4aDdFNWVyOF84bzJRU05qek1OblhBdGRXd3pxQTA The first two stamps I examine are the ones in wireshark's Time column, generated by "tcpdump -j adapter". the difference is 102.437 milliseconds. The second set is the Timestamp field in the 802.11 management frame header. The difference calculates to 102.417 milliseconds. In total, there is a 20 microseconds deviation which I am trying to find the reason for. Note that this deviation varies for different pairs of consecutive packets. Thanks!
The difference between the time stamps you are comparing should never be the same. And in fact will probably always deviate between consecutive packets. Why? Let's examine how the time is generated for each field.
Time stamp from Wireshark's time column = This time can be viewed under Frame, Epoch Time. As stated in the link I provided above: "pcap gets the time stamp of a packet by mechanisms that return the time in UN*X format i.e. seconds and fractions of a second since January 1, 1970, 00:00:00 UTC, and the packets are, in most cases, time-stamped by the operating system's networking stack at some point in the packet's path up to userland, which could be a point after the packet arrives at the networking adapter." So this time is the arrival time of the packet at the adapter plus the additional time to process the packet.
Time stamp from the 802.11 management header = This time is defined in the IEEE 802.11-2012 specification, section 10.1.3.1: "A STA sending a Beacon frame shall set the value of the Beacon frame’s timestamp so that it equals the value of the STA’s TSF timer at the time that the data symbol containing the first bit of the timestamp is transmitted to the PHY plus the transmitting STA’s delays through its local PHY from the MAC-PHY interface to its interface with the wireless medium. So consider this the time the instance when the data hits with wireless medium (air).
So why don't they equal? It takes time for the data to traverse across the air. Remember one is the arrival time and the other is the transmitted time.
So why are there deviations between the consecutive packets? This could be due to a number of factors including how long it takes the receiver to process the data, if the medium was busy at the expected time of a Beacon transmission then the Beacon will be delayed (i.e., CSMA deferral)
Referring to the stamp in Wireshark's time column, I don't think they are generated by the OS in my case, since I use tcpdump's '-j adapter' flag. The packets should actually be stamped by the adapter before any processing is done on the receiver's end. I realize the stamps are still not equal, but I assume the packet's propagation time as well as PHY delays should not deviate between consecutive packets. I also considered CSMA deferral to be the reason for the deviations, but following 802.11's definition that you gave in 2., the stamp should be done "at the time that the data symbol containing the first bit of the timestamp is transmitted to the PHY [..]", so any deferrals should already be considered in the embedded TSF value.
@madmax1 = Before moving forward, I would like to have some agreement on certain points. Please tell me if you agree. 1. The "tcpdump -j" timestamp occurs when the WiFi frame is immediately received (i.e., no processing) at the adapter. 2. The timestamp in the 802.11 management header occurs when the WiFi frame is being transmitted on the PHY. 3. The tcpdump and management header timestamps should not equal due to propagation delay. 4. The timestamp in the 802.11 management header only occurs in the following WiFi frames: Beacons, Probe Responses and Time Advertisements frames (per the 802.11 specification). 5. Neither the tcpdump timestamp nor the 802.11 management timestamp are generated by Wireshark. The tcpdump timestamp is generated by the adapter, driver or kernel. The 802.11 management timestamp is part of the IEEE 802.11 specification and is generated by the WiFi adapter.
Depends on the value of the
-jargument and whether it actually takes effect. Note that failure to take effect is a warning, not an error, so do not use the fact that the capture starts as an indication that the-jargument applies to the capture.