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

[Vadim Goncharov <vadimnuclight () gmail com>]

On Mon, 12 Oct 2026 11:19:03 +0200
Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:

> 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

No, Windows uses it's own mechanisms, Denis' proposal was conceptual
("socket" as "bi-directional communication channel", not as "UNIX socket")
rather than exact technology, but why SCM_RIGHTS is needed? It could be e.g.
just opening a named pipe (and Windows has named pipes, but not in
filesystem).

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

Instead of reinventing ad-hoc wheel, CBOR [RFC 8949] is a good fit - it is:
* standard [STD 94]
* simple (just few hundreds line of C, or less if you do not
  need general interoperability for partial implementation)
* and yet extensible (can be described in two words as "binary JSON with
  extensions").

> or to reuse netlink for serialization?

Why to use this non-crossplatofrm overcomplicated poorly-documented bloat
which does not conform even to it's own RFC 3549 ?


-- 
WBR, @nuclight
_______________________________________________
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