Re: Extra DLT types required for opensolaris DLPI DL

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

On 27/03/09 03:01 AM, Guy Harris wrote:
> 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).

Oh, do I serve my masters present or masters future? Confusion!

Seriously, for my purposes, it is "Cisco HDLC".

For the purposes of my table, I'd like to map the mediums that have 
passed (or are passing) from active use to "unsupported" and call it 
DLT_UNSUP (0xffffffff). On one level this is strange, because it isn't a 
DLT type, but it is a useful programming tool.


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

If you can give it a new number, I can see to it that the change gets 
into NetBSD. I can't see a whole lot of people screaming if it does 
change ;)

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

Ok, that's going to take some experimentation and I'll have to get back 
to you on that as I don't have any Infiniband machines handy.

Additionally, I'm considering creating a new datalink type for loopback 
packets on OpenSolaris. The contents would be something like:
version (16 bits: 1)
protocol family (16 bits: AF_INET, AF_INET6)
capture point (32bits enum: local, in, out)
interface index (32bits)
group interface index (32bits)
source zone (32 or 64bits?)
destination zone (32 or 64bits?)
I'm guessing that this should be called DLT_LOOP_SOLARIS.

Darren

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