Wireshark mailing list archives
recorded time in pcap file drifts from system time
From: Stuart Kendrick <skendric () fhcrc org>
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 ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- recorded time in pcap file drifts from system time Stuart Kendrick (Apr 06)
- Re: recorded time in pcap file drifts from system time Guy Harris (Apr 06)
- Re: recorded time in pcap file drifts from system time Stuart Kendrick (Apr 07)
- Re: recorded time in pcap file drifts from system time Stuart Kendrick (Apr 09)
- Re: recorded time in pcap file drifts from system time Graham Bloice (Apr 09)
- Re: recorded time in pcap file drifts from system time Jaap Keuter (Apr 09)
- Re: recorded time in pcap file drifts from system time Stuart Kendrick (Apr 07)
- Re: recorded time in pcap file drifts from system time Guy Harris (Apr 06)