Re: Request for new pcap/pcapng DLT Format
Guy Harris <guy <at> alum.mit.edu>
2013-05-21 18:36:20 GMT
On May 20, 2013, at 7:19 PM, chris_bontje <at> selinc.com wrote:
> I'll include some screen captures of the Comm Monitor interface of the RTAC
Just out of curiosity, does that screen shot show a capture made in late November, 2011?
If so, was it done in your local area (which appears, from the area code, to be in eastern Washington state)?
If so, was it done at about 1:36 in the morning of November 23, 2011?
If so, those "seconds" fields look rather suspiciously like UN*X "seconds since the epoch" values, i.e.
*absolute* time stamps, not *relative* time stamps.
(If they were captured somewhere else, apply the appropriate time zone delta from the Pacific time zone to
"1:36 in the morning".)
> vs. the pcap contents. The "sub-seconds" 32-bit field is accurate to 6 digits.
By that do you mean "the "sub-seconds" 32-bit field is a count of microseconds since the second specified in
the "seconds" field"?
If so, and if the "seconds" field is a UN*X "seconds since the Epoch" value, the time stamp sounds *VERY*
suspiciously like a "struct timeval"...
...which, given that, as you said, "the RTAC platform is Linux-based", i.e. it's running on a UN*X, would
not be very surprising at all.
If so, then the time stamp field in the header is redundant - the time stamp field in the pcap or pcap-ng
records would suffice, as the former are "struct timeval"-style time stamps, and the latter are also
(Continue reading)
RSS Feed