-
Notifications
You must be signed in to change notification settings - Fork 524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can Npcap use KeQuerySystemTimePrecise() if running on Windows 8 or later? #71
Comments
I am very much interested in this feature as I use npcap to sniff and timestamp traffic that will need to be correlated with other traffic captured on different hosts. NTP is used to keep system clocks synchronized. Can I submit a pull request with this change? |
As long as either
or
|
I think it may be possible using a combination of |
I am posting a little update here to answer the question in the title: yes, it is possible to use In the thread of #19 comments, @guyharris and I talked about the possibility to use the new precise time-of-day API as a single alternative to current time modes (mainly QPC and QST). Further changes to timestamping can be maybe discussed in a separate issue or into #46. |
So the first thing to do here might be to remove some undocumented time stamp types that might have been failed experiments at better supporting multiple CPUs with I have some cleanup to do on libpcap's timestamp types:
I'm also working on making the time stamp modes per-instance; I'll submit a pull request once that's done. (I'll probably wait until nmap/nmap#1829 is resolved; there's extra crud I won't have to worry about if it's resolved as "kill those old modes".) |
This mode uses KeQuerySystemTimePrecise if available. On Win7/2008R2, it falls back to KeQuerySystemTime, equivalent to TimestampMode 2. While this is not as precise as TIMESTAMPMODE_SINGLE_SYNCHRONIZATION, it at least does not drift from wall clock time in the same way. I believe the behavior (monotonic vs synchronized) is a more important distinction to preserve than the precision. Once we have per-capture-handle timestamp modes, we can probably have a feedback mechanism to inform the caller whether a timestamp mode is supported on the current platform. See nmap/nmap#1407
So should we have the default time stamp type, if the
That way, if the registry key isn't set, Windows 8 and later will default to a time stamp type that is 1) high resolution and 2) synchronized with the system time. If so, then, unless there's a compelling reason to use The only compelling reason I can think of would be performance, i.e. if On Windows 7, we could offer a choice between |
This would let Wireshark and tcpdump get high-precision times on Windows 8 and later without any source changes. |
OK, I've checked in the libpcap changes I used to test the new |
For now, we are having to run npcap in WinPcap-compatibility mode to support our legacy software. To use the TIMESTAMPMODE_QUERYSYSTEMTIME_PRECISE timestamping mode, I would need to set the HKLM\System\CurrentControlSet\Services\NPF\TimestampMode key or the HKLM\System\CurrentControlSet\Services\npcap\TimestampMode key? And do I set the value to 2 or 4? FWIW, I'm using Npcap OEM 1.10. Is it defaulted to the TIMESTAMPMODE_QUERYSYSTEMTIME_PRECISE value? |
Thanks everyone. I believe this was implemented a while back and so this issue can be closed. It's documented in the Npcap timestamp guide (which comes from libpcap). So it's available on a per-handle basis rather than being systemwide like with the old Winpcap registry entries. Some comments from @dmiller-nmap: The default is HIPREC_UNSYNCED, which uses KeQuerySystemTimePrecise once at the beginning of the capture, then uses KeQueryPerformanceCounter to stamp later packets based on CPU ticks. We call that TIMESTAMPMODE_SINGLE_SYNCHRONIZATION. The TIMESTAMPMODE_QUERYSYSTEMTIME calls KeQuerySystemTime for every packet, and was supported (registry entry for whole system) by WinPcap. Libpcap calls that PCAP_TSTAMP_HOST_LOWPREC. The new mode is TIMESTAMPMODE_QUERYSYSTEMTIME_PRECISE, which libpcap calls PCAP_TSTAMP_HOST_HIPREC, which calls KeQuerySystemTimePrecise for every packet. Both those last 2 do not drift from wall clock time, but may run forwards or backwards according to leap seconds, time zones, system time changes, etc. But the default is a monotonic (always increasing) clock. Both are needed in different situations. |
Somebody complained about packet time stamps drifting from system time with WinPcap on Windows 10.
WinPcap has, at least on 32-bit Windows, a registry parameter
HKLM\System\CurrentControlSet\Services\NPF\TimestampMode
that controls how time stamps are generated:There also appears to be a setting of 1, the symbol for which in
time_calls.h
isTIMESTAMPMODE_SYNCHRONIZATION_ON_CPU_WITH_FIXUP
, and a setting of 99, the symbol for which isTIMESTAMPMODE_SYNCHRONIZATION_ON_CPU_NO_FIXUP
.It looks as if, on 64-bit Windows, the RDTSC version isn't supported.
From a quick look at the Npcap driver, it seems to behave similarly, although the NT
GET_TIME()
code went fromin WinPcap to
on Npcap - the mis-indentation of the
#endif
makes it less clear that modes 0 and 2 are still supported.If a mode were supported in which
KeQuerySystemTimePrecise()
were used, at least on Windows 8 (and its server variant) and later, that would provide a mode that 1) gives high-resolution time stamps and 2) doesn't drift from the system clock, although it might be more costly than usingKeQueryPerformanceCounter()
. (And if it's not more costly, it's probably the best mode on 64-bit Windows, given that RDTSC isn't being used.)Furthermore, given that there's now a
pcap_set_tstamp_type()
in libpcap, having the time stamp type be per-pcap_t
, rather than system-wide, might be useful. You'd offer a choice between:PCAP_TSTAMP_HOST
- this would useKeQuerySystemTime()
prior to Windows 8 andKeQuerySystemTimePrecise()
on Windows 8 and later, and would always be available (it's the default in libpcap);PCAP_TSTAMP_HOST_LOWPREC
- this would always useKeQuerySystemTime()
, and would be always be available;PCAP_TSTAMP_HOST_HIPREC
- this would always useKeQuerySystemTimePrecise()
, and would only be available on Windows 8 and later.If the other time stamp types are useful, we could add new
PCAP_TSTAMP_
types for them, and make them available only on Windows (thePCAP_TSTAMP_ADAPTER
types are available only on Linux - and they have a number of problems, not the least of which is that they give time as seconds since January 1, 1970, 00:00:00 TAI with at least some adapters; don't get me started on UN*X time stamps and leap seconds...).The text was updated successfully, but these errors were encountered: