On Nov 28, 2011, at 2:02 PM, Andy Fingerhut wrote:
> libpcap has had support for pcap ng files since early 2010. Such
> files can contain timestamps with resolutions more precise than
> microseconds. From my reading of the code, it appears that when
> libpcap reads from such a file, it converts the fractional time values
> to units of microseconds, since that is what a struct timeval is
> documented to contain in its tv_usec field.
Yes - that's a requirement for source and binary compatibility.
> A pcap_t *p created by any of the pcap_open_* calls can be used as an
> argument to the new function:
>
> int pcap_set_tv_usec_resolution(
> pcap_t *p, int tv_usec_resol);
How about
a pcap_t can be used as an argument to the new function
int pcap_allow_max_resolution(pcap_t *p)
which returns the reciprocal of the highest time-stamp resolution
possible on that pcap_t, and causes the fraction part of the timestamp to be in
units of that resolution.
This means that existing programs, which don't use that API, get microsecond
resolution, while new programs that use that API get, for example, nanosecond
resolution if the capture device (for live captures) or file format (for
savefiles) offers it, and microsecond resolution otherwise. (It could also
support intermediate resolutions.)
That way if a device/mechanism doesn't support nanosecond resolution, or a file
being read doesn't offer that resolution, you don't get that resolution, and
don't then end up, for example, displaying time stamps with a bunch of
meaningless extra 0's in the fraction-of-a-second part or writing a file that
claims to provide higher resolution time stamps but doesn't really do so.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
