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

[Guy Harris <gharris () sonic net>]

On Oct 2, 2026, at 4:10 PM, Michael Richardson <mcr () sandelman ca> wrote:

> Guy Harris <gharris () sonic net> wrote:
> > 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 they wanted more detailed access to the packets, they wanted to
> be able to use multiple threads.  Like, an initial classifier that looks for
> 5-tuples, then passes that packet to a thread that deals with that particular
> flow.   I think, that this would permit the different threads to be able
> to release the buffers back to the kernel asynchronously to each other.


It's the sort of thing that Linux-specific and ordinary-network-device-specific code could do with the result of 
pcap_fileno(), but It Would Be Nice if libpcap could offer a common API for that (if the interface doesn't support it, 
calls would just return "sorry, I don't know how to do that"). There's a pull request for such an API for Linux - 
https://github.com/the-tcpdump-group/libpcap/pull/869 - with discussion of support for other platforms.

> > 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;
>
> Exactly, it would be ideal.
> There is a fair bit of stuff to coordinate when trying to roll file names,
> overwritting the oldest files, etc.

I'd imagine in "tcpdump done right" the output files would be managed by the top-level non-privileged process. If 
another process is doing the writes to the capture file, it'd send a "rotate the files" message to the top-level 
process and get back a file descriptor/HANDLE and turn that into a stream to which to write.

> > 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).
>
> I know how we got rpcap, but I dislike that it wasn't just "ssh host rpcap".

WinPcap 3.0 was the first release with rpcap support, and that looks as if it dates back to 2003, so SSH *was* 
available, but...

> I know... popen("ssh..") is only just becoming common on windows, and that
> was just hard to very difficult ten+ years ago.

...SSH servers for Windows, perhaps not so much.

> Clearly, "rpcapd" using libpcap can use "plugins".

As long as they're sufficiently trusted plugins that they don't expose an rpcap attacker to a target-rich environment.

> So, not one dumpcap per device, but one dumpcap per wireshark instance.

Yes, that lets it write all the packet to a single pcapng file.

> > Once libpcap has full pcapng support, tcpdump should probably allow
> > multiple -i options, just as TShark and dumpcap do.
>
> Agreed.
> Although, I think might be a win if one actually captures in multiple
> processes, writes to multiple files, and then combine them afterwards.

Yeah, I've thought of that as an alternative to the current dumpcap model, so that you can get more CPU parallelism.

> I'm saying that calling dlopen() shouldn't be required: do that at link time.

So something like current libpcap, but with:

1) the create and findalldevs routines being in external libraries;

2) the autotools/CMake stuff looking for those external libraries rather than for the OS support that our current 
modules use.

For systems where "everything is a package", such as most if not all Linux distributions, this works for all modules 
that become packages in the system.  Adding a new module just involves a small change to pcap.c and changes to 
configure.ac and CMakeLists.txt.

For the *BSDs, it works for modules that become core OS components. For packages, the user might have to rebuild 
libpcap themselves.

For macOS, the same applies. Apple have their own modules in their libpcap, but they can just keep them around.

For Windows, it's like macOS, except that Npcap *is* a third-party package, and the Npcap people can bundle plugins.

So this appears to address the DPDK issue, at least for Linux, and possibly lets us hand off some of the existing Linux 
modules to another group if they're interested.

> > 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.
>
> cp pcap-linux.c pcap-linux-tpacketv2.c
> mv pcap-linux.c pcap-linux-tpacketv3.c
> .. edit until they are two things, both internal "plugins"

But that means that "eth0" would have to choose which module to use at activate time, rather than create time, as it 
doesn't depend on the device name, it depends on whether immediate mode was requested.


_______________________________________________
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