We're now a non-profit! Support open source packet analysis by making a donation.

Wireshark-dev: Re: [Wireshark-dev] pcap-ng support

From: "Gianluca Varenni" <[email protected]>
Date: Fri, 8 Feb 2008 15:58:02 -0800
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 
Have a nice day

----- Original Message ----- From: "Ulf Lamping" <[email protected]>
To: "Developer support list for Wireshark" <[email protected]>
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


I tried to spedify the timestamps better and renamed if_tsaccur into

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.)
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
[email protected]