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

[Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: "Robin Jarry" <rjarry () redhat com>
>
> Date: Mon, 12 Oct 2026 11:19:03 +0200
>
> Hi Denis,
>
> Denis Ovsienko, Oct 10, 2026 at 00:12:
> > Consider if the interfaces were arranged as follows:
> >
> > [libpcap]-[socket]-[plugin]-[callable API]-[external packet source]
> >
> > Here the "socket" for the sake of argument could be a Unix domain 
> > socket or a named pipe or the rpcap protocol or a System V IPC message 
> > queue, let's for now not compare these alternatives in detail, but 
> > focus on two key properties.  Which are that the "socket" has an ID 
> > and can provide a bi-directional communication channel between two 
> > different processes.
>
> This is an interesting proposal. You're proposing to make the control 
> socket + ring buffer the official way to capture third party backend. 
> This would be a great fit for grout since this is precisely what we 
> already have:
>
> https://github.com/DPDK/grout/blob/main/modules/infra/api/gr_capture.h
>
> We could adapt/rework this API to go in libpcap.
>
> > It could even be a pair of "sockets" (one for the control requests and 
> > responses and another for the packets), or a socket and a ring buffer, 
> > as you describe.  It could use a subset or a super-set or a new 
> > version of the rpcap protocol, or its own protocol.  The plugin end of 
> > such a "socket" could be a standalone process or a function in 
> > a larger program.  These are secondary details.
>
> As I already said, sending the packets in a socket (UNIX or otherwise) 
> is not an option because it requires system calls. We "could" run an 
> intermediate processes that reads from a shared memory ring and copies 
> to a socket but that seems extraneous and we'd prefer to reduce the 
> number of moving parts.
>
> However, I don't know if sharing an anonymous ring-buffer [1] in memory 
> is possible with all backends that libpcap supports (is there file 
> descriptor sharing over SCM_RIGHTS [2] on windows?). There could be 
> different options to allow sharing over POSIX shared memory segments [3].
>
> [1] https://www.mankier.com/2/memfd_create
> [2] https://www.mankier.com/7/unix#Description-Ancillary_messages
> [3] https://www.mankier.com/3p/shm_open
>
> As for the control API, anything is on the table. Whatever will be 
> simpler for libpcap. Would you prefer an ad-hoc binary message protocol 
> or to reuse netlink for serialization?
>
> > Let's for the sake of argument say that plugins could create their 
> > "sockets" in /var/run/libpcap/, then basename(3) would identify 
> > a plug-in and every plug-in that managed to create a "socket" would 
> > automatically have a unique ID/namespace.  Compare this to loading 
> > pcap-foo1.so and pcap-foo2.so, each of which turns out to declare 
> > namespace "foo".  But that's a secondary detail as well.
> >
> > One key difference would be that from libpcap perspective the use of 
> > any plugin through a socket would follow the same general logic as has 
> > been implemented for network interface packet capture, which is an 
> > exchange of messages between libpcap and the OS kernel:
> >
> > libpcap (L): What is the list of you capture devices?
> > plugin (P): A, B and C.
> > L: I am going to capture on B.
> > P: Acknowledged.
> > L: And the capture parameters are as follows...
> > P: Acknowledged.
> > L: Start now.
> > P: packet 1, packet 2, packet 3, ...
> >
> > Another key difference would be that besides the "socket" the two 
> > processes would be mostly independent: neither of the two would need 
> > to be aware of the callable API, any implementation details or even 
> > the programming language of the other.
>
> > 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".  Which means in a way that does not affect other plugins, 
> > libpcap (other that "socket"-related error handling) or the process 
> > that uses libpcap.  The only increase in the attack surface would be 
> > the "socket" protocol, as far as it seems to me.
> >
> > Also, as mentioned in the pull request, each plug-in would be free to 
> > decide how many threads and processes to involve, which could make it 
> > easier to filter packets at high rate before these reach the plug-in 
> > end of the "socket".  This would align with libpcap design, which is 
> > to discard as many unwanted packets as early as possible.
> >
> > However, the current design does not pursuit the goal of capturing all 
> > packets at high rates -- there are other solutions for that, which 
> > typically use specialised hardware and software.  libpcap can consume 
> > multiple packets in one go under right conditions, but then it always 
> > processes one packet at a time, and improving that aspect could be 
> > a separate future development.
>
> I don't think that capturing 100G link at line rate is something 
> desirable. This looks more a case for port-mirroring or traffic sampling 
> but these use-cases have nothing to do with libpcap. We can table this 
> for later.
>
> Cheers,
>
> --
> Robin
>
> # Merchandise can be shipped only upon receipt of payment.
>
>
> --- End Message ---
_______________________________________________
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