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.
Default timestamping mode based on KeQueryPerformanceCounter() causes a drift from the system clock.
KeQuerySystemTime() does not give me the precision I want, so I really look forward to the possibility of using KeQuerySystemTimePrecise().

Can I submit a pull request with this change?

Can I submit a pull request with this change?

As long as either

1. it somehow arranges to avoid using KeQuerySystemTimePrecise() on Windows Vista and Windows 7, whether that can be done with a single driver that checks the version of the kernel in which it's running or must be done by building two versions of the driver and installing the appropriate driver based on the OS version on which it's being installed (I suspect the answer is that two versions will be required)

or

2. the Npcap developers are willing to drop support for Windows Vista and Windows 7.

a single driver that checks the version of the kernel in which it's running

I think it may be possible using a combination of RtlIsNtDdiVersionAvailable() and MmGetSystemRoutineAddress(). It is worth a try.

I am posting a little update here to answer the question in the title: yes, it is possible to use KeQuerySystemTimePrecise() when running on Windows 8 or later, instead of the imprecise KeQuerySystemTime().

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).
After some thinking, I would like to propose to merge #19. It is a single call replacement that will not break existing application using npcap time mode settings (whether they are officially documented or not) and will provide greater precision on Windows 8 and later.
Microseconds precision and coherency with a wall clock is a much-needed requirement for distributed monitoring.

Further changes to timestamping can be maybe discussed in a separate issue or into #46.
What do you think? 😉

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 KeQueryPerformanceCounter(); given that Nmap is either Vista-and-later or Windows 7-and-later, where I think KeQueryPerformanceCounter() ensures cross-CPU consistence, those modes may no longer be necessary. I've filed nmap/nmap#1829 on that.

I have some cleanup to do on libpcap's timestamp types:

• add PCAP_TSTAMP_HOST_HIPREC_UNSYNCED and use that for TIMESTAMPMODE_SINGLE_SYNCHRONIZATION, which isn't synchronized with the host OS's clock;
• change the definition of PCAP_TSTAMP_HOST_LOWPREC to be synchronized with the host OS's clock, and use that for TIMESTAMPMODE_QUERYSYSTEMTIME
• change the definition of PCAP_TSTAMP_HOST_HIPREC to be synchronized with the host OS's clock, so that we can use it for a new TIMESTAMPMODE_QUERYSYSTEMTIMEPRECISE mode.

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".)

So should we have the default time stamp type, if the HKLM\System\CurrentControlSet\Services\NPF\TimestampMode registry key is absent, be:

• TIMESTAMPMODE_SINGLE_SYNCHRONIZATION if KeQuerySystemTimePrecise() isn't available;

• TIMESTAMPMODE_QUERYSYSTEMTIMEPRECISE if KeQuerySystemTimePrecise() isn't available is available?

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 TIMESTAMPMODE_SINGLE_SYNCHRONIZATION or TIMESTAMPMODE_QUERYSYSTEMTIMErather thanTIMESTAMPMODE_QUERYSYSTEMTIMEPRECISE, perhaps on Windows 8 and later there's no need to offer a choice of time stamp types through the pcap API. Most if not all UN\*Xes currently do the equivalent of TIMESTAMPMODE_QUERYSYSTEMTIMEPRECISEwith kernel APIs that provide high-resolution time stamps - and that are used forgettimeofday()`, so they are inherently synchronized with the system time.

The only compelling reason I can think of would be performance, i.e. if KeQuerySystemTimePrecise() is sufficiently more expensive than KeQuerySystemTime() or KeQueryPerformanceCounter() somebody might want to be able to use one of the latter, if, in the first case, they didn't care about high precision or, in the latter case, they didn't care about being synchronized with the system clock.

On Windows 7, we could offer a choice between TIMESTAMPMODE_SINGLE_SYNCHRONIZATION and TIMESTAMPMODE_QUERYSYSTEMTIME. Windows 7 is out of support, though, so I'm not sure to what extent supporting that in the pcap API, rather than at a system-wide level via the registry key, would be worth the effort. It might have the advantage of reducing the number of systems having the registry key set; that would mean that, with my proposal above, those systems would automatically switch to TIMESTAMPMODE_QUERYSYSTEMTIMEPRECISE if upgraded to Windows 10.

So should we have the default time stamp type, if the HKLM\System\CurrentControlSet\Services\NPF\TimestampMode registry key is absent, be:

• TIMESTAMPMODE_SINGLE_SYNCHRONIZATION if KeQuerySystemTimePrecise() isn't available;
• TIMESTAMPMODE_QUERYSYSTEMTIMEPRECISE if KeQuerySystemTimePrecise() isn't available is available?

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.

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 PacketGetTimestampModes() code as the-tcpdump-group/libpcap@b75571b. Backport those to Npcap's libpcap code and give that a try on Windows 10, using tcpdump.

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.