Re: Extra DLT types required for opensolaris DLPI DL types...

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

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.

>       { DL_TPR,       0 },            /* IEEE 802.5 Token Passing  
> Ring */

That's DLT_IEEE802.  The original DLT_ values were ARP hardware type  
values.  Given that DLT_ values identify the link-layer header, this  
was a poor choice, given that "IEEE 802 network" doesn't identify a  
particular link-layer header type.  In practice, several platforms  
adopted DLT_IEEE802 as the DLT_ value for Token Ring, so that's what  
it now means.

>       { 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.

>       { 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.

>       { DL_CHAR,      0 },            /* Character Synchronous  
> protocol */

What exactly does "Character Synchronous protocol" mean?  Does it  
refer to a particular protocol with a particular link-layer header, or  
is it a "generic" networking type?

>       { DL_CTCA,      0 },            /* IBM Channel-to-Channel  
> Adapter */

What particular sort of packets are going over the CTC adapter?

>       { DL_FC,        0 },            /* Fibre Channel interface */

To what particular sort of packets does this refer?

>       { DL_X25,       0 },            /* X.25 LAPB interface */

Do those packets begin with a raw LAPB header, or is there a pseudo- 
header giving, for example, an indication of incoming vs. outgoing  
packets?

>       { DL_ISDN,      0 },            /* ISDN interface */

To what sort of packets does this refer?  LAPD packets on the D  
channel?  Some particular sort of traffic on the B channel?

>       { DL_HIPPI,     DLT_HIPPI },    /* HIPPI interface */

I don't see any DLT_HIPPI in the top-of-tree pcap/bpf.h.

>       { DL_100VGTP,   0 },            /* 100 Based VG Token Ring */

Did that have the same link-layer headers as 802.5?  If so, it's  
DLT_IEEE802.

>       { DL_IB,        0 },            /* Infiniband */

To what particular sort of packets does that refer?

>       { DL_FRAME,     DLT_FRELAY },   /* Frame Relay LAPF */

So those packets start with a Q.922 Frame Relay header, right?  If  
not, they'd need a different DLT_ value.

>       { DL_MPFRAME,   0 },            /* Multi-protocol over Frame  
> Relay */

What does the link-layer header on those packets look like?

>       { DL_ASYNC,     0 },            /* Character Asynchronous  
> Protocol */

What exactly does "Character Asynchronous protocol" mean?  Does it  
refer to a particular protocol with a particular link-layer header, or  
is it a "generic" networking type?

>       { DL_IPX25,     0 },            /* X.25 Classical IP interface  
> */

What does the link-layer header on those packets look like?

>       { DL_LOOP,      DLT_NULL },     /* software loopback */

If, as, and when Solaris supports capturing on the loopback interface,  
will the packets begin with a 4-byte header containing an AF_ value,  
in host byte order?  If not, DLT_NULL isn't appropriate.

>       { DL_OTHER,     0 },            /* Any other medium not listed  
> above */

That comment almost explicitly indicates that no DLT_ value can  
possibly handle it, as it implies that there could be more than one  
link-layer type corresponding to it.

>       { 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.)

>       { SUNW_DL_VNI,  0 },            /* Virtual network interface */

What does the link-layer header on those packets look like?

>       { 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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.