>Message: 4 >Date: Sat, 2 Nov 2013 19:50:58 -0700 >From: Guy Harris <[email protected]> >To: Developer support list for Wireshark <[email protected]> >Subject: Re: [Wireshark-dev] adding IRIG time and time of day >Message-ID: <[email protected]> >Content-Type: text/plain; charset=iso-8859-1 > > >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.
Well, from what I've gathered on my side, it appeared that the very old AFDX capture files had a timestamp starting from 0 in nanoseconds, and was later converted to use an IRIG time to sync the same timestamp against other IRIG source data streams. It also appears that the block type was not the 'Enhanced' type with ID 6, but the Obsolete Packet Block with ID 2. It appears that the hardware board and the driver never created "standard legal" pcap-ng files. >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. I suppose that it is possible to retroactively put Unix Epoch timestamps into the packet stream, but the intent seems to be deliberate to keep multiple data streams in sync with a common timestamp (there are other external tools that dump the contents of the packet data payload beneath the UDP protocol layer with data from the other message streams, which expects a common timestamp in IRIG). >> 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. I don't foresee this tweak as rolling back into Wireshark proper, but a patch that I apply to Wireshark source to handle this particular data scenario in this corner case. Perhaps I can start by looking at TS_UTC_WITH_DATE and go from there. Thanks for your input. Best regards, John D.
<<winmail.dat>>
___________________________________________________________________________ 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
