>Message: 2
>Date: Tue, 5 Nov 2013 09:19:15 -0800
>From: Guy Harris <g...@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: <c698fbe1-0808-4dfc-b85a-f5dd597f6...@alum.mit.edu>
>Content-Type: text/plain; charset=iso-8859-1
>
>> We have a CNIC-A2P3 board installed in a Compact PCI chassis.
>
>Unfortunately, GE won't let me get either the hardware manuals for their ARINC
>664 devices or the cpcap manual.
>
>I'm guessing, perhaps incorrectly, from the "pcap" in "cpcap", that it
>provides a libpcap-compatible API.
>
>The folks at GE *could* have, somewhere in the path between the hardware and
>the caller of cpcap:
>
>gotten the current year number;
>
>calculated the number of seconds between January 1, 1970, 00:00:00 UTC and
>January 1, {current year}, 00:00:00 >UTC (except for leap seconds - don't ask,
>that's why I say "seconds-since-the-Epoch" rather than "seconds since >the
>Epoch");
>
>added that to the "fractions of seconds since the beginning of the year" value
>from the IRIG-synchronized counter;
>
>when the IRIG time stamp overflows into the next year, increment the year
>number and recalculate the "number of >seconds since..." value;
>
>and provide *that* value as the packet time stamp (which they *especially*
>should have done if cpcap has what >they intend to be a libpcap-compatible
>API!).
>
>*Did* they do so, or do they just provide a "fractions of seconds since the
>beginning of the year" value?>From an excerpt from their manual describing the API The Cpcap API is a relatively high level set of functions, much like libpcap, with a user-friendly abstraction of the traffic source. --- They provided a set of sample driver programs that used the board's internal clock to timestamp packets, starting from 0. There was no sample (back then, there may be now) that demonstrated how to use the IRIG time signal from the board to synchronize the packet stream, or to populate the packet time with an Unix epoch timestamp (their API did at least document how to query the board for an IRIG time in seconds). Condor Engineering (bought by GE) also provided a modified version of Ethereal (or Wireshark) that attempts to handle some of the extensions that AFDX provided in a different graphical representation. It was difficult to understand and impractical to use for our needs. The other data streams (ARINC-429 and MIL-STD-1553 were timestamped using IRIG-B without the year, and their BusTools applications that provided graphical introspection of the data did not support Unix Epoch time format as an option. I decided to synchronize the packet stream to the IRIG-B so that all three bus modalities were synchronized to that same format. At that time, I was not very familiar with the pcap-ng standard and made that decision based on my group's local needs. I'm not sure if there's a good way to resolve the issue. Changing the MIL-STD-1553 and ARINC-429 timestamps to Unix Epoch would break their compatibility with the GE tools, and we'd have to adapt our other software tools to handle mixed time formats. There's several years worth of data that may or may not be politcally difficult to justify retroactively applying the Unix epoch just to make the capture files standard compliant. It is what it is. 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-requ...@wireshark.org?subject=unsubscribe
