[FR] Support for `CLOCK_MONOTONIC_RAW` for packet timestamps

[fivlao]

Would it be possible to add support for using CLOCK_MONOTONIC_RAW — or optionally all of the monotonic clock types (CLOCK_MONOTONIC, CLOCK_MONOTONIC_COARSE, CLOCK_MONOTONIC_RAW) — so that the timestamp stored in pcap_pkthdr->ts represents the time elapsed since the system boot time, rather than the wall-clock time?

This would be useful in cases where:

• Wall-clock time can jump backwards or forwards (NTP adjustments, manual time changes),
• Monotonic timestamps are required for precise packet timing or latency measurements,
• Raw hardware time is preferred, without NTP corrections (CLOCK_MONOTONIC_RAW).

---

✅ Goal:
Have packet timestamps (pcap_pkthdr->ts) generated using a monotonic clock source instead of the system clock.

[guyharris]

Time stamps for captured packets come from the OS's clocks or from network adapter clocks, not from libpcap itself.

This means that this will require different changes for different platforms, and whether it can be done depends on the platform.

A quick look at the time stamping page of the Linux kernel networking documentation does not seem to indicate that there's any way to request arbitrary CLOCK_ clock types in time stamps. Changing that would require a Linux kernel change.

Another Linux option might be to have the packet filtering done by an eBPF program that also sets a time stamp for the packet; it looks as if it might allow fetching monotonic clocks of at least some sort. That would be a significant amount of work, however.

The FreeBSD documentation for the BPF capture mechanism allows the type of time stamping to be specified; it includes monotonic time stamps hat count the time since the system was booted. It offers:

• BPF_T_MICROTIME_MONOTONIC and BPF_T_NANOTIME_MONOTONIC, which always query the system clock, returning microsecond-precision or nanosecond-precision time;
• BPF_T_MICROTIME_MONOTONIC_FAST and BPF_T_NANOTIME_MONOTONIC_FAST, which don't always query the system clock and thus have, the precisions nonwithstanding, only clock-tick resolution.

None of the other *BSDs, including CupertinoBSD, appear to have anything of that sort.

KeQueryPerformanceCounter() could, I think, be used to provide a monotonic high-resolution time stamp in Npcap's NPF driver on Windows.

[infrastation]

Would using the network adapter's timestamp do the job? Some purpose-built capture cards have their own hardware clock, which may or may not be monotonic depending on the hardware capabilities and configuration.