Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: [Wireshark-users] recorded time in pcap file drifts from system time

From: Stuart Kendrick <skendric@xxxxxxxxx>
Date: Fri, 06 Apr 2012 17:06:42 -0700
Perhaps there is no fix for this ... but I figured I'd ask.

Absolute time, as recorded in the .pcap file, tends to drift from system
time.

Why do I believe this?  Because I tend to use dumpcap plus the ring
buffer options, when I'm trying to capture an intermittent issue.

C:\temp>type capture.bat
dumpcap -i 4 -b filesize:50000 -b files:8000 -w clients.pcap -s 256 -f
"ip host a.b.c.d or ip host e.f.g.h or ip host i.j.k.l"
C:\temp>

I set this particular capture going Tuesday afternoon (today being
Friday).  The intermittent incident in question occurred a few hours
ago.  I grab the relevant trace(s) and start poking through them.  I
have precise knowledge of when the incident occurred, due to log
messages from the relevant application.  But then I have to figure out
the 'time offset' between the 'Real Time' (all my machines are synced
via NTP, including the box hosting Wireshark), i.e. the time when my
application logged its error messages, and 'Wireshark Time'.

Had this occurred on Tuesday, I wouldn't have worried about this --
'Wireshark Time' starts off the same as system time on the machine
hosting it.  But as the days pass, 'Wireshark Time' and 'Real Time'
drift apart.

I capture this effect here:
client> cat mark-pings
#!/bin/sh
date
/bin/ping -c 1 server
date
/bin/ping -c 1 server
date
/bin/ping -c 1 server
date
/bin/ping -c 1 server
date
client>./mark-pings
/var/tmp> ./dome
Fri Apr  6 16:32:28 PDT 2012
PING server.company.com 56(84) bytes of data.
64 bytes from server.company.com: icmp_seq=1 ttl=252 time=0.441 ms
[...]
Fri Apr  6 16:32:28 PDT 2012
PING server.company.com 56(84) bytes of data.
64 bytes from server.company.com: icmp_seq=1 ttl=252 time=0.167 ms
[...]

 228708 16:33:05.720886 439.295024  209.320809  102   client     server ICMP   Echo (ping) request  id=0x722c, seq=1/256, ttl=61
 228709 16:33:05.721214 439.295352  0.000328    102   server     client ICMP   Echo (ping) reply    id=0x722c, seq=1/256, ttl=255
 228710 16:33:05.723651 439.297789  0.002437    102   client     server ICMP   Echo (ping) request  id=0x742c, seq=1/256, ttl=61
 228711 16:33:05.723677 439.297815  0.000026    102   server     client ICMP   Echo (ping) reply    id=0x742c, seq=1/256, ttl=255
[...]

So ... doing a little arithmetic ...
	Client sent first ping at 16:32:28
	Wireshark saw that ping arrive at 16:33:05
	Thus, Wireshark Time is 37 seconds ahead of Real Time.

And then I poke through the trace for the time when the application logged the error, subtract 37 seconds, and start paying attention.

But, there are various ways in which this work-around causes discomfort ... like, I need to calculate the delta between the two times 
fairly soon after the event ... the longer I wait (hours, days), the less confidence I have in the calculation ...

Is there a way around this?  I suppose I could stop and restart my capture every few hours, to give Wireshark a chance to grab Real Time.  Other thoughts?

Wireshark 1.6.6
windows 7 Enterprise SP1 64 bit

--sk

Stuart Kendrick
FHCRC