On Nov 5, 2013, at 3:22 PM, John Dill <[email protected]> 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.
___________________________________________________________________________
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
