Wireshark · Wireshark-users: [Wireshark-users] System Clock Drift

["Capehart, Nolan" <Nolan.Capehart@xxxxxxxxxx>]

Version 1.2.0 (SVN Rev 28753)
 
Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and
contributors.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
 
Compiled with GTK+ 2.16.2, with GLib 2.20.3, with WinPcap (version
unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI
0.4.8,
with c-ares 1.6.0, with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4,
with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 15 2009), with
AirPcap.
 
Running on Windows Server 2003 Service Pack 2, build 3790, with WinPcap
version
4.1 beta5 (packet.dll version 4.1.0.1452), based on libpcap version
1.0.0,
GnuTLS 2.8.1, Gcrypt 1.4.4, without AirPcap.
 
Built using Microsoft Visual C++ 9.0 build 30729
 
----------------------------------
 
It appears to me that when a capture is started, and no other capture is
already running, then Wireshark records the correspondence between the
time-of-day reported by the OS and some other way that Wireshark keeps
track of time, and that this correspondence is used for recording the
time-of-day of each captured packet up until the time at which all
captures are halted. This can be illustrated by these steps:
 
1) Start a capture, with "Update list of packets in real-time", and with
the timestamps shown as time-of-day.
2) Display the system time clock.
3) Note that the timestamps on the newest packets agree with the system
clock.
4) Change the system time by a large amount.
5) Note that the timestamps on the newest packets no longer agree with
the system clock, as if the system clock had never been changed.
6) Start a new instance of Wireshark, and start a different capture.
7) Note that the timestamps on the newest packets on the second capture
also act as if the system clock had not been changed.
8) Stop both captures, but do not close Wireshark.
9) Start a new capture. Note that now the timestamps on the newest
packets agree with the modified system clock.
 
I believe this is a reasonable way to do this. However, this creates a
problem for me. I tend to run very long captures - perhaps a week long.
But after a week, my system clock has been adjusted to a time server so
much that I've lost the ability to correlate the Wireshark timestamps to
anything that strictly uses the system clock.
 
The only thought I've had is that I can use system-clock adjustment
software such as Tardis that logs every adjustment, and then I could
tediously figure out how different the system clock and the Wireshark
clock are at any point in time.
 
Well, I've also thought of an option in Wireshark to cause it to
more-closely track system time for situations such as this. Each time
the system clock adjusts, it would totally mess up the packet-to-packet
time delta, but it would be more useful to me.
 
Any thoughts?