Wireshark-users: [Wireshark-users] recorded time in pcap file drifts from system time
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
