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

[Guy Harris <gharris () sonic net>]

On Oct 1, 2026, at 1:33 PM, Michael Richardson <mcr () sandelman ca> wrote:

> https://adam.pages.nic.cz/dns-probe/Running.html does not, AFAIK,
> use libpcap for these preformance reasons, offering TPACKET or DPDK integrations.

libpcap runs atop TPACKET on Linux, so presumably the performance problem are either in pcap.c or pcap-linux.c. Any 
idea what they might be?

> I think that the rpcap protocol *itself* could be better, mind you.

Yes, that's why I added versioning support (via some hackery to allow version information to be exchanged without 
breaking older client or server implementations).

> Yes, but what privileges libpcap/user needs to talk to DPDK is not really the
> concern.
>
> 1. some systems (distros) setuid on tcpdump.  I've never liked this, but I
>   understand it.

It does have the convenience that you can Just Run Tcpdump to capture packets.

It has the disadvantage that it runs tcpdump with elevated privileges.

> 2. some systems (distros) use capabilities, set on the tcpdump executable.

Better, if you *have* those capabilities (that's a Linuxism) and they suffice for capturing on the device in question 
(which is, alas, *not* true for capturing on USB buses, for example).

> 3. but, many of us prefer to just sudo.

OK, I guess.  (I just rely on Wireshark's ChmodBPF to make all the BPF devices usable.)

> I'd like to do more to split things up while not hurting performance too
> much.   OpenBSD has done some of this, but in it's own way.  I think that
> they are more concerned about the security around the dissectors, and I want
> that isolation as well.

Personally, I like the idea of:

        tcpdump (or TShark or Wireshark or...) is a front-end program;

        the dissectors run in a separate, possibly sandboxed, process, with the front-end doing whatever file opening 
is necessary;

        the capturing privileges are even *further* isolated, so the front-end program doesn't require them.

> > - Discovery. Where are plugins found, and in what order? (The PR uses    a
> > single compiled-in directory plus an environment override that is
> > dropped under elevated privileges, like ld.so with LD_LIBRARY_PATH.)
>
> Yes, and that's where I begin to get afraid, because features were added to
> ld.so, and sometimes they interacted in curious and insecure ways.
> There may be *ld.so* options that affect us even.

Plus, ld.so isn't a single program, it's several programs that do similar things with ELF files, plus there's one 
called just "dyld" that deals with Mach-O files, and then there's what mechanism Windows uses for dynamic loading of 
libraries and plugins, so it's not as if "understanding what's safe" is necessarily a problem that has a universal 
solution for all platforms libpcap supports.

> > - Enumeration vs selection. Do plugins only contribute devices to
> > pcap_findalldevs(), or can they intercept arbitrary device names?
>
> > Our
> > preference: a plugin owns a namespace prefix (e.g. "grout:") and    is
> > consulted only for names in its namespace. This makes "how do    multiple
> > plugins coexist" answerable by construction.
>
> So, the devices would not show up for --list-interfaces, but if one does -i grout:dpdp/selector
> then it loads libpcap-dpdp-plugin.so, and passes "selector" to it?
>
> The alternative is that tcpdump has a --load-plugins dpdk,vpp ... and if that
> shows up before --list-interfaces, then it enumerates the devices from those
> plugins?
>
> I would prefer --list-interfaces *NOT* attempt to load all the plugins in the
> default directory, and ask them for a list :-)
>
> That would otherwise be the best thing for users.
> That's mostly what I think wireshark UI users would want.

Tshark could have the same command-line options; Wireshark would probably have it as a preference.

> Further, all of this probably has to work when it's rpcapd (under wireshark,
> from a windows desktop user...) that is doing this.
> That's where having multiple plugins loaded might be required.
>
> *The rpcap client becomes a plugin*

The rpcap should, at minimum, plug into a similar interface as the ones that local capture modules already do. That 
way, other over-the-wire capture mechanisms could be supported.

Making them plugins allows Somebody Else to support them (or, in the case of rpcap, allows a separate project to handle 
both the rpcap: handler and the rpcapd daemon, even if it's a Tcpdump Group project).

> > - Parallelism / pre-emption. Denis asked how multiple plugins work in
> > parallel or pre-empt each other. Our proposed answer: they do not
> > interact at all. Each pcap_t is bound to exactly one backend chosen    at
> > create/activate time; plugins never see each other's handles.    Anything
> > else should be out of scope for a first version.
>
> Yes, that's good.
> I'm not finding a good reason for more than one plugin would exist per pcap_t.
> I'm sure that there are programs that use more than one pcap_t, and quite
> possibly they might need to have different plugins.

Wireshark's dumpcap (which does all the capturing for Wireshark and TShark) can capture on multiple devices, so it can 
have more than one pcap_t open.

Once libpcap has full pcapng support, tcpdump should probably allow multiple -i options, just as TShark and dumpcap do.

> > - ABI. Plugins must not see pcap-int.h. The proposal is a versioned,
> > narrow accessor API (pcap_plugin_*) so libpcap internals stay    private
> > and the plugin ABI is explicit and stable.
>
> Agreed.
> No public structures ideally, only getters/setters?

Including a getter/setter for a pointer to module-private data.

> I'd like _tcpdump_ to drop any privilege if it is told to load a plugin.

I'd ideally like *tcpdump* not to run with any privileges, other than what privileges it gets by having a descriptor 
handed to it - or, rather, to libpcap - by a small simple program that runs with elevated privileges (see above).

> > - Off by default. The loader should be a compile-time option, disabled    by
> > default, as fxlb already requested on the PR. Distributions and
> > dataplane projects opt in; a stock libpcap build carries none of it.
>
> Given this, does the plugin actually need to be loadable?

So you're saying that plugins should be bundled *by the OS distributor* and wired in, rather than allowing 
outside-of-libpcap projects *not* bundled by the distributor to be plugged into libpcap?

If so, that might work for most cases with Linux distributions, most of which don't seem to draw a strong distinction 
between "core OS" and "packages". It *does* mean that the libpcap package would have more dependencies.

It might not work so well for the *BSDs, most of which have a "core OS" separate from the package collection, and that 
include libpcap in the "core OS". That includes macOS ("CupertinoBSD"), which, being a commercial OS, may have 
third-party *binary-only* libpcap extensions, which would require a standardized *ABI*. (macOS is one reason why I try 
to make sure libpcap never changes its ABI other than, perhaps, carefully dropping routines from the API/ABI over time, 
as long as they've been deprecated before their disappearance.)

> > - No privileged loading. Since the motivating backends need no    elevated
> > privileges (see section 2), libpcap could refuse to load    plugins while
> > running with elevated privileges, or drop those    privileges first and
> > only proceed if the drop succeeded. A single    tcpdump binary could still
> > do `tcpdump -i eth0` (opens a raw socket,    then drops) and `tcpdump -i
> > grout:p0` (no privileges needed).
>
> yes, I think everyone is in agreement here.
> I don't know if that will work for wireshark or other things.

Wireshark doesn't, in theory, need to be run with elevated privileges. (At one point, Gerald Combs had a comment, 
somewhere, in ALL CAPS, saying something such as "WIRESHARK HAS N MILLION LINES OF CODE. DO NOT RUN THEM AS ROOT." 
tcpdump has fewer lines, but I wouldn't run *it* as root, either.)

Dumpcap may need to run with elevated privileges; some Linux distributions allow the user to select that at 
installation time. (Unfortunately, the only elevated privileges that will let you monitor USB messages are "run as 
root", so that would requite set-UID root.)

> > - Trusted location only. Plugins load only from a root-owned,
> > non-user-writable directory; the environment override is ignored    under
> > elevated privileges, exactly as ld.so treats LD_LIBRARY_PATH.
>
> Well, if libpcap drops any privileges it might have had the moment
> --load-plugin is seen (but, before acting on it), then actually, this is moot.

I'm not sure *libraries* should drop privileges on their own, as the program may be running with elevated privileges 
for other reasons.

> > To Denis's concern that a framework nobody uses, or one whose plugins become
> > TTG's responsibility, would be an expensive mistake: we agree, and we think
> > the framework should be designed so that no plugin is ever TTG's
> > responsibility. Plugins live in and are maintained by their own projects
> > (grout being a concrete, active example). Inside libpcap the recurring cost
> > is just the loader and the accessor ABI. If we keep the ABI narrow and the
> > loader off by default, that cost stays small and self-contained, and there
> > are no repository-boundary problems inside libpcap itself.
>
> The best way to amortize and test the cost of the ABI is for libpcap to use
> that ABI to do, for instance TPACKET_V3.   This might let us remove some of
> the TPACKET3 bug-work around code by having an "older" plugin.
> We have lots of #ifdef HAVE_LIBNL around nl80211 code, and maybe that could
> be a plugin.  Maybe we could drop TPACKET_V2, although that might not be much
> of a win.

Currently we use TPACKET_V2 for immediate mode, as I don't think there's a way to get "give me a packet as soon as it 
arrives, no batching" from TPACKET_V3.
_______________________________________________
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