Re: Reserving a libpcap DLT value

[Kent Dahlgren <kent () praesum com>]

Guy

The goal here is to de-couple the requirement for coordination between
libpcap and Ethereal. From what I have seen in the Ethereal comments
it hasn't worked well, and the situation will only get worse. The number
of transports will grow dramatically the use of as switched interconnect
technology increases.

The approach that I have suggested is simple.

        1) A libpcap file is generated by whatever tool the user wants.
        This includes specialized tools that grab packet streams from
        specialized interfaces like the NPF Streaming Interface. All they
        have to do is make the data link type = DLT_NAMED, and set
        the dlt_name string to "dissector_name".

        2) Ethereal loads the file and starts decoding it with a dissector
        whose PROTOABBREV = dissector_name.

So I have two questions:

        1) how do I get "DLT_NAMED" reserved in libpcap?

        2) Who do I coordinate with to get the DLT_NAMED
        extensions that I am working on in Ethereal 0.97
        integrated into the next release?

Thanks
Kent

At 04:14 PM 10/8/2002 -0700, Guy Harris wrote:
> On Tue, Oct 08, 2002 at 11:18:31PM +0200, Hannes Gredler wrote:
> > On Tue, Oct 08, 2002 at 07:41:11AM -0700, Kent Dahlgren wrote:
> >
> > | I'd like to create a new value that will be used
> > | to communicate what I call Named Data Link
> > | Type information to Ethereal.
> >
> > kent,
> >
> > wouldn't a simple value2string tokentable do what you are looking for ?
> >
> > static const struct tok bpf_dlt_values[] = {
> >     { DLT_EN10MB,     "Ethernet (10Mb)" },
> >     { DLT_EN3MB,      "Experimental Ethernet (3Mb)" },
> >     { DLT_AX25,       "Amateur Radio AX.25" },
> >     { DLT_PPP,        "Point-to-point Protocol" },
> >     { DLT_FDDI,       "FDDI" },
> >     { 0, NULL}
> > };
> >
> > what is the reason why you want to create a new DLT_ value ?
>
> His message to the Ethereal list said:
>
>         I'd like to be able to capture packets from a non-supported
>         transport and transfer them to Ethereal for decoding.
>
>         Specifically I would like to be able to display packet transfers
>         across a RapidIO link. I have written a utility to generate
>         trace files in libpcap format and a dissector to the RapidIO
>         transport layer.
>
>         The problem that I am running into is how to communicate
>         the transport type to Ethereal. There is no "DLT_" value for
>         this transport, and therefore Ethereal has no knowledge of
>         where to start when decoding the file.
>
>         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
>                 };
>
>         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.
>
>         Am I missing something? Is there an easier way to do this?
>         Any feedback would be appreciated.
>
> Presumably the "dlt_name" field would be absent for other DLT_ values.
>
> However, I'd prefer to have separate DLT_ types for new data links, as I
> don't want Ethereal-specific stuff added to libpcap format.
>
> (Alternatively, we could add DLT_NAMED but have the protocol names
> specified by the libpcap developers rather than by Ethereal, but I'm not
> sure there's any advantage to that.)
> -
> This is the TCPDUMP workers list. It is archived at
> http://www.tcpdump.org/lists/workers/index.html
> To unsubscribe use 
> mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe


-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe