[Guy Harris <guy@xxxxxxxxxxxx>]

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?

> 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.

> 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.

> 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.

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

	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).

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.