Re: Legacy Linux kernel support

[Mario Rugiero <mrugiero () gmail com>]

> 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.
Even if they are, I'm not sure why they would want to update libpcap
in that case.

> > 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.
Yes, I was typing faster than I was thinking. I meant at run-time.

> > 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.
Yes. This still makes for different builds, and this still means what
the kernel headers define may not match what the user has.
If we support only newer kernels at run-time, it makes sense that we
support only newer kernels at build-time.

> 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.
Yes. That's what I'm proposing.

> 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;
Hmmm, I use memory-mapping precisely to deal with that fire hose
without dropping too much.

>         memory-mapped mode means declaring a maximum-sized buffer for packets, so it may consume more memory for the 
> buffering;
I could argue that declaring this maximum-sized buffer may give you
more control over the memory consumption instead.

> so non-memory-mapped capturing might be a better fit.
Isn't pcap currently using memory-mapping whenever it can?

> ("(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.)
That's a weird use-case indeed. I'm not sure libpcap is that bad of an
option for this.

> > 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.
The thing is, we can never know that there aren't. We can only know
there are, if someone asks for support for them.
It's a leap of faith.
I think I'd rather just fix security bugs (easy to say, not being the
maintainer, heh) and backport them to some kind of LTS release than do
the main development with it polluting the code-base.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers