Re: Sub-nanosecond timestamps

[David Mirabito <davidm () metamako com>]

> > This seems to work, although I haven't yet convinced myself that it's
> guaranteed to be safe to splat over fd->abs_ts from a trailer dissector.
>
> I would recommend against that.  There is one frame_data structure for
> every packet in a capture file, so reducing the size of that structure
> would reduce the memory consumption of Wireshark for a file, possibly by a
> significant amount of a large file; one way to reduce that size would be to
> have pinfo->abs_ts be what stores the absolute time stamp, and set it from
> the time stamp supplied by libwiretap.  That might require that the
> libwiretap code for some file formats keep their own time stamp tables, but
> at least most capture file formats would not require that.

I think I've conflated two things, which perhaps should be separate
discussions:
1. Handling <ns times. This would presumably add a field to some struct
somewhere, with the additional info coming from "somewhere".
2. Getting the time out of the trailer for use as "the time" that the rest
of the program knows how to handle. This could be done with the existing
precision support and as you mention could be done at capture time rather
than 'view in wireshark' time.

These are orthogonal, other than the fact that #2 is trivially extended as
a convenient source of extra precision with which to test #1.
I'm getting the impression that the "real" time generally is expected to
come from libwiretap, ie. be extracted from reading an erf/pcapng file.

I'll shelve discussion of trailers and "our" timestamps for now, and stick
to wireshark's internal handling of <ns times, wherever they may have come
from, and I take your point that perhaps wiretap should be doing the
promotion from trailer to "the" timestamp rather than doing so at
dissection time.
We currently have a post-processing script which puts our numbers into
.pcap[ng] headers so we can continue to use those for a while longer as a
vehicle to import them into Wireshark et al.


> Note that there are tools that process capture files and that don't have
> "shark" anywhere in their name; i.e., there are tools, including standard
> tools, that would not have their behavior changed by any changes to
> Wireshark.
> So either those other tools would need to check for the MetaWatch trailer
> and use the time stamp.
Agreed. For now we can assume some combination of capture / postprocess /
libwiretap have conspired to get finer time details into wireshark.

Cheers,
DavidM

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe