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

[Guy Harris <gharris () sonic net>]

On Oct 2, 2026, at 1:51 PM, Vadim Goncharov <vadimnuclight () gmail com> wrote:

> On Fri, 02 Oct 2026 09:56:43 -0400
> Michael Richardson <mcr () sandelman ca> wrote:
>
> > Vadim Goncharov <vadimnuclight () gmail com> wrote:
> >
> > > 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.

It's... a bit more complicated.

On most UN*Xes, USB capture is done through libpcap, which has a module for capturing on Linux and supports capturing 
through the BPF capture mechanism (!) on FreeBSD and Darwin/macOS.

On Windows, USB capture, like remote capture via SSH, is done through a *non*-libpcap-based mechanism that involves 
running capture programs called "extcaps". Those are run by Wireshark/TShark but are connected to dumpcap, so they feed 
stuff to dumpcap over a pipe. (The last time I looked at this complicated mechanism, it was done so that the extcaps 
wouldn't be run with dumpcap's privileges, as that may be more privilege than they need.)

At some point, when libpcap adds support for remote-capture modules, it could have a module added to support 
"ssh+tcpdump" or... capture URL schemes.
_______________________________________________
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