On May 20, 2013, at 7:19 PM, chris_bon...@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 measured as fractions of a second (with a precision that defaults to 1 microsecond, but that's specifiable in the file) since the Epoch. > The pcap timestamp(s) are relative to the time of the start of the capture > utility. That's because you've specified that they should be displayed that way, right? What's displayed if you select "Date and Time of Day" as the time display format? _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
