Wireshark · Wireshark-dev: Re: [Wireshark-dev] Sub-nanosecond timestamps

[David Mirabito <davidm@xxxxxxxxxxxx>]

> 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