On Fri, 12 Apr 2024 18:49:05 -0700
Guy Harris <ghar...@sonic.net> wrote:
> A while ago, tcpdump and its configuration script were modified -
> mainly by Bill Fenner, as I remember - so that it didn't require a
> contemporary version of libpcap, and could be built with older
> versions of libpcap.
>
> The intent, as I remember, was to allow somebody who was using a
> system that provided both libpcap and tcpdump to build a more recent
> version of tcpdump without having to download and build a newer
> version of libpcap.
Specifically, tcpdump tests for particular functions one-by-one and
then enables specific code paths depending on specific HAVE_PCAP_xxxxx
macros. This covers some use cases, however...
First, the solution is not always convenient: every program that uses
libpcap has to make the build-time checks without much assistance from
libpcap headers: i.e. instead of hinging the conditionals on
hypothetical PCAP_HAVE_PCAP_xxxx macros pre-defined (or not) in a
libpcap header the checks have to be duplicated: tcpdump uses one set
in Autoconf and another in CMake. Other software has to use its own
means to detect particular functions. This complicates usage
unnecessarily (as soon as a particular revision of libpcap has
compiled, the fact it implements a particular function is a constant).
Second, the solution space does not always match the problem space:
sometimes the software that uses libpcap needs to know not just that a
particular function is available, but also whether it implements a
particular detail (default behaviour, a feature or a bug/fix). In
practice this boils down to checking libpcap version. The latter is not
as trivial as it should be. I remember one program parsing the [string]
result of pcap_lib_version() because there wasn't a more appropriate
way to do it.
Since tcpdump is the reference implementation of a program that uses
libpcap, it may be a good occasion to improve the solution space such
that other software can copy something that works well in tcpdump. It
is not entirely obvious the LIBPCAP_HAVE_PCAP_xxxx macros would be worth
the burden of maintenance, but the version macros should be a
straightforward improvement, something such as:
#define PCAP_VERSION_MAJOR 1
#define PCAP_VERSION_MINOR 11
#define PCAP_VERSION_PATCHLEVEL 0
#define PCAP_VERSION_AT_LEAST(a, b, c) ...
(The GCC and Clang version checks in compiler-tests.h would be examples
of a good macro structure; Sun C, XL C and HP C version checks look
unwieldy and error-prone).
There could be a run-time check as well:
extern int pcap_version_at_least (unsigned char major, unsigned char
minor, unsigned char patchlevel);
The latter could be available via a build helper binary, such as (using
the binary operators from test(1) and version-aware comparison):
pcap-version -ge 1 # same as 1 0 0
pcap-version -ge 1 10 # same as 1 10 0
pcap-version -ne 1 10 4
pcap-version -eq 1 10 4
pcap-version -ge 1 9 1 && pcap-version -le 1 9 3
Obviously, any such improvements would not cover any earlier releases of
libpcap, so would need time to propagate.
Would this make sense?
> Currently, at least in theory, we support versions of libpcap at
> least as old as 0.4, which was the last version released by LBL.
>
> tcpdump, for example, supports versions of libpcap that don't include
> pcap_findalldevs(); that routine first appeared in libpcap 0.7, which
> was released in 2001, almost 23 years ago.
>
> It also supports versions of libpcap that don't include pcap_create()
> and pcap_activate(); those first appeared in libpcap 1.0, which was
> released in 2008, almost 16 years ago.
>
> Is there any reason not to require libpcap 1.0 or later? If there
> is, is there any reason not to require libpcap 0.7 or later?
Such use cases may exist, but I am not aware of any.
--
Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
