["John Dill" <John.Dill@xxxxxxxxxxxxxxxxx>]

>Message: 1
>Date: Wed, 6 Nov 2013 13:12:04 -0800
>From: Guy Harris <guy@xxxxxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] adding IRIG time and time of day
>Message-ID: <A4378249-6D30-404F-8123-2FE8B845C519@xxxxxxxxxxxx>
>Content-Type: text/plain; charset=iso-8859-1
>
>
>On Nov 5, 2013, at 3:22 PM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
>
>> 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).
>
>So they didn't provide code to even time stamp packets with IRIG-derived time stamps, much less with Unix->epoch time stamps?

Correct.

>> 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.
>
>Could you get the source code to their modifications? (If not, they've violated the GPL, and lawyers can be sent >after them to force them to provide the source code.) That might be interesting.

They provide three headers: cpcap.h, CnicStructures.h, and version.h, and a library that you link against.  The version that I have have a copyright license from Condor Engineering.  From the look of the header file, most of the interface does not mimic pcap per se except for the pcap_compile related stuff.  The source code never came with the distribution, and I never bothered to ask for it, so it's unclear how much is a wrapper around pcap and what's not.

>> 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.
>
>OK, so it sounds as if you had to (as per the first paragraph above) write your own code to combine the board's >internal clock value and the IRIG time value somehow to generate a "fractions of a second since the beginning >of the current year" time stamp for packets. Combining that with the current year would have been preferable, >but what's done is done.

That's correct.

>> 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.
>
>So, *IF* you know what year a capture was started, you could convert the time stamps in libwireshark, and >present "seconds-and-nanoseconds-since-the-Epoch" time stamps to Wireshark/TShark/etc., as those >programs expect.

I can find the year based on either the last modification timestamp of in the file's properties, or using the date substring in the packet dump filename as well.  The packet dump files all have an automatically generated filename with a standard naming convention.  I suppose it's possible to analyze the filename format on Open and branch into a special case that resolves the time difference (in a patch I'd maintain).

>If you know what year a given capture was started, one option might be to:
>
>add a special API to libwireshark to specify a starting year for an open capture file (zero would mean "this file >has valid time stamps, no conversion is necessary);
>
>have the pcap-ng reader use that information to convert "fractions-of-a-second-since-the-beginning-of-the-year" >to "seconds-and-nanoseconds-since-the-Epoch" (doing this means keeping a table of frame offsets in the file >and time offsets, so that random access works, and watching for a wrap-around in the time stamps and treating >that as a switch to a new year, unless you don't need to support captures that start on or before December 31 >and end on or after January 1 of the next year);
>
>use the current trunk version of Wireshark, which has an option to display time stamps as YYYY/DOY >HH:MM:SS, or apply the change for that:
>
>http://anonsvn.wireshark.org/viewvc?revision=53114&view=revision <https://www.greenfieldeng.com/exchweb/bin/redir.asp?URL=http://anonsvn.wireshark.org/viewvc?revision=53114%26view=revision> 
>
>to your version (not all of the changes are necessary for that, but I took the opportunity to tweak some names, >fix some man pages, and add some missing capabilities to some TShark statistics taps when I noticed those >issues while making the change).

I appreciate your generous effort to include a day of year option in wireshark.

>If you *don't* know what year a capture was started, you could add a special hack (which wouldn't be accepted >in mainline Wireshark) to provide an option to, in the time stamp columns, treat time stamps as "seconds-and->nanoseconds-since-the-beginning-of-the-year", and do your own calculation to reduce them to year, day-of->year, hour, minute, and (non-integral) second. The changes would be similar to the aforementioned change in >some ways.
 
I will study the changes that you have made and try to determine how I can support both options (with a patch that I would have to maintain).
 
Best regards,
John Dill

<<winmail.dat>>