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

[Denis Ovsienko <denis () ovsienko info>]

On Mon, 12 Oct 2026 03:22:25 -0700
Guy Harris <gharris () sonic net> wrote:

> On Oct 9, 2026, at 3:12 PM, Denis Ovsienko <denis () ovsienko info>
> wrote:
>
> > In this case each plugin would be able to crash, hang, run OOM, set
> > and trip setrlimit(2), configure, receive and handle signals, set
> > timers and atexit(3) handlers, override standard library calls,
> > link with 3rd-party libraries, experience/mitigate/fix its own
> > vulnerabilities, elevate and drop privileges, run containerised,
> > under debugger/strace/profiler etc. -- all entirely at its end of
> > the "socket".  
>
> So the plugin is an executable running in a process separate from the
> process using libpcap rather than a loadable object running in the
> process using libpcap?

Yes.

> This sounds similar to Wireshark extcaps, although those are oriented
> towards the captured packets being consumed by reading a file. That
> works for Wireshark and TShark, but it wouldn't work for all
> applications (and doesn't work very well for TShark being run without
> writing to a file, i.e. capture packets and print the dissection,
> like tcpdump without -w).

A common pattern here is that two processes exchange data instead of
executing each other's code.

> Either that, or the plugin is loaded into the address space, but just
> sets up the external process, or sets up the external process and
> passes the packets it delivers to libpcap's caller.

libpcap could launch some plug-in processes if a specific use case works
much better this way, but that should not be the default approach.  One
use pattern could be that an application that /can/ provide a source of
packets opens its "socket" at start, and if days later someone needs to
capture the packets to debug something, that would not require
restarting the application, and stopping the capture would not require
stopping the application.

If you consider bpf(4) as an archetype of a module, /dev/bpf is by
default available regardless of whether any process is using it, and
processes do not have to set up or to tear down BPF in general, only
their specific session of using the OS facility.  One exception has
been the AIX-specific bpf_load() in pcap-bpf.c, but it looks a
violation of layers even on paper and may be dead code in present-day
AIX.  I do not have any means to test it.

-- 
    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