On Jun 27, 2018, at 2:28 AM, David Mirabito <[email protected]> wrote:
> 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. If, in some cases, it's reasonable to treat a time other than the one supplied by the capture mechanism as the "real" time stamp for the packet, a better mechanism should be provided. > It was pointed out to me today that previous dissectors may have previously > copied-by-value the old abs_ts, say for request/response latency > measurements. We're open to other alternatives (such as hooking at the > wiretap level and setting abs_ts nice and early?). This is somewhat > orthogonal to subnanos as we'd also like to do this for the basic ns > timestamps without requiring users to pre-process their tracefile to promote > our timestamps into the packet header for consumption by standard tools. 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. I'm assuming that your devices do not directly write out pcap or pcapng files but, instead, append a trailer to packets and forward the packets to be captured by another machine, so that the capture mechanism adds its own time stamp (as the mechanisms supported by libpcap/WinPcap/Npcap do, and as do the capture mechanisms used by other sniffers do as well). ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
