Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I noticed that there is a --time-stamp-type option for dumpcap. I've tried listing supported timestamp types on my Dell XPS running Windows 10 but get nothing listed.

Currently, Linux is the only OS on which time stamp types other than the default "system time, at whatever precision you get" are supported.

Is there a way to force npf to periodically check the system clock and resync its internal timestamp?

No, but there's a way to get WinPcap to use the system time to time stamp packets; the advantage is that the time stamps don't drift relative to the system clock and the disadvantage is that the call the driver makes to get the system clock value (KeQuerySystemTime()) gives system clock interrupt precision (i.e., it fetches a system variable that's updated on every clock interrupt), with clock interrupts happening at intervals in the millisecond range, so packet time stamps aren't very high-resolution.

(Given that the time between the arrival of the last octet of the packet on the network adapter and the time-stamping of the packet in the network stack is variable, high-resolution host time stamps may not be as useful as some might want. This also applies to high-resolution time stamps using the x86 time stamp counter and Windows kernel performance counter. BTW, the x86 time stamp counter is only available on 32-bit x86 - when the code was written, at least, the compiler didn't support in-line assembler for 64-bit x86, so they didn't bother implementing that.)

There's a global setting in the registry that controls how the time stamps are generated.. Set it to 2 to get time stamps from the system clock.

Does npcap address the issue of arrival time drift?

No, it behaves just like WinPcap, including the registry setting. I've filed an npcap issue suggesting that they support the libpcap time-stamp-type APIs and default to "host time stamp" just as happens with packet capture on UN*Xes (and offer, for what it's worth, a high-resolution time stamp using the system clock on Windows 8 and later - the kernel interface for that isn't available prior to Windows 8).

The

I noticed that there is a --time-stamp-type option for dumpcap. I've tried listing supported timestamp types on my Dell XPS running Windows 10 but get nothing listed.

Currently, Linux is the only OS on which time stamp types other than the default "system time, at whatever precision you get" are supported.

Is there a way to force npf to periodically check the system clock and resync its internal timestamp?

No, but there's a way to get WinPcap to use the system time to time stamp packets; the advantage is that the time stamps don't drift relative to the system clock and the disadvantage is that the call the driver makes to get the system clock value (KeQuerySystemTime()) gives system clock interrupt precision (i.e., it fetches a system variable that's updated on every clock interrupt), with clock interrupts happening at intervals in the millisecond range, so packet time stamps aren't very high-resolution.

(Given that the time between the arrival of the last octet of the packet on the network adapter and the time-stamping of the packet in the network stack is variable, high-resolution host time stamps may not be as useful as some might want. This also applies to high-resolution time stamps using the x86 time stamp counter and Windows kernel performance counter. BTW, the x86 time stamp counter is only available on 32-bit x86 - when the code was written, at least, the compiler didn't support in-line assembler for 64-bit x86, so they didn't bother implementing that.)

There's a global setting in the registry that controls how the time stamps are generated.generated. Set it to 2 to get time stamps from the system clock.

Does npcap address the issue of arrival time drift?

No, it behaves just like WinPcap, including the registry setting. I've filed an npcap issue suggesting that they support the libpcap time-stamp-type APIs and default to "host time stamp" just as happens with packet capture on UN*Xes (and offer, for what it's worth, a high-resolution time stamp using the system clock on Windows 8 and later - the kernel interface for that isn't available prior to Windows 8).

The