[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

My thought is that this is related to the capture driver WinPCAP. You should 
address their mailing list.

Thanx,
Jaap

Capehart, Nolan wrote:
> 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?