Re: Request for new pcap/pcapng DLT Format

[Guy Harris <guy () alum mit edu>]

On May 21, 2013, at 1:06 PM, chris_bontje () 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