Support for hardware timestamps

[kayoub5]

It would be nice if Npcap could support hardware timestamps.
See https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-ndis-packet-timestamping

[fyodor]

Hi @kayoub5. Thanks for opening the issue. This is definitely a feature we want to add, but we're waiting for it to be supported on more Windows devices first. While NDIS 6.82 is supported by up-to-date Windows 10 systems (it was added in 1809), I don't believe the hardware timestamping feature became available until Windows 11. That was just released in October. We're looking at whether we can possibly support NDIS 6.82 through a multi-version-capable driver rather than having to build a separate driver (for each architecture) for that.

[guyharris]

Note that two key capabilities, as seen on the "NDIS_TIMESTAMP_CAPABILITY_FLAGS structure" page on Microsoft Learn, required for this are the AllReceiveHw and AllTransmitHw - the point here is to provide hardware-generated time stamps for all packets, not just PTP packets; the purpose here isn't to implement PTP, it's to get time stamps that aren't shifted by interrupt latency for received packets, transmission latency for transmitted packets, networking stack delays, etc..

There's also AllReceiveSw and AllTransmitSw, but, while that may avoid some networking stack delays, it doesn't avoid interrupt/transmission latency.

I don't know whether either of them produce time stamps synchronized to the OS time stamp; there's a good chance that it doesn't. Given that the aforementioned "NDIS_TIMESTAMP_CAPABILITY_FLAGS structure" page suggests that, for software time stamps, the driver use KeQueryPerformanceCounter(), the software time stamps are probably not guaranteed to be synchronized with the system clock; hardware time stamps won't be synchronized unless the adapter's timer is kept synchronized, which it may well not be. As the pcap-tstamp man page indicates, libpcap supports "unsynchronized adapter-generated time stamps" as a time stamp type.

[hoene]

Is it time to reconsider this feature request?

[fyodor]

I'll also mention #737, which is another feature we could support if we build a driver with newer NDIS. That issue also discusses our current drivers and the pros and cons.

[fyodor]

Yeah it is looking more compelling to do the NDIS upgrade now that more systems are available which will support it. And from @guyharris notes above, it sounds like we could map it to an existing libpcap timestamp mode rather than having to make changes upstream. In fact, we'd probably be able to use the same Packet.dll regardless of whether the driver supports the timestamps or not. We'll bump up the priority on this one (although given that we just released Npcap 1.80 on Monday, the next release will likely be in 2025.

[fyodor]

During a discussion with @dmiller-nmap today, he brought up this interesting Windows NDIS capability which may allow us to build one highest-version driver and then determine what version to downgrade behavior to based on a runtime call at driver load. This could be a big improvement over our current system of shipping many Npcap drivers with different NDIS versions and then installing the best match based on a system's NDIS version.