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<g...@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.