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

[Guy Harris <gharris () sonic net>]

On Oct 1, 2026, at 1:49 PM, Bill Fenner <fenner () gmail com> wrote:

> Hi Robin, thanks for starting this discussion. I'd like to throw another
> idea into the mix: use the same API for plugins and "native" libpcap
> implementation.

That's pretty much what I had in mind for the capture module API.

One thing required for third-party plugins is API *stability*. The current API is still pcap-oriented, and would have 
to change in order to add capabilities for use with an API that can handle all of pcapng.

> A capture provider is a capture provider, and it could
> be one registered by code compiled into the library or dynamically loaded
> as a plugin - that is orthogonal.

Yes.

The big issue I see for third-party plugins is *security*, especially given that a lot of capture mechanisms require 
significantly elevated privileges. You don't want a hostile plugin running with root privileges if somebody types "sudo 
tcpdump -i malicious0".
_______________________________________________
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