Re: RFC: a loadable plugin framework for external capture backends

[Guy Harris <gharris () sonic net>]

On Oct 4, 2026, at 2:11 AM, Robin Jarry <rjarry () redhat com> wrote:

> Hi Guy,
>
> First of all, I need to clarify one thing: DPDK is *not* an application. It is a low-level collection of hardware 
> drivers and libraries. And more important: Applications using DPDK (OVS, VPP, grout, etc.) do *not* have the same 
> representation for what is an interface. DPDK only provides abstractions for what is an Ethernet device.
>
> Any attempt at making a *generic* capture API in DPDK libraries will only work on physical ports. You will not be 
> able to capture traffic on logical interfaces (e.g. VLAN, VXLAN, IPIP, GRE, etc.) as these are logical constructs 
> that only make sense in the context of each application.
>
> Guy Harris, Oct 03, 2026 at 21:15:
> > At least as I understand Michael's proposal, I'm not sure to what extent it differs from many of the existing 
> > built-in modules.
> >
> > For example, the D-Bus sniffing support requires that the dbus-1 package be installed, so it can link with that 
> > library. The configure script and CMakeLists.txt check whether it's present and, if so, configures libpcap to link 
> > with it and defines PCAP_SUPPORT_DBUS.
>
> The premise for this is that libpcap is aware of such backends *in advance*.

Yes. That awareness can be added by pull requests from developers of third-party backends.

> This is the very thing our proposal wants to avoid.
>
> > As I understand it, Michael's proposal would, to use DPDK as an example, check whether a "DPDK libpcap support" 
> > library, which provides findalldevs and create routines, is installed, and, if so, configures libpcap to link with 
> > it and defines PCAP_SUPPORT_DPDK.
>
> > The only difference I see there is that the code that uses the D-Bus library to support capturing is currently part 
> > of libpcap, although, with the scheme in question, perhaps the D-Bus developers should take that over.
>
> Reflecting back on my first paragraphs: PCAP_SUPPORT_DPDK would not make any sense if you want to capture traffic 
> from DPDK-enabled applications. It would only be a PoC demonstration like the one I removed before 0.11.0. Nothing 
> you could use in real-world applications.
>
> You would need PCAP_SUPPORT_GROUT, PCAP_SUPPORT_OVS, PCAP_SUPPORT_VPP, etc. And you would be right where we started 
> before removing DPDK support, only worse. Each application would need to add their backend code in the libpcap 
> repository and maintain it every time their API changes.

At least for "everything is a package" platforms, such as most Linux distributions, that would not, in fact, be the 
case.

Each backend provider would, as part of one of their packages, provide the backend as a library (shared, unshared, or 
both). Libpcap's autoconf script and CMakeLists.txt would check whether that library is present and, if so, set the 
appropriate PCAP_SUPPORT_xxx definition so that the entry in pcap.c's table of additional modules would include them, 
arrange that pcap-config and libpcap's .pc files link with those libraries for a static build if a static library for 
the backend is provided, and arrange that libpcap be linked with the backend library.

The providers of the platform would have to include that backend, and arrange that it be present when libpcap is built, 
to ensure that it's available to software linked with libpcap.

> This would impose additional maintenance on libpcap

I don't see any maintenance required beyond what we *already* require for backends that require linking to additional 
libraries.

> and/or forbid any API changes in such applications.

The only API changes this would forbid is API changes to the find-devices and create-a-pcap_t routines in the backend 
(as well as changes to the libpcap APIs that the backends use, but that would also be the case for dynamically-loaded 
backends). Changes to APIs that the mechanism the backend uses provides can be made; that would, of course, require 
that the backend change.

> The mechanism for discovering and loading of these backends can be discussed, but I personally think the only viable 
> solution is dlopen().

(And LoadLibrary() on Windows.)

> It allows OS/distros to ship a vanilla libpcap with dynamic loading enabled and then let applications/backends 
> contribute with their own plugin. For example: there is no need to have D-Bus support if no D-Bus application is 
> installed.

Yes, that's one advantage.

> This proposal comes with a bonus: existing backends that are currently built-in libpcap could use that same mechanism:
>
> PCAP_SUPPORT_BT
> PCAP_SUPPORT_BT_MONITOR
> PCAP_SUPPORT_DBUS
> PCAP_SUPPORT_LINUX_USBMON
> PCAP_SUPPORT_NETFILTER
> PCAP_SUPPORT_NETMAP
> PCAP_SUPPORT_RDMASNIFF
>
> And switch to a dynamically loadable plugin instead of having #ifdef's sprinkled around the code base.

There are precisely three instances of #if/#ifdef checks of PCAP_SUPPORT_LINUX_USBMON. Some have only two; this 
provoked me to check, and I think the tests in pcap_lookupnet() could be removed with a small change to the module 
interface to handle "what are the IPv4 address and netmask for this interface".

There are some cases where PCAP_SUPPORT_NETMAP is checked outside pcap.c; those can probably be eliminated by adding an 
"add some text to the version string to indicate that this mechanism is supported" routine to the module interface - 
which would have to be done for dynamically-loadable modules as well.

So that bonus seems small.

The differences I see between what I understand Michael's proposal to be and your proposal are that:

1) Michael's proposal doesn't involve as much effort to avoid malicious added mechanisms, as it's *less* flexible*;

2) your proposal makes it somewhat easier to add mechanisms on "everything is a package" platforms and *significantly* 
easier to add mechanisms on "libpcap is part of the core OS" platforms, and makes it possible to allow D-Bus/{pick your 
DPDK-based mechanism}/etc. support in libpcap to be available if and only if the underlying mechanism is available, as 
it's *more* flexible.
_______________________________________________
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