Re: Dropping support in tcpdump for older versions of libpcap?

[Denis Ovsienko <denis () ovsienko info>]

On Fri, 19 Apr 2024 11:18:47 -0700
Guy Harris <gharris () sonic net> wrote:

> On Apr 19, 2024, at 5:49 AM, Denis Ovsienko <denis () ovsienko info>
> wrote:
>
> > On Fri, 12 Apr 2024 18:49:05 -0700
> > Guy Harris <gharris () sonic net> wrote:  
>
>       ...
>
> > 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).  
>
> Presumably meaning that we should export version information in the
> way GCC and Clang do, rather than in the ways that Sun/Oracle C, XL C
> and HP C do, the latter being why we have to go through all that
> extra pain (they provide a single #define with the version number
> components packed in it - or two different defines in different
> versions as XL C does - rather than separate #defines for major and
> minor versions, as GCC and Clang do).

On a second thought, the best way to describe the desired result would
be that from the library users' point of view the version macros should
be easy to use correctly and difficult to use incorrectly.  This would
justify some inconvenience in the library code, if necessary.

An advantage of correctly sized BCD versions is that two packed integer
values compare in a straightforward way, so every end user does not
have to remember how to compare two version triplets correctly.  A
disadvantage of BCD versions is the need to unpack them if one needs
individual components.

Perhaps the best balance would be in defining the individual version
components as individual macros, and defining one-way "make this a BCD"
and "make the current libpcap version a BCD" macros.

For example, instead of

// require libpcap >= 1.10.2
PCAP_VERSION_MAJOR > 1 ||
(PCAP_VERSION_MAJOR == 1 && PCAP_VERSION_MINOR > 10) ||
(PCAP_VERSION_MAJOR == 1 && PCAP_VERSION_MINOR == 10 &&
PCAP_VERSION_PATCH >= 2)

the users could use the following:

// require libpcap >= 1.10.2
PCAP_VERSION_BCD_CURRENT >= PCAP_VERSION_BCD(1, 10, 2)

(where the exact number of bits allocated to each version component and
the definitions of PCAP_VERSION_BCD_CURRENT and PCAP_VERSION_BCD() are
an internal detail so long as the same values compare the same in
different versions of libpcap)

> > There could be a run-time check as well:
> >
> > extern int pcap_version_at_least (unsigned char major, unsigned char
> > minor, unsigned char patchlevel);  
>
> So how would that be used?
>
> If a program is dynamically linked with libpcap, and includes calls
> to routines that were added in libpcap 1.12 or later, if you try to
> run it with libpcap 1.11, the run-time linker will fail to load it,
> as some symbols requested by the executable won't be present in the
> library. The only OS on which this can be made to work is macOS, with
> its weak linking mechanism:

[...]

> But *all* of those require either run-time checks for a particular OS
> version in macOS, in cases where you're using the libpcap that comes
> with macOS, or require loading the library at run time, finding
> particular routines at run time, and checking at run time whether the
> routine was found.

Thank you for the overview of weak linking means.  I suppose it would be
best to keep out of this space to keep the task relatively manageable.
The only use case for the C function I currently see is the
command-line version tester.

> > 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  
>
> So would this be used in a Makefile/configure
> script/CMakeFile.txt/etc. to check whether the libpcap on the system
> is sufficiently recent to include the routines your program needs,
> and fail if it isn't?

Yes (as the tcpdump dependency would be).  And not just the routines,
but their behaviour, as some software could require.

> > > 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.  
>
> So my inclination would be to require libpcap 1.0 for tcpdump 5.0.

Let's aim for that then?

-- 
    Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s