On Sat, Sep 28, 2002 at 02:19:19PM -0700, Kent Dahlgren wrote:
> One approach to this problem would be to create a new
> Data Link Type called "DLT_NAMED" and add an additional
> parameter to the libpcap file header, as follows:
>
> // "libpcap" file header
> struct pcap_hdr {
> uint32 magic; // magic number
> uint16 version_major; // major version number
> uint16 version_minor; // minor version number
> int32 thiszone; // GMT to local correction
> uint32 sigfigs; // accuracy of timestamps
> uint32 snaplen; // max length of captured packets
> uint32 network; // data link type = DLT_NAMED
> char dlt_name[]; // data link protocol name
> };
Presumably that field would be *completely absent* if the link type
isn't DLT_NAMED.
> The dlt_name parameter would be the PROTOABBREV name
> used by the protocol dissector. Using this mechanism users could
> easily add support for new data links for Ethereal such as RapidIO,
> PCI Express etc.
I would suggest that you propose that to tcpdump-workers@xxxxxxxxxxx,
not to the Ethereal list; libpcap file format isn't owned by the
Ethereal developers, and as an Ethereal developer *and* a
tcpdump/libpcap developer I don't want to see Ethereal unilaterally make
changes to the file format.
> Am I missing something? Is there an easier way to do this?
Introduce new DLT_ values for each new data link. Send mail to
tcpdump-workers@xxxxxxxxxxx to request a new DLT_ value, and somebody
(usually me) will do so (assuming somebody who would do so isn't out of
town, as I was for two weeks).
That:
obviates the need to modify the libpcap file header;
obviates the need to add code to wiretap/libpcap.c to parse that
string;
is more consistent with the way libpcap files work for all other
link types.
