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

[Phil Paradis]

Cool; I think that will work for us. We have a hard enough time getting people to tell us what day something happened, much less what time, so a few milliseconds here and there won't cause too many problems. The system logs we need to correlate with have only whole second resolution in any case.

Thanks,

--
Phil
________________________________________
From: winpcap-users-bounces at winpcap.org [winpcap-users-bounces at winpcap.org] On Behalf Of Gianluca Varenni [gianluca.varenni at cacetech.com]
Sent: Thursday, April 16, 2009 15:03
To: winpcap-users at winpcap.org
Subject: Re: [Winpcap-users] FW: [Wireshark-users] FW: Dumpcap  timestampdiscrepancy

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

_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users