plugin: add runtime plugin loader for external capture backends including dpdk by vjardin · Pull Request #1659 · the-tcpdump-group/libpcap

vjardin · 2026-03-20T17:29:37Z

Dataplanes like DPDK expose unstable APIs that change across releases. Compiling backends for these dataplanes directly into libpcap ties the two release cycles together: a DPDK API change breaks the libpcap build, and fixing it requires a coordinated update of both projects. The same problem applies to any fast-moving dataplane (grout, VPP, etc.) whose capture interface evolves independently from libpcap.

Add a generic plugin loader (pcap-plugin.c) that discovers external capture backends at runtime. Each backend ships as a pcap-*.so shared module in a well-known directory. The loader dlopen's every matching file, looks up a "pcap_plugin_entry" symbol, validates the ABI version, and dispatches findalldevs/create calls through it. Backends are found in $PCAP_PLUGIN_DIR (colon-separated), /usr/lib/pcap/plugins, and /usr/local/lib/pcap/plugins.

Because pcap-int.h is not installed, plugins cannot access the pcap_t struct directly. A set of pcap_plugin_* accessor functions is exported with default visibility: handle allocation, ops registration, field getters/setters, BPF helpers, and device enumeration. This gives plugins a stable ABI (versioned via PCAP_PLUGIN_ABI_VERSION) without exposing libpcap internals.

With this mechanism, a dataplane project builds its own pcap-*.so against its own headers and ships it alongside its packages. Upgrading the dataplane only requires rebuilding the plugin, not libpcap. If the plugin is absent or fails to load, libpcap keeps working — no compile time dependency, no conditional #ifdefs.

guyharris · 2026-03-20T17:40:42Z

There's already a code-loading API, pcapint_load_code(), in pcap.c.

It currently has only a Windows implementation, as it was only used to load AirPcap support code, allowing the same code to work regardless of whether AirPcap support was installed. It's currently unused in the main branch, as we removed AirPcap support (Riverbed's AirPcap devices are no longer supported by the vendor).

You should probably add UN*X support to that, and use it.

guyharris · 2026-03-20T18:09:56Z

Loading plugins should be done with great care, as opening capture devices requires elevated privileges on many platforms, which means you may be loading plugins into a program running with elevated privileges.

At minimum, plugin-loading code should require that the plugin be loaded from a specific trusted directory (or maybe one of a small set of trusted directories) and that neither the directory nor the plugin file be writable by unprivileged users.

There may be - in fact, there probably are - more things to worry about.

See, for example:

this Stack Overflow question and answers thereto;
this Medium post;
this Reddit post and th Mastodon post to which it refers - it started with Lennart Poettering discussing having systemd load library dependencies at runtime with dlopen() rather than linking them in, with one rationale being that it can reduce the attack surface of systemd ("Recently, another reason for doing this came into focus: ibsystemd was used as a vehicle to get from the backdoored liblzma into the ssh process. There's hence value in reducing the ELF dependencies loaded into consumers of our library, if we can avoid it, to make it harder to use our code as exploit vehicle, even if we were neither the final target of the attack, nor directly attacked.";
another Reddit post asking about secure plugin loading;
a comment in this Oracle document about secure use of dlopen();

Those were found with a Google search for "securely allowing dlopen for privileged code"; there may be others. A similar search, using LoadLibrary rather than dlopen, might also be useful.

Supporting plugin modules for libpcap would be useful in that it would, as you note, allow third parties to maintain their modules independently; the reason why I, at least, haven't done more than think about it is that it really needs to be secure.

(That also brings up the problem that opening a capture device may require privileges that you really don't want the program using. Perhaps the opening should be done by a program that runs with privileges and hands a file descriptor to libpcap over a UNIX-domain socket. The program still has some privileges, in that it has a descriptor for a capture device, but it's not as if it has root privileges if that's what opening the capture device required. But that's another discussion.)

fxlb · 2026-03-20T18:12:42Z

Adding plugins into a security-sensitive library like libpcap need conducting an in-depth security risk assessment.

mcr · 2026-03-20T20:25:09Z

So I think that we are all pretty wary about any kind of plugin system.
I suggest that DPDK look at rpcapd.c, and consider bringing that into DPDK core, where the dependancy/API drift can be better dealt with within the DPDK CI. The tcpdump/wireshark/libpcap interface is then rpcap protocol to localhost or Unix domain socket.
Maybe that also facilitates better JIT/adaption of pcap filters into DPDK runtime, which might also involve pushing filters down to smart NICs.

rjarry · 2026-03-20T21:32:30Z

Hey folks,

Thanks for the review and all the security refs, those are the right questions to ask.

On the rpcapd idea: the backends we're after (OVS-DPDK, grout, etc.) need to do packet capture into shared memory with no syscalls on the data path. The libpcap side would just mmap a file descriptor it gets from the dataplane over a unix socket. Going through rpcap's TCP/UDP sockets would negate the whole point -- you'd end up paying for copies and syscalls on every packet, which is exactly what these backends try to get rid of.

That said, the dlopen-in-a-privileged-process concern is legit and needs to be dealt with. I think there's a reasonable way to go about it though:

Before loading any plugin, libpcap could check if the process has elevated privileges (setuid/setgid, file capabilities on Linux). If so, either refuse to load plugins entirely, or drop the extra privileges first and only go ahead if the drop actually worked. That way a single tcpdump binary could still do tcpdump -i eth0 (needs raw socket privileges) and tcpdump -i $backend:port0 (just talks to a unix socket, no special privileges needed). These plugin backends won't need elevated privileges -- the dataplane process owns the capture, libpcap just reads from it.

In practice this probably means libpcap shouldn't load plugins silently on its own but instead expose something like pcap_load_plugins() that apps call explicitly. tcpdump would open its raw sockets, drop privileges, then call pcap_load_plugins(). Keeps the app in control instead of libpcap doing something unexpected behind its back.

Also $PCAP_PLUGIN_DIR should be ignored when running with elevated privileges, same way the dynamic linker drops LD_LIBRARY_PATH for setuid binaries. Only load from compiled-in system directories in that case, with ownership and permission checks on both the directory and the .so files.

Does that sound workable?

PS: if we want yet another layer on top, we could add optional signature verification before dlopen -- libpcap looks for a detached signature (e.g. pcap-foo.so.sig) next to each plugin and checks it against trusted public keys in a root-owned directory (say /etc/libpcap/trusted-keys/). Similar to how distros manage CA bundles or RPM signing keys -- the sysadmin decides what's trusted, not libpcap upstream. Though honestly, plugins installed via a package manager in root-owned system directories have already gone through the distro's own package signing, so it might be overkill. Worth discussing if the added complexity buys anything over the privilege checks and directory ownership validation alone.

Cheers

infrastation · 2026-03-20T21:40:30Z

Thank you for attempting this development, it certainly has its pro et contra. The first committed version would need to be safe and maintainable, and it would take some more design and implementation work to get there. If there is a similar library that has already solved a very similar problem using plug-ins, it could be used as a model to relate the problem space and the solution space.

We are trying to make a few releases before long, so substantial changes and new features are currently mostly on hold. That said, why not consider this matter in the background meanwhile.

I agree that potentially there may be more sense in DPDK developing a stable tiny API just for packet capture (whether via libpcap or not), and hiding the internal churn behind that interface. That said, rpcap may be not the best interface/transport for that.

vjardin · 2026-03-20T23:49:38Z

Thanks for all the feedback. I've scoped the plugin loader to mitigate the security concerns around loading external .so files

fxlb · 2026-03-21T06:56:47Z

If there is a similar library that has already solved a very similar problem using plug-ins, it could be used as a model to relate the problem space and the solution space.

+1.

vjardin · 2026-03-21T08:19:51Z

If there is a similar library that has already solved a very similar problem using plug-ins, it could be used as a model to relate the problem space and the solution space.

+1.

I did start checking. If you have a taxonomy I could refer too, can you share those ? Any URLs on their git repo ?

vjardin · 2026-03-21T15:44:17Z

Enclosed this minor update for the BSD systems.

mcr · 2026-03-21T17:38:50Z

So I think that we are all pretty wary about any kind of plugin system. I suggest that DPDK look at rpcapd.c, and consider bringing that into DPDK core, where the dependancy/API drift can be better dealt with within the DPDK CI. The tcpdump/wireshark/libpcap interface is then rpcap protocol to localhost or Unix domain socket. Maybe that also facilitates better JIT/adaption of pcap filters into DPDK runtime, which might also involve pushing filters down to smart NICs.

The more I think about it, the more this makes more sense.
Rather than throw a plugin at libpcap and hope the DPDK user/developer/operator has the most recent one, put this functionality with DPDK. I suggest copying libpcap/rpcapd [yes, fork it] to DPDK, along with just enough of libpcap so that you can statically compile an "dpdk-pcapd" as part of DPDK. That allows DPDK to evolve its capture mechanism(s), optimize your BPF (or another thing), deal with any multi-threading, locking or scaling issues, and also deal with any permissions issues that might arise.

vjardin · 2026-03-21T18:16:11Z

How to get high performances with your proposal ?

Dataplanes like DPDK expose unstable APIs that change across releases. Compiling backends directly into libpcap ties the two release cycles together. Add a generic plugin loader (pcap-plugin.c) that discovers external capture backends at runtime, decoupling libpcap from backend release cycles. Each backend ships as a pcap-*.so shared module. The loader scans plugin directories, loads each via the centralized pcapint_load_code() API (extended from Windows-only to Unix with dlopen/dlsym), looks up a "pcap_plugin_entry" symbol, checks the ABI version, and dispatches findalldevs/create calls through it. A set of pcap_plugin_* accessor functions (pcap/pcap-plugin.h) provides plugins a stable ABI without exposing pcap-int.h internals: handle allocation, ops registration, field getters/setters, BPF helpers, and device enumeration. Security model, modeled after OpenSSL provider loading: A survey of PAM, NSS (glibc), GStreamer, OpenSSL (providers), and Mesa shows they all converge on the same model: a hardcoded directory as the default, with environment variable overrides ignored under elevated privileges. None perform lstat(), ownership checks, or symlink validation. - $PCAP_PLUGIN_DIR is read through secure_getenv() on glibc, with fallbacks for BSD (issetugid), Linux without glibc (getauxval AT_SECURE), and other Unix (uid/euid comparison). Under elevated privileges the env var is automatically ignored, matching how OpenSSL handles OPENSSL_MODULES and how ld-linux.so handles LD_LIBRARY_PATH. - The hardcoded plugin directory (PCAP_PLUGIN_DIR, default ${libdir}/pcap/plugins) is always scanned. - Filesystem permissions on the plugin directory are the security boundary, same as PAM, NSS, OpenSSL, and Mesa. - plugindir is exposed in libpcap.pc so external projects can query the install path at build time with: pkg-config --variable=plugindir libpcap This follows the GStreamer model (pluginsdir in gstreamer-1.0.pc). Signed-off-by: Vincent Jardin <vjardin@free.fr>

Telecom-grade dataplanes (radio-based routers) need nanosecond-accurate timestamps to measure inter-packet jitter and verify hardware pacing. Default host timestamps (software clock at packet delivery) give microsecond-level accuracy at best, which is insufficient for sub-microsecond scheduling verification on 10G+ links. Modern NICs (ConnectX-6 Dx, ConnectX-7) stamp each received packet with a hardware clock at wire arrival time. The kernel exposes this via AF_PACKET's PACKET_TIMESTAMP / SOF_TIMESTAMPING_RAW_HARDWARE, and tcpdump accesses it with -j adapter. External capture plugins need the same mechanism. Add two accessors to the plugin API: pcap_plugin_get_tstamp_type() — read the type the user requested pcap_plugin_set_tstamp_type_list() — advertise supported types Plugins call set_tstamp_type_list during create so that pcap_list_tstamp_types (tcpdump -J) reports the available clock sources. During activate, get_tstamp_type tells the plugin whether the user asked for PCAP_TSTAMP_ADAPTER (NIC clock, synced to real-time), PCAP_TSTAMP_ADAPTER_UNSYNCED (raw NIC clock), or PCAP_TSTAMP_HOST (default software clock). The plugin then configures its backend accordingly. Signed-off-by: Vincent Jardin <vjardin@free.fr>

vjardin · 2026-03-23T17:33:16Z

Based on a taxonomy that @maxime-leroy shared with me in DM, I did simplify and limit the security surface of the plugin. See the latest update.

Moreover, I tried to enrich all the cases a DPDK plugin could need.

The plugin API lacked accessors for several pcap_t options that tcpdump (and other consumers) set before pcap_activate(): promiscuous mode, buffer size, immediate mode, and timestamp precision. Without these, a plugin backend could not honor user-requested capture settings. Similarly, plugins had no way to advertise supported timestamp precisions or data link types back to libpcap, so pcap_list_tstamp_precisions() and pcap_list_datalinks() would return empty results for plugin-backed devices. Plugins also could not provide a selectable file descriptor for event-driven callers. New getters (plugin reads during activate): pcap_plugin_get_promisc() pcap_plugin_get_buffer_size() pcap_plugin_get_immediate() pcap_plugin_get_tstamp_precision() New setters (plugin advertises capabilities): pcap_plugin_set_tstamp_precision_list() pcap_plugin_set_datalink_list() pcap_plugin_set_selectable_fd() Signed-off-by: Vincent Jardin <vjardin@free.fr>

vjardin · 2026-03-26T00:47:33Z

The ci seems to be flakky : choco times out or does not prepare properly the Windows environment ; s390x timeout on an unrelated topic.

vjardin · 2026-03-26T00:48:17Z

@guyharris : please, can I get your review on it ?

guyharris · 2026-03-26T01:01:15Z

The ci seems to be flakky : choco times out or does not prepare properly the Windows environment

AppVeyor isn't the best. At one point I looked at another one - I think it was Cirrus CI - but they didn't have anything with Visual Studio pre-installed, and having to install it every time would impose a significant hit to CI time. Maybe it's changed, or maybe there's a way to get it done once and reuse it.

s390x timeout on an unrelated topic.

For some reason it's currently prone to timeouts in the filter tests. The only thing noteworthy about it is that it's big-endian (which is a feature, not a bug, until the last big-endian machine running anything UN*Xy is shut down, and IBM doesn't seem to be in a hurry to get rid of either z/Architecture or Linux on Z); it's not as if those machines are exactly tiny machines with slow CPUs.

Maybe there's some issue with big-endian machines in the filter code.

guyharris · 2026-03-26T01:02:29Z

The ci seems to be flakky : choco times out or does not prepare properly the Windows environment

AppVeyor isn't the best. At one point I looked at another one - I think it was Cirrus CI - but they didn't have anything with Visual Studio pre-installed, and having to install it every time would impose a significant hit to CI time. Maybe it's changed, or maybe there's a way to get it done once and reuse it.

I've hit "re-run incomplete" on the Appveyor build.

guyharris · 2026-03-26T02:25:18Z

For some reason it's currently prone to timeouts in the filter tests. The only thing noteworthy about it is that it's big-endian (which is a feature, not a bug, until the last big-endian machine running anything UN*Xy is shut down, and IBM doesn't seem to be in a hurry to get rid of either z/Architecture or Linux on Z); it's not as if those machines are exactly tiny machines with slow CPUs.

Maybe there's some issue with big-endian machines in the filter code.

Or maybe not, given that it's not reliably failing on any given test; it might just be random luck.

vjardin · 2026-03-26T08:56:59Z

Or maybe not, given that it's not reliably failing on any given test; it might just be random luck.

Can we increase the timeout ?

How to get detailed logs/traces ?

infrastation · 2026-03-26T11:31:35Z

Complete CI logs are available in respective CI checks associated with the pull request, if the obvious needs to be stated.

linux-s390x is hosted by OSU OSL, which are in the process of moving the data centre (donations are welcome to cover the expenses), so some flakiness is expected. If this persists, it will be dealt with later as and if required.

One more time, releasing libpcap 1.11.0 is a more important and more urgent problem to solve compared to fixing of DPDK support, so these changes will have to wait until time is good for merging.

infrastation · 2026-03-26T21:34:54Z

Apparently, the donations page is now here (and requires manual input to donate specifically to OSL).

vjardin · 2026-04-02T16:55:46Z

@infrastation : Denis, fyi, the following has to be selected:

When will the release 1.11.0 be tag'd ?

Meanwhile, can someone confirm the approach of this pull request ? We could use it to clean up the unsupported DPDK case of the libpcap.

infrastation · 2026-04-03T15:07:28Z

A few urgent problems are in the way of 1.11.0 release, this is being worked on.

Add libpcap as a meson wrap subproject with three patches on top of upstream commit bac2884b. These patches implement the plugin loader proposed in the-tcpdump-group/libpcap#1659: - runtime plugin loader for external capture modules - timestamp type accessors for adapter code - complete accessor API for tcpdump feature parity The meson.build exposes a plugindir variable via declare_dependency() so consumers can install plugins in the right location. Signed-off-by: Robin Jarry <rjarry@redhat.com>

vjardin · 2026-04-15T05:16:16Z

thanks @rjarry for the early wrap integrations on DPDK/grout.

Add libpcap as a meson wrap subproject with three patches on top of upstream commit bac2884b. These patches implement the plugin loader proposed in the-tcpdump-group/libpcap#1659: - runtime plugin loader for external capture modules - timestamp type accessors for adapter code - complete accessor API for tcpdump feature parity The meson.build exposes a plugindir variable via declare_dependency() so consumers can install plugins in the right location. Signed-off-by: Robin Jarry <rjarry@redhat.com>

The packet capture feature needs libpcap with the plugin loader API proposed in the-tcpdump-group/libpcap#1659 which is not yet merged upstream. Add libpcap as a meson wrap subproject with three patches on top of upstream commit bac2884b implementing the runtime plugin loader, timestamp type accessors and a complete accessor API for tcpdump feature parity. The meson.build exposes a plugindir variable via declare_dependency() so consumers can install plugins in the right location. Signed-off-by: Robin Jarry <rjarry@redhat.com>

vjardin · 2026-05-27T20:40:10Z

Hi,

Sorry for not being "aware" of the release trains of libpcap, but what is the landing/when for the release for a possible merge of this pull request (assuming ok one) ? Behind the hood, it is to sync with grout and DPDK communities and to avoid the risks of "local" patches.

thank you,

infrastation · 2026-05-29T01:24:14Z

Thank you for waiting Vincent. libpcap 1.11.0 has not been released yet because it got blocked by libpcap 1.10.7, which has not been released yet because it is still blocked by important bug fixes that took longer than expected. This is going to take a bit longer.

vjardin mentioned this pull request Mar 20, 2026

dpdk: add pdump capture module for DPDK secondary process #1656

Closed

infrastation added the DPDK Data Plane Development Kit label Mar 20, 2026

vjardin force-pushed the vj_dpdkplugins branch from f97d481 to 99dfd24 Compare March 20, 2026 23:45

vjardin force-pushed the vj_dpdkplugins branch 2 times, most recently from bf4e767 to 577f370 Compare March 21, 2026 00:05

guyharris reviewed Mar 21, 2026

View reviewed changes

Comment thread pcap-plugin.c Outdated

vjardin force-pushed the vj_dpdkplugins branch from 577f370 to 4a80041 Compare March 21, 2026 08:50

vjardin added 2 commits March 23, 2026 18:01

vjardin force-pushed the vj_dpdkplugins branch from af3d103 to e38cb3f Compare March 23, 2026 17:30

vjardin force-pushed the vj_dpdkplugins branch from 7e06ef7 to e38cb3f Compare March 23, 2026 23:43

vjardin force-pushed the vj_dpdkplugins branch from e38cb3f to bf99484 Compare March 25, 2026 15:33

rjarry mentioned this pull request May 13, 2026

tcpdump / libpcap - packet traces - pcap-grout.so - WIP DPDK/grout#565

Open

Conversation

vjardin commented Mar 20, 2026

Uh oh!

guyharris commented Mar 20, 2026

Uh oh!

guyharris commented Mar 20, 2026

Uh oh!

fxlb commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcr commented Mar 20, 2026

Uh oh!

rjarry commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

infrastation commented Mar 20, 2026

Uh oh!

vjardin commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

fxlb commented Mar 21, 2026

Uh oh!

vjardin commented Mar 21, 2026

Uh oh!

vjardin commented Mar 21, 2026

Uh oh!

mcr commented Mar 21, 2026

Uh oh!

vjardin commented Mar 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vjardin commented Mar 23, 2026

Uh oh!

vjardin commented Mar 26, 2026

Uh oh!

vjardin commented Mar 26, 2026

Uh oh!

guyharris commented Mar 26, 2026

Uh oh!

guyharris commented Mar 26, 2026

Uh oh!

guyharris commented Mar 26, 2026

Uh oh!

vjardin commented Mar 26, 2026

Uh oh!

infrastation commented Mar 26, 2026

Uh oh!

infrastation commented Mar 26, 2026

Uh oh!

vjardin commented Apr 2, 2026

Uh oh!

infrastation commented Apr 3, 2026

Uh oh!

vjardin commented Apr 15, 2026

Uh oh!

vjardin commented May 27, 2026

Uh oh!

infrastation commented May 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

6 participants

fxlb commented Mar 20, 2026 •

edited

Loading

rjarry commented Mar 20, 2026 •

edited

Loading

vjardin commented Mar 20, 2026 •

edited

Loading

vjardin commented Mar 21, 2026 •

edited

Loading