tcpdump mailing list archives
Re: Extra #ifdef's required for pcap-linux.c
From: Guy Harris <guy () alum mit edu>
Date: Fri, 20 Aug 2010 13:56:25 -0700
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.
Current thread:
- Re: Extra #ifdef's required for pcap-linux.c Guy Harris (Aug 20)
- Re: Extra #ifdef's required for pcap-linux.c Darren Reed (Sep 18)