Ethereal-dev: Re: [Ethereal-dev] How to read/import and display capture files with 1ns timesta
Ulf Lamping wrote:
First of all, I (currently) don't need to capture in nanosecond resolution, reading/importing would be enough.
Yes, but currently Wiretap supplies time stamps in seconds/microseconds
form, so the nanosecond resolution is lost. One way not to lose that
would be to change Wiretap to supply seconds/nanoseconds time stamps
when reading a file; if you do that, you probably want to change it to
*accept* seconds/nanoseconds time stamps when *writing* a file, which
would mean if you used the standard Wiretap code to write the file when
capturing, it'd be translating the seconds/microseconds time stamps it
gets from libpcap into seconds/nanoseconds time stamps before calling
Wiretap, and, if it's writing to a standard libpcap file (which is
probably what we want for captures, so that the file can be read by
other tools that use libpcap format), it'd then have to translate those
back to seconds/microseconds time stamps.
Using a separate path for writing packets in live captures would avoid
that. That's the reason I mentioned the capture code path.
Having a look at the implementation, I've just added a new function (in my personal tree) to read the current timestamp resolution from wiretap (in the format provided by the NTAR spec, therefore the questions).
That'd be another way to do it, which would avoid the overhead referred
to before (although, as per my comments about radio headers, I'd still
eventually like to go with a separate path for writing packets in live
captures).
This way I'm now looking for a way to change the display to be corresponding to the file content.
Probably the best way to do that would be to convert time stamps to
nstime_t's in Ethereal and Tethereal at the time the packets are read
from Wiretap. You might also want to supply time stamp significant
figure information as well, so you don't, for example, display with 9
digits after the decimal point time stamps with only 6 significant
digits after the decimal point; unfortunately, pcap-NG has no option
time stamp precision - and I'm not sure any packet capture information
supplies the *true* resolution of time stamps.
Simply changing the magic value or DLT_ (or alike) would be enough, no further changes to the file format required.
As per other mail, the magic number is the thing to change; the time
resolution isn't connected with the type of link-layer header in the
capture, the latter being with the DLT_ specifies.
