On Nov 2, 2013, at 4:36 PM, "John Dill" <[email protected]> wrote:

>> On Nov 1, 2013 at 2:18:04 PM, Guy Harris <[email protected]> wrote:
>> 
>> What is the file format?  Where does it store the IRIG time stamps?
> 
> The file is NTAR (another name for pcap-ng?).

Actually, it's the name for a library that reads pcap-ng files; the official 
name for the file format is pcap-ng.

> The software stores the 64-bit IRIG timestamp in the Timestamp 
> (High)/Timestamp (Low) field of a Packet Block.

To quote the pcap-NG specification:

        o 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 way to 
interpret this field is specified by the 'if_tsresol' option (see Figure 9) of 
the Interface Description block referenced by this packet. Please note that 
differently from the libpcap file format, timestamps are not saved as two 
32-bit values accounting for the seconds and microseconds since 1/1/1970. They 
are saved as a single 64-bit quantity saved as two 32-bit words.

and therefore...

> It's injected into the packet stream from a 10-nanosecond resolution clock on 
> the capture board that is synchronized to an external IRIG-B timecode.  It's 
> used to synchronize the time of the packet stream with ARINC 429 and 
> MIL-STD-1553 data streams, which are also IRIG-B time coded.
> 
> IRIG-B is a time format that is simply a count of seconds since Jan 1 at 
> midnight UTC, not from 1970.
> 
>    +---------------------------------------------------------------+
>  0 |                    Block Type = 0x00000006                    |
>    +---------------------------------------------------------------+
>  4 |                      Block Total Length                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  8 |                         Interface ID                          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 12 |                        Timestamp (High)                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IRIG-B 
> Timestamp
> 16 |                        Timestamp (Low)                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...that's not a valid pcap-ng file.

Either get a new block type value for blocks containing an IRIG-B time stamp, 
or put a fractions-of-seconds-since-the-Epoch time stamp into the packets, get 
a new option value for IRIG-B time stamps, and put those into the Enhanced 
Packet Block as an option.

> Isn't the time column displayed based on the contents of Timestamp 
> (High)/Timestamp (Low)?

The time column is displayed based on the time stamp supplied by the Wiretap 
library (the library in the wiretap subdirectory).

Wiretap returns, and Wireshark and TShark expect, this time stamp to be a time 
stamp that is in the form of seconds since January 1, 1970, 00:00:00 GMT, and 
nanoseconds since that second.

The pcap-ng file reading code turns Timestamp (High) and Timestamp (Low) into 
such a value, just as the pcap code turns its time stamp (seconds since January 
1, 1970, 00:00:00 UTC, and either microseconds or nanoseconds since that 
second, into that format, and so on.

> I figure that adding another display option should be feasible to handle this 
> special case.

No, that's not feasible, given the way Wireshark works.

To handle a time stamp that rolls over on day boundaries, the Wiretap API would 
have to be changed.  There are some files that have time stamps like that (some 
of the text formats dumped out by some devices only give times, not dates), so 
that might be a useful change, but it's not a simple change.

The UI would, for files such as that, probably not offer any options to display 
the date, *and* dissectors would probably be changed to, if no date-and-time 
was available, either not do things such as calculating response times, or 
display them only if the response time is positive.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to