Legacy Linux kernel support

[Mario Rugiero <mrugiero () gmail com>]

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.
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.
Anybody not upgrading the kernel for as long is very unlikely to want
to update libpcap.
The result is a code that is quite daunting and hard to debug and
understand for newcomers (hi!), for what I see as little to no gain.
I posted an issue in Github (#853) about this and thought it'd be
better to discuss this here.
While I'd like to do the work, I think it'd be most productive if I
met any objection or suggestions before going through the work and
making a PR.
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.
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.

I think the module can benefit from a general cleanup.

Examples of what I'd like to see removed are:
TPACKET V1 and V2 handling. This includes some special casing for VLAN tags.
SOCK_PACKET. All of it.

In the same note, assuming an environment from this decade brings us
some possibilities to write simpler and shorter code.
For example, querying the present interfaces becomes way easier
calling if_nameindex than the current crawl through sysfs.
That was probably not an option before, but IIRC the first glibc to
implement it became common ~2005.

Anyway, I declare the debate open.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers