While analyzing a network interface using WireShark, which device’s timestamp is recorded

networkingwireshark

OK, this may seem trivial but due to the nature of testing required for my application, I need to get precise timestamps.

I am using WireShark to analyze packets.

Suppose I have a network with 2 hosts h1 and h2.

h1 and h2 are connected with each other via interfaces h1-eth0 and h2-eth0 respectively.

When I run Wireshark on host h1 to capture the interface h1-eth0, can I be absolutely certain that the timestamps being recorded correspond to the system time of host h1?

Although this should be the case, besides your useful remarks, it would really help if I could get a link citing the same (this is just so I may formalize my application).

[CONCLUDING REMARKS]: manpage for the tcpdump's timestamp module. PCAP-TSTAMP.

NOTE: The man page is written by Guy Harris himself. 🙂

Quoting:

When capturing traffic, each packet is given a time stamp representing, for incoming packets, the arrival
time of the packet and, for outgoing packets, the transmission time of the packet. This time is an approx‐
imation of the arrival or transmission time.

Best Answer

Suppose I have a network with 2 hosts h1 and h2.

h1 and h2 are connected with each other via interfaces h1-eth0 and h2-eth0 respectively.

When I run Wireshark on host h1 to capture the interface h1-eth0, can I be absolutely certain that the timestamps being recorded correspond to the system time of host h1?

If you run Wireshark (or tcpdump or WinDump or snoop or Microsoft Network Monitor or Sniffer or OmniPeek or Commview or any other sniffer; the answer is not specific to Wireshark...) on host h1, the packets are coming from a capture mechanism in the networking stack of the OS running on host h1, and the time stamps correspond either to the time at which the packet was time-stamped by that networking stack (i.e., timestamped by host h1) or, in some cases, by the time at which the packet was stamped by the network adapter plugged into host h1 (or, on HP-UX, by the time at which libpcap read the packet from the networking stack on host h1, as HP-UX's capture mechanism doesn't itself time-stamp packets).

So the time stamp is closest to the host time on the machine on which you're running the sniffer program. It does not necessarily correspond to the exact time, down to the microsecond or nanosecond, at which the packet arrived at host h1's network adapter (unless the network adapter is time-stamping the packets; most don't support that). There may be a delay between the time at which the packet arrived at the networking adapter and the time at which it's time-stamped, that could included:

  • the time between the arrival of the packet and the signaling of an interrupt to tell the host that a packet has arrived (there isn't necessarily an interrupt signaled for each packet);
  • the time between the signaling of the interrupt and the host responding to it;
  • the time between the host responding to the interrupt and the packet being handed to the capture mechanism;
  • the time between the packet being handed to the capture mechanism and being time-stamped by the capture mechanism.

So if by "can I be absolutely certain that the timestamps being recorded correspond to the system time of host h1?" you mean "can I be absolutely certain that the timestamps being recorded correspond, with high precision, to the system time of host h1 at the time the packet arrived?", the answer is "not necessarily, even if you're running on host h1". It's closer to the time at which the packet arrived on host h1 than to the time at which the packet was sent from host h2, but if you need to know high-precision and high-accuracy time stamp values, you'll need either specialized hardware that time-stamps packets on the networking adapter or a specially-tuned receive code path (which may mean that you'd have to hack interface driver code and networking stack code; such a specially-tuned receive code path is not, for example, a configuration option for a Linux kernel or a registry option for a Windows kernel).

(BTW, Mitch's answer applies only on Windows; there's no such routine as KeQuerySystemTime on my personal computer, for example - the packets are time stamped with a value returned by a routine named microtime.)

Related Topic