tcpdump mailing list archives
Re: Legacy Linux kernel support
From: Guy Harris <gharris () sonic net>
Date: Mon, 7 Oct 2019 10:27:15 -0700
On Oct 3, 2019, at 6:12 PM, Mario Rugiero <mrugiero () gmail com> wrote:
The 'pcap-linux.c' implementation is plagued by #ifdefs and special cases aiming to support kernels as old as the 2.0.x family era.
Heck, it may even support 1.x kernels with SOCK_PACKET support.
The oldest version supported by upstream is 3.16.74. The most 'bleeding-edge' supported family has been there since the 2.6.y times, almost 10 years ago, so I think we can assume it's present on any current user's box.
A long time ago, I had the impression that 2.0.x kernels, and perhaps even 1.x kernels, were popular for some small embedded systems; some of them might perform networking functions, so that libpcap support might be useful, even if they didn't run full-blown tcpdump, but just ran something that can write out a pcap file to read on another machine. If nobody's still doing that, we might as well get rid of, for example, SOCK_PACKET support. Currently, we do "immediate mode" capture with TPACKET_V2; I'm not sure whether that, or non-memory-mapped capture, would be better for immediate mode.
So far, there has been an objection regarding a bug on TPACKET V3 that is present in 3.16, but Guy pointed out libpcap already works around that, to which I add that this behaviour in libpcap can only be defined at build-time.
Which behavior can only be defined at build time? The work-around itself is enabled or disabled based on the current running kernel version; see set_poll_timeout(). The point there is that there isn't a version of the kernel that supports TPACKET_V3 on which we can't use TPACKET_V3, given the workaround.
I think it would be useful to have the closest to a single build that we can get. I get having different builds for different user facing features (sniffing USB, for example), but not for something the user generally won't know, such as if the kernel where libpcap was built supported TPACKET V2 or V3.
We don't #ifdef around whether the kernel on which we'll be *running* has TPACKET_V3. We #ifdef around whether the *headers with which we're building* have the #defines, structures, etc. needed to compile the code that supports TPACKET_V3. If we were to drop TPACKET_V1 and TPACKET_V2 support, that'd mean we'd be dropping 2.x kernels and older 3.x kernels as targets, and would require that the headers with which libpcap is being built be new enough to support TPACKET_V3.
Examples of what I'd like to see removed are: TPACKET V1 and V2 handling. This includes some special casing for VLAN tags.
So that would mean using non-memory-mapped capturing in immediate mode. That might even work better for that purpose - yes, there's more copying involved (copying the packet to the socket buffer and then copying from the socket buffer into userland), but: immediate mode is generally used for people (ab)using libpcap to implement protocols at the link layer, where you aren't necessarily dealing with the packet firehose you can get when doing sniffing; memory-mapped mode means declaring a maximum-sized buffer for packets, so it may consume more memory for the buffering; so non-memory-mapped capturing might be a better fit. ("(Ab)using" in the sense that perhaps there should be a *separate* library for use by code implementing protocols that run directly atop the link layer; on some platforms - not just Linux - that code might use a completely different mechanism from the mechanism used by libpcap.)
SOCK_PACKET. All of it.
Unless there are still important small embedded devices or whatever 1) for which there's a good reason to run a 2.0.x (or 1.x) kernel, 2) for which there's a need to run libpcap-based code on the device, and 3) on which they'd really want to build the Latest Newest Shiniest version of libpcap, yes, drop SOCK_PACKET support. _______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Legacy Linux kernel support Mario Rugiero (Oct 03)
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero (Oct 07)
- Message not available
- Re: Legacy Linux kernel support Guy Harris (Oct 07)
- Re: Legacy Linux kernel support Guy Harris (Oct 07)
- Re: Legacy Linux kernel support Mario Rugiero (Oct 07)
- Re: Legacy Linux kernel support Guy Harris (Oct 07)
- Re: Legacy Linux kernel support Mario Rugiero (Oct 07)
- Re: Legacy Linux kernel support Guy Harris (Oct 07)
- Re: Legacy Linux kernel support Mario Rugiero (Oct 07)
- Re: Legacy Linux kernel support David Laight (Oct 08)
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero (Oct 08)
- Re: Legacy Linux kernel support Guy Harris (Oct 08)
- Re: Legacy Linux kernel support Mario Rugiero (Oct 08)