Support timestamp method selection by capture handle rather than registry key

[fyodor]

Operating systems have various timestamp methods available with differing tradeoffs between granularity, accuracy, precision, efficiency, etc.

Npcap has an undocumented legacy method (inherited from Winpcap) for choosing this on a system-wide basis using TimestampMode registry key. It can be set to "0", "2", or "3":

• 0 is the default and uses KeQueryPerformanceCounter. This provides great precision (some microseconds) but is less reliable on SMP/HyperThreading machines since it doesn't return monotonic values across multiple CPUs.
• 2 uses KeQuerySystemTime instead, which is more reliable on SMP/HyperThreading machines, with a precision of a scheduling quantum (10/15 milliseconds)
• 3 uses the i386 RDTSC instruction. This is also less reliable on SMP/HyperThreading/SpeedStep machines and has a precision of some microseconds.

The registry location for this key depends on whether you are using Npcap native mode or Winpcap compatible:

• HKLM\System\CurrentControlSet\Services\npcap\Parameters\TimestampMode if using Npcap native API mode (npcap driver)
• HKLM\System\CurrentControlSet\Services\npf\Parameters\TimestampMode if using Winpcap compatible mode (npf driver)

It is probably best to just set both. Also note that even the Winpcap compatible location is a bit different than what Winpcap uses (which is HKLM\System\CurrentControlSet\Services\NPF\TimestampMode).

We have verified that this feature works with Npcap 0.9983, but we haven't officially documented it because setting the timestamp mode system-wide is not a great approach. It could cause issues if multiple applications are using Npcap and each wants a different mode.

The better method that we might actually want to officially support uses the per-capture handle timestamp option as described here. That describes the options available on several platforms, but we don't offer any non-default options through this API on Windows (Npcap). But we might, if we see demand for it. We created this issue both to document the current situation and also so folks can comment if the normal default mechanism doesn't work well for them. Please also note what you would prefer and why. The more well-supported requests we get, the more we can prioritize this issue. We don't waste time implementing a feature that nobody seems to want. And, at least for our Nmap Security Scanner, the default timestamp methods seem to be working well enough for us.

[fyodor]

Just as a data point, I was conversing with one Npcap user today who is now using mode "2" because they want the monotonic data.

[guyharris]

See also issue nmap/nmap#1407 "Can Npcap use KeQuerySystemTimePrecise() if running on Windows 8 or later?"

[guyharris]

And note that the set of timestamp types can be expanded if none apply to the modes Npcap can offer. The legacy WinPcap modes are all "host" modes, so they would be PCAP_TSTAMP_HOST_ modes.

[guyharris]

So the next step would be to have a packet.dll interface to get a list of all the supported TIMESTAMP_ modes for a given handle. (Currently, it's system-wide, rather than per-adapter, but if Microsoft ever offers a way to get adapters that have their own clocks to provide time stamps to NDIS filter drivers, it could become per-adapter, so let's make it per-handle.)

Then the next step would be to add support for pcap_list_tstamp_types() and pcap_set_tstamp_type() to pcap-npf.c.

Note, however, that, on Windows 8 and later, TIMESTAMPMODE_QUERYSYSTEMTIME_PRECISE is probably what almost all, if not all, users would want; it offers high-resolution time stamps synchronized with the system clock, with the only potential disadvantage being performance, if KeQuerySystemTimePrecise() is sufficiently slower than either KeQuerySystemTime() (for mode 2's low-resolution time stamps synchronized with the system clock) or KeQueryPerformanceCounter() (for mode 0's high-resolution time stamps not synchronized with the system clock).

Offering a choice for Windows 7 might be worthwhile, as you can't get both high resolution and synchronization with the system clock, so you'd have to choose which you want - assuming the now-supported-only-maybe-by-extra-long-term-support-with-Microsoft Windows 7 is worth adding that. (Note that Wireshark currently has no way to request different time stamp types from the GUI, so that would need to be added. tcpdump and dumpcap support specifying the time stamp type.)

[dmiller-nmap]

Since timestamp method selection is already available per capture handle, I'm closing this issue. The idea for getting a list of timestamp modes via ioctl is #174

Regarding "TIMESTAMPMODE_QUERYSYSTEMTIME_PRECISE is probably what almost all, if not all, users would want," I think Nmap in particular would rather have all clocks monotonically increasing, since it's less important for us what time the wall clock said when a packet arrived as it is how long it has been since we sent the probe that elicited the response. Unfortunately, on all systems we use gettimeofday() for measuring time intervals, so QST is probably better for now, but nmap/nmap#180 may get fixed eventually :)