Re: Extra DLT types required for opensolaris DLPI DL

[Darren Reed <Darren.Reed () Sun COM>]

On 26/03/09 05:23 PM, Guy Harris wrote:
> On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
>
> > I'm trying to work out how to correctly map the DLPI data link
> > types that are used to each of the relevant DLT's that are
> > supplied in bpf.h. Some of them are easy, some are repeats,
> > some not so...
>
> ...and some DL_ values appear to have been reserved for future use 
> "just in case" but don't appear to refer to a network type particular 
> enough to have a link-layer header, so, as a DLT_ value refers to a 
> *particular* link-layer header type, they can't, by themselves, be 
> mapped to a DLT_ value.
>
> > I'm not completely sure if I should assume DLT_NULL for the
> > likes of IPv4/6 tunnels or pretend that the outer IP header
> > is the "link header" and thus in need of a DLT_IPV4/DLT_IPV6.
> >
> > So I'd like to request that a DLT types be given for each
> > unique type that's included below and currently mapped to "0".
>
> ...and that doesn't already have an appropriate DLT_ value.
>
> However, as indicated, DLT_ values refer to a particular link-layer 
> header type - it is an Extremely Bad Thing to require some weird 
> heuristic to determine how to dissect a packet even if you know the 
> DLT_ value, and I don't want to increase the number of Extremely Bad 
> Things that tcpdump/Wireshark/etc. have to do for that - so, for some 
> of those DL_ types, it might not be possible to add a new DLT_ value 
> for them, and, for some others, an indication of the precise 
> link-layer header format for them would be necessary.
>
> Note also that not all of the DL_ values correspond to packets we're 
> likely to see these days; DLPI was invented back in the late 80's, 
> before some networking types died out.
>
> >       { DL_TPB,       0 },            /* IEEE 802.4 Token Passing Bus */
>
> I suppose we could add a DLT_IEEE802_4 value, although, in practice, I 
> don't know whether there are any 802.4 token buses around.

I suspect that this is going to be the case for a lot of these esoteric 
types. In part, my sending this email is to find out what other people 
know of these protocol(s) and if they are still used or not.


> >       { DL_METRO,     0 },            /* IEEE 802.6 Metro Net */
>
> I suppose we could add a DLT_IEEE802_6 value, but I don't know whether 
> anybody offers SMDS service any more.

I wonder the same about many of the link types I included...

> >       { DL_HDLC,      DLT_HDLC },     /* ISO HDLC protocol support */
>
> "HDLC" is a catch-all term for various types of networking, usually 
> meaning that
>
>     1) the packets are framed using HDLC framing (with bit-stuffing 
> and byte-stuffing)
>
> and
>
>     2) the packets have an HDLC-style header with an addresse followed 
> by an HDLC control field.
>
> I don't see a DLT_HDLC in the top-of-tree pcap/bpf.h.

Hmmm, I took that from NetBSD's <net/dlt.h>
It would seem like someone forgot to feed that back :-(
So someone has been bad, their definition for it is:

#define DLT_HDLC    16    /* HDLC framing */


> >       { DL_HIPPI,     DLT_HIPPI },    /* HIPPI interface */
>
> I don't see any DLT_HIPPI in the top-of-tree pcap/bpf.h.

From NetBSD:
#define DLT_HIPPI    15    /* HIPPI */

> >       { DL_IB,        0 },            /* Infiniband */
>
> To what particular sort of packets does that refer?

The driver that introduces IP over IB uses DL_IB here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/plugins/mac_ib.c

And the header definition(s) for the packets are here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ib/clients/ibd/ibd.h




> >       { DL_IPV4,      0 },            /* IPv4 Tunnel Link */
>
> What does the link-layer header on those packets look like?  Are they 
> just raw IPv4 packets with no link-layer header?  If so, that's DLT_RAW.
>
> >       { DL_IPV6,      0 },            /* IPv6 Tunnel Link */
>
> What does the link-layer header on those packets look like?  Are they 
> just raw IPv4 packets with no link-layer header?  If so, that's 
> DLT_RAW.  (The IP version number can be used to distinguish between 
> IPv4 and IPv6.)

These are IPv4/6 in IPv4/6.

And it sounds like DLT_RAW is what to use here - ok.

> >       { DL_WIFI,      DLT_IEEE802_11 },       /* IEEE 802.11 */
>
> Presumably the packet begins with an 802.11 header, with no radio 
> information.  If it has radio information - preferably using the 
> radiotap header! - it'd be the DLT_ value appropriate for the radio 
> information.

So according to:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/plugins/mac_wifi.c
it's the 802.11 header, without radio information - or at least there is 
nothing there that looks remotely like it is dealing with radio bits.

Darren


-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.