On May 21, 2013, at 1:06 PM, chris_bon...@selinc.com wrote: > Looking at the format again, you are correct - I guess those 8 header bytes > *are* redundant as to what the pcap file has been assigned for the packet > timestamps; I have a feeling they are part of a per-packet direct data dump > from the Monitor display that I showed in the other screen capture. If you > select the time-and-date format to display Epoch time, it evens gets more > telling: > > <Mail Attachment.gif> > > Changing the RTAC serial line header format may be an issue though as it has > been used for several years and we generally don't change formats like that > without *lots* of internal discussions due to fear of breaking backwards > compatibility. I'll have enough of a battle getting the DLT # changed. :) > > Let me know if that redundancy is a show-stopper for getting a DLT assigned > to the header type and I'll get my justifications written-up.
It's not a show-stopper - we can just document them as containing a time stamp but note that it's redundant with the time stamp in pcap and pcap-ng files, and say that the time stamp from the pcap packet record header or the pcap-ng packet block header should be used and the time stamp in the packet header should be ignored. Given that I've already checked in a LINKTYPE_/DLT_ value of 250, and assigned a value of 251 for Bluetooth Low Energy air interface link-layer packets, we might as well stick with the existing format, with a "time stamp is redundant, don't use it" note. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
