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 <[email protected]> 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.
