Re: DLT value for IP over IB (Infiniband)

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

On Jul 14, 2011, at 5:23 AM, Darren Reed wrote:

> Some more follow up on this...
>
> Looks are deceiving - there is no RFC 4391/4392 header being prepended to the IP packet:
> /*
> * In order to transmit the datagram to correct destination, an extra
> * header including destination address is required. IB does not provide an
> * interface for sending a link layer header directly to the IB link and the
> * link layer header received from the IB link is missing information that
> * GLDv3 requires. So mac_ib plugin defines a "soft" header as below.
> */
> (From a header file on Solaris)
> The above probably explains this output on Linux:
>
> # tcpdump -i ib0 -vv -e -c 5
> tcpdump: WARNING: arptype 32 not supported by libpcap - falling back to cooked socket

What explains that part of the output is that libpcap doesn't have any code to map ARPHRD_INFINIBAND to any DLT_ value, 
because nobody's contributed any such code.  Perhaps that's because there's no DLT_ value that corresponds to whatever 
the link-layer header looks like on ARPHRD_INFINIBAND devices on Linux; it's not because of anything specific to 
Solaris.

> ... and which ultimately means there is not likely to ever be a real link layer header presented for outbound 
> packets. For inbound, it would seem that it is implementation dependent.

If "implementation-dependent" means "it's different on Solaris and Linux", the solution is simple - different LINKTYPE_ 
values for Solaris and Linux; there's already precedent for LINKTYPE_ values for particular OS's flavor of link-layer 
headers: there are both LINKTYPE_ARCNET_BSD and LINKTYPE_ARCNET_LINUX, there's LINKTYPE_APPLE_IP_OVER_IEEE1394 for 
Apple's headers for IP-over-FireWire, there are a bunch of other LINKTYPE_ values with LINUX in the name, etc.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.