Re: Extra DLT types required for opensolaris DLPI DL

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

On Mar 26, 2009, at 6:47 PM, Darren Reed wrote:

> On 26/03/09 05:23 PM, Guy Harris wrote:
> > On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
> >
> > >      { 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 */

From a quick look at the only driver I found under sys/dev/ic that  
uses it, DLT_HDLC appears to mean "Cisco HDLC", which uses HDLC  
framing but not an HDLC header; instead, it has a 1-byte address field  
(0x8f for multicast and 0x0f for unicast), followed by a reserved by  
and a 2-byte Ethernet type (no HDLC control field).

Whether that's what DL_HDLC is used for in any system whose link-layer  
interfaces are based on DLPI is another matter.  This page:

        https://www.opensolaris.org/jive/thread.jspa?threadID=60345&tstart=105

appears to suggest that they might be using it for Cisco HDLC (the  
0x8f), although this page:

        
http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.aixlink25/doc/x25usrgd/DL_INFO_ACK.htm

seems to suggest that IBM uses it for X.25 (LAPB being HDLC-derived,  
with a real HDLC control field).

> > >      { 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 */

From a quick look at sys/net/if_hippi.h and sys/net/if_hippisubr.c,  
the header appears to be:

        a 1-byte ULP field;

        a 1-byte flags field;

        a 2-byte "offsets" field;

        a 4-byte "D2 length" field;

        a 4-byte "destination switch" field;

        a 4-byte "source switch" field;

        a 2-byte reserved field;

        a 6-byte destination address field;

        a 2-byte "local admin" field;

        a 6-byte source address field;

followed by an 802.2 LLC header.  This appears to be what's specified  
in RFC 2067.

(BTW, a Google search for

        HIPPI RFC

suggests "Did you mean HIPPIE RFC?")

If there are interfaces using DL_HIPPI, and they supply the same link- 
layer header, a DLT_HIPPI would make sense.  Unfortunately, 15 is in  
the Badlands of DLT_ values, where various OSes have used the same  
numerical value for different purposes, so we'd probably end up  
assigning a new value in the range starting with 100 (which is the  
range we're maintaining).

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

The Wireshark dissector for Infiniband appears to assume the packet  
starts with a Local Route Header, followed by a Global Route Header,  
followed by a Base Transport Header; if that's what the driver hands  
that up, then you might want to experiment with a private  
DLT_INFINIBAND value (pick one of the DLT_USERn values), have wiretap/ 
libpcap.c map that value to a WTAP_ENCAP_USERn value, and then wire up  
that WTAP_ENCAP_USERn to the Infiniband dissector.  If that works,  
then we should assign a DLT_INFINIBAND value, otherwise we'll need to  
find out what's different and assign that to DLT_INFINIBAND_SOLARIS or  
something such as that.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.