On Nov 2, 2013, at 4:36 PM, "John Dill" <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
>> On Nov 1, 2013 at 2:18:04 PM, Guy Harris <guy@xxxxxxxxxxxx> 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.