Request to be able to query the current pcap time

[nikodul]

Would it be possible to query the current time (with a non-blocking call) of the time source that is used to assign the packets timestamps?
Once the time stamp type is selected with pcap_set_tstamp_type, it would be nice to be able to query the current time of the pcap time source, without having to wait for the first packet captured to get its timestamp (or the function may be called during capture, at any time between packets reception).

This would allow to synch other systems on the PCAP source time, even in case no packets are captured (when the network has low or no traffic).

I didn't find at method to call for this.
Do you see any workaround? (e.g. inject a dummy packet, and re-capture it to get its pcap timestamp?)

[guyharris]

Would it be possible to query the current time (with a non-blocking call) of the time source that is used to assign the packets timestamps?

(Presumably this is for sources other than PCAP_TSTAMP_HOST, PCAP_TSTAMP_HOST_LOWPREC, and PCAP_TSTAMP_HOST_HIPREC, as the calls to get that current time are the standard OS "what time is it now?" calls.)

I didn't find at method to call for this.

There is no current API in libpcap to fetch that.

For PCAP_TSTAMP_HOST_HIPREC_UNSYNCED, which is currently only supported on Windows, the Npcap driver, the packet library, and libpcap could be modified to implement such an API.

For PCAP_TSTAMP_ADAPTER and PCAP_TSTAMP_ADAPTER_UNSYNCED, if the adapter provides a way to query its clock and If the OS and driver provides a mechanism to query that clock, libpcap could be modified to implement such an API. That might not be the case on all platforms that could support those, and might not be the case on any of them. It also might not be possible on all adapters.

Do you see any workaround? (e.g. inject a dummy packet, and re-capture it to get its pcap timestamp?)

I suspect that would work for PCAP_TSTAMP_HOST_HIPREC_UNSYNCED.

For the PCAP_TSTAMP_ADAPTER* types, that would only work if the networking stack and capture mechanism, when adapter time stamping is selected, time stamp outgoing packets in the adapter. If the adapter time stamps packets at the time it receives them, that might be somewhat blocking (as the host would have to wait until the adapter said "OK, this packet is time stamped" - which might really be one indication delivered for a batch of outgoing packets). If it time stamps them at the time they're put on the wire/air, it would be even more blocking.

(Note also that any "what time does this clock have?" call - including "what's the host clock's time?" - return the value the clock had at some time between the point at which the call was made and the point at which the call returned.)