Re: Legacy Linux kernel support

[Guy Harris <gharris () sonic net>]

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