[Winpcap-users] FW: [Wireshark-users] FW: Dumpcap timestampdiscrepancy

[Gianluca Varenni]

What happens is that the WinPcap driver synchronizes with the system clock 
when you start the capture, and then uses the timestamps returned by 
KeQueryPerformanceCounter, which represent the number of 100ns ticks since 
boot time. Such clock doesn't get resynchronized when your machine 
synchronizes its clock on the network with NTP or similar systems.

If you accept a timestamp precision in the order of some milliseconds, the 
workaround is to switch the timestamping mode to the system time, which has 
a granularity in the order of 10-15milliseconds.

This can be done by modifying a registry key:
       HKLM\System\CurrentControlSet\Services\NPF\TimestampMode
  Possible values are
   * 0 (default) -> Timestamps generated through KeQueryPerformanceCounter,
          less reliable on SMP/HyperThreading machines,
          precision = some microseconds
   * 2 -> Timestamps generated through KeQuerySystemTime,
   more reliable on SMP/HyperThreading machines,
          precision = scheduling quantum (10/15 ms)
   * 3 -> Timestamps generated through the i386 instruction RDTSC,
          less reliable on SMP/HyperThreading/SpeedStep machines,
          precision = some microseconds

After that you need to restart the npf service (or reboot your machine).

Have a nice day
GV






----- Original Message ----- 
From: "Phil Paradis" <Phil.Paradis at unitedtote.com>
To: <winpcap-users at winpcap.org>
Sent: Wednesday, April 15, 2009 11:58 PM
Subject: [Winpcap-users] FW: [Wireshark-users] FW: Dumpcap 
timestampdiscrepancy


>I was referred here from the wireshark-users list; here's the original 
>post:
>
> 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
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users