[Winpcap-users] Dumpcap timestampdiscrepancy after extended period of time

[nico de moor]

Hi,

We have several trace PC's (synchronized with NTP server) which are continuously capturing packets in our VOIP network, when we need to analyze a call we filter out these calls and want to merged them chronologically but the timestamps in the files do not match when the traces are running for an extended period of time due to the timestamp mode set to 'generated through KeQueryPerformanceCounter' - when we change the timestamp mode setting to 'generated through KeQuerySystemTime' the time is correct but due to the high amount of traffic in our network we have lots of packets with the same time stamp which is also not workable.

Is it possible to have the timestamp generated through PerformanceCounter but periodically updated (e.g. with creation of new file or once every hour) with the system time?

Br. Nico    


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>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
 		 	   		  
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20091218/fed42df5/attachment.htm