Re: Extra #ifdef's required for pcap-linux.c

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

On Jun 30, 2010, at 3:10 PM, Darren Reed wrote:

> Linux has defined a large number of values for dummy ARP
> header types (<net/if_arp.h>) that are not present in the
> official IANA listing. See the hardware type table here:
>
> http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml
>
> and compare it with the list found in pcap-linux.c.
>
> One of my current goals is to get pcap-linux.c to compile
> and function on Solaris using PF_PACKET in Solaris and
> after internal discussion, we're not entirely keen on
> defining all of the extra symbols found on Linux given
> that they have no actual basis.
>
> The attached diff introduces complimentary #ifdef's for
> all of the Linux extras, of which there is already some
> present. This should also make pcap-linux.c friendlier
> to all Linuxes.

The patch adds backup definitions for:

        ARPHRD_PPP
        ARPHRD_CSLIP
        ARPHRD_SLIP6
        ARPHRD_CSLIP6
        ARPHRD_ADAPT
        ARPHRD_SLIP
        ARPHRD_LOCALTLK

All of those are defined by the if_arp.h in the 2.0 kernel, so the only Linuxes to which the patch would make 
pcap-linux.c friendlier are

        1) Linux 1.x kernels, which I don't think we even try to support;

        2) Linux kernels that have gratuitiously removed ARPHRD_ definitions, which I'm not inclined to try to support.

If the goal is to, for some reason, support PF_PACKET in Solaris (given that we already support both DLPI and Solaris's 
BPF, I'm not sure why PF_PACKET support is useful, but...), I'd be inclined to, instead, just wrap the cases in 
question with an #ifdef for the case label - if Solaris isn't going to return ARPHRD_PPP (even for PPP devices?), 
there's no point in checking for it.
Going back to the 2.0 kernel, of the

> btw, the above table also suggests that the Linux
> handling of type 15, frame relay, is incorrect.

Unfortunately, there's no guarantee that, for a given ARPHRD_ type (whether it's an IANA-assigned ARP type or a dummy), 
if you try to capture "raw" packets (PF_PACKET/SOCK_RAW), you will get any link-layer header, much less a link-layer 
header appropriate to the link-layer type.  That's not the case for ARPHRD_PPP, or at least wasn't the case a while 
ago, which is why ARPHRD_PPP gets captured in cooked mode (PF_PACKET/SOCK_DGRAM) - that means that you get a link-layer 
type value, which you don't get with PF_PACKET/SOCK_RAW.

That's why there's the comment

                /*
                 * XXX - should some of those be mapped to DLT_LINUX_SLL
                 * instead?  Should we just map all of them to DLT_LINUX_SLL?
                 */

in the cases for ARPHRD_RAWHDLC and ARPHRD_DLCI.  The current handling of ARPHRD_DLCI (and ARPHRD_FRAD) comes from a 
patch submitted by Krzysztof Halasa back in 2003; when I asked him about it, he replied

> Guy Harris <guy () alum mit edu> writes:
>
> > Do ARPHRD_DLCI devices supply a useful link-layer header (from which the
> > protocol running atop Frame Relay can be determined), or not?
>
> No. It's a virtual device and FR headers are added/removed by underlying
> physical device code.

so, for better or worse, it sounds as if ARPHRD_DLCI should be mapped either to DLT_RAW (i.e., all packets are IP, and 
the packet data begins with an IP header) or DLT_LINUX_SLL (i.e., not all packets are IP, so capture in cooked mode and 
put the cooked-mode header on the packets).

Perhaps they shouldn't have used 15 as the ARPHRD_ value for that, but that's water over the bridge; some parts of the 
Linux kernel use some of the ARPHRD_ values as ARP hardware types, but it's probably best, when dealing with PF_PACKET 
sockets, to think of them as link-layer header types, some of which happen to have the same values as the ARP hardware 
types for the corresponding link layer.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.