Re: adding IRIG time and time of day

["John Dill" <John.Dill () greenfieldeng com>]

> Message: 4
> Date: Sat, 2 Nov 2013 19:50:58 -0700
> From: Guy Harris <guy () alum mit edu>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Subject: Re: [Wireshark-dev] adding IRIG time and time of day
> Message-ID: <710F03E1-AD4B-400C-9E8C-6B66CFC78342 () alum mit edu>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> On Nov 2, 2013, at 4:36 PM, "John Dill" <John.Dill () greenfieldeng com> wrote:
>
> > > On Nov 1, 2013 at 2:18:04 PM, Guy Harris <guy () alum mit edu> 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 <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe