Hi,
Even though I can't intelligently respond to the issue raised you might want to
contact the winpcap-users mailing list[1] as well, as they are more familiar
with the inner details of capture and know Wireshark as well.
[1] http://www.winpcap.org/contact.htm
Thanx,
Jaap
Phil Paradis wrote:
We have a sniffer running continuously in one of our facilities, capturing
data to/from a specific system. The box is running Windows XP Pro (SP-3) and
dumpcap is running as a service using srvany.exe. The clock on this system is
synchronized with the rest of the hosts on this network.
When left running for an extended period of time (weeks/months) it seems the
timestamps recorded in our captures slowly drift backwards. The timestamp
recorded in the filename as each new file is created matches the system time
relatively well (from observation; i.e. when BAT_99717_20090415222212.cap was
created, the system clock showed 10:22 PM.) however the packet timestamps
within the file are off by a significant amount. (In this particular example,
the first packet in the file has a timestamp of 22:16:18, nearly 6 minutes
earlier than when the file was opened.)
Stopping and restarting the service seems to correct this; after a restart,
the first packet in the new file had a timestamp closely matching the
timestamp in the filename (and the system time.)
What documentation I can find seems to indicate that WinPCap obtains the
timestamp from the system as packets are received; since the system itself
reflects the correct time, the discrepancy we are seeing strikes me as rather
odd. Has anyone else seen this or know what could cause it?
The command line used to start Dumpcap from SrvAny is:
-i \Device\NPF_{ABF2B612-CEAA-46CE-BEEB-D401F37BAEFF} -B 8 -b filesize:5000
-b files:5000 -w c:\sniff\BAT.cap
The version of Wireshark we are using is 1.0.0, with WinPcap 4.0.2. (Yes, I
know it's old. We can easily update to the latest version, but I figured I'd
ask anyway in case anyone knows of a different cause for this issue.)
Thanks,
-- Phil