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

[Vadim Goncharov <vadimnuclight () gmail com>]

On Fri, 02 Oct 2026 09:56:43 -0400
Michael Richardson <mcr () sandelman ca> wrote:

> Vadim Goncharov <vadimnuclight () gmail com> wrote:
>     >> I recognize that these are two different but very similiar things,
>     >> and I am unclear to what extent the Linux kernel treats them in
>     >> similiar code paths. I believe that VPP, DPDK, etc. use AF_XDP to get
>     >> packets from the kernel, and send them back to the device.  (I think
>     >> that there are also still vendor proprietary paths?)  
>
>     > No, DPDK works in completely different way. An interface is detached
>     > from kernel, it's DMA buffers are allocated inside huge pages
>     > (non-swappable), driver (userland one!) places packets directly there,
>     > and main infinite loop on each logical core polls that buffers eating
>     > 100% CPU even if there is no traffic. That is, network interface
>     > disappears from system so there is nothing to put into `tcpdump -i` -
>     > that's why entire subject is raised.  
>
>     > VPP has different backends, but usually DPDK one is chosen.  
>
>     > AF_XDP, on the other side, is from kernel side and kernel driver,
>     > interface exists.  
>
> So, the DPDK thing is completely different frm XDP.
> I didn't know.  But, is DPDKI coding NIC registers directly?
> I didn't think that, but it *is* speaking the native/hardware ring buffers,
> is what you are saying?

Yeah.

> Thus, there is no "standard" ring buffer code in DPDK today :-(

It "is" from point of view of upper-level libraries in DPDK - mbuf/rings
layout changes rarely. That's all is internal to DPDK, however.

>     >> 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.  Particularly for the
>     >> "sudo" case.  
>
>     > 4. On *BSD systems there is /dev/bpf* files - e.g. on my FreeBSD I
>     > just add my user to have gid=0, do `chmod g+r /dev/bpf*` and now
>     > tcpdump runs from my user without any "sudo" or binary tweaking. Don't
>     > know if OpenBSD changed something here.  
>
> I think that OpenBSD isolates all of the print_* functions in tcpdump into an
> even less privileged process than the user.

In the last times that have come, when even an ordinary user (for instance,
their browser) is targeted by hacking attempts, that makes sense, too. However
this is likely second priority as out of scope for the topic raised.

>     >> 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.
>     >> Maybe a specific executable that can do this, returning JSON, would
>     >> satisfy.  
>
>     > s/JSON/CBOR/  
>
> Oh, sure.  I way prefer CBOR too, but I see some value in a human being able
> to read this output.

Then EDN is to come!

>     >> > - 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.  
>
>     > AFAIR Wireshark already does capturing via separate process always
>     > (dumpcap).  
>
> I didn't think it always did that.
> I guess if it's only one plugin per pcap_t, then wireshark could (maybe it
> does) start a new dumpcap if it needs to change.

Likely yes. But since addition of different capture types directly in
selection window, like USB, remote capture via SSH, etc., it fits proposed
solution nicely.

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