I updated the document removing the reference to the UNIX time format and
removing the duplicated description of the if_tsresol field.
The new document is available at
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
Have a nice day
GV
----- Original Message -----
From: "Ulf Lamping" <ulf.lamping@xxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Tuesday, January 22, 2008 2:00 AM
Subject: Re: [Wireshark-dev] pcap-ng support
Gianluca Varenni schrieb:
I just uploaded a new version of the spec here
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat_ts.html
I tried to spedify the timestamps better and renamed if_tsaccur into
if_tsresol.
Let me know if you think it makes more sense.
Yes it does, however still can be improved IMHO :-)
I would refer to "Unix time" only if it really represents the *seconds*
til 1/1/1970 - and this isn't the case here. I wouldn't repeat the whole
if_tsresol description here (to avoid duplication and the field
description is already pretty long).
"Timestamp (High) and Timestamp (Low): high and low 32-bits of a 64-bit
quantity representing the timestamp. The timestamp is a single 64-bit
unsigned integer representing the number of units since 1/1/1970. The
unit of this field is specified by the 'if_tsresol' option (see Figure 9
(Interface Description Block format.)
<http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat_ts.html#formatidb>)
of the Interface Description block referenced by this packet. E.g. if
the value of 'if_tsresol' is 9, the unit is 10^-9 nanoseconds, so the
64-bit timestamp is simply the number of nanoseconds since 1/1/1970.
Please note that differently from the libpcap file format, timestamps
are not saved as two 32-bit values accounting for the seconds since
1/1/1970 and microseconds of the day. They are a single 64-bit quantity
saved as two 32-bit words."
I guess in future we will need a new field in IDB, something like
"if_tsformat" (or so) to specify libpcap like or completely different
timestamp formats - I guess that's the same conclusion Stephen Donelly
may have. But we can do this later when the problem really arises ;-)
Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev