tcpdump Mailing List

Covers the classic tcpdump text-based network sniffer and its libpcap sniffer library component.

List Archives

Latest Posts

Re: DOS Sniffer source code now available Denis Ovsienko (Oct 13)
On Tue, 13 Oct 2026 09:24:20 -0700
Gerald Combs via tcpdump-workers <tcpdump-workers () lists tcpdump org>
wrote:

Thank you for posting this Gerald. That's Token Ring Sniffer, which
subsequently added support for Ethernet. I might have seen an Ethernet
software-only version in action once, but it could be a false memory.

Anyway, I had a brief look at the published archives and the packet
filtering language syntax looks not entirely...

Re: RFC: a loadable plugin framework for external capture backends Denis Ovsienko (Oct 13)
Not quite exactly: rpcap was inherited as-is, and a plug-in protocol
can be designed more or less differently based on the lessons learned so
far. For example, in rpcap it is wrong to compile the filter at the
user end of the connection, but in a plug-in protocol it may be a
better design choice.

The receiver can be slower than the sender for any reason and for any
length of time. This problem is not new in libpcap and can use the same...

DOS Sniffer source code now available Gerald Combs via tcpdump-workers (Oct 13)

Re: RFC: a loadable plugin framework for external capture backends Robin Jarry via tcpdump-workers (Oct 13)

Re: RFC: a loadable plugin framework for external capture backends Denis Ovsienko (Oct 12)
Yes.

A common pattern here is that two processes exchange data instead of
executing each other's code.

libpcap could launch some plug-in processes if a specific use case works
much better this way, but that should not be the default approach. One
use pattern could be that an application that /can/ provide a source of
packets opens its "socket" at start, and if days later someone needs to
capture the packets to debug something,...

Re: RFC: a loadable plugin framework for external capture backends Denis Ovsienko (Oct 12)
Thank you for considering it.

The main point is to have, between libpcap and a libpcap plugin, only
an exchange of /data/ over a data-only interface, rather than to
execute the otherwise unaligned /code/ bases as one OS process.

That intermediate process/module/function would be your libpcap plug-in.
With the right design of the message exchange it would be entirely up
to you how it integrates with your software stack, so long as it speaks
and...

Re: RFC: a loadable plugin framework for external capture backends Robin Jarry via tcpdump-workers (Oct 12)

Re: RFC: a loadable plugin framework for external capture backends Vadim Goncharov (Oct 12)
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).

Instead of reinventing ad-hoc wheel, CBOR [RFC 8949] is a good fit - it is:
* standard [STD 94]
* simple...

Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 12)
No, but there are other mechanisms by which one process can pass a HANDLE (the Windows equivalent of a UNIX file
descriptor) to another process.

CreateFileMapping() creates a "file mapping object" and, if passed INVALID_HANDLE_VALUE as the "HANDLE for the file to
map", the object refers to anonymous (swap-space backed rather than file-backed) memory. and DuplicateHandle() can, as
far as I know, pass the HANDLE for the file...

Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 12)
So the plugin is an executable running in a process separate from the process using libpcap rather than a loadable
object running in the process using libpcap?

This sounds similar to Wireshark extcaps, although those are oriented towards the captured packets being consumed by
reading a file. That works for Wireshark and TShark, but it wouldn't work for all applications (and doesn't work very
well for TShark being run without writing...

Re: RFC: a loadable plugin framework for external capture backends Robin Jarry via tcpdump-workers (Oct 12)

Re: RFC: a loadable plugin framework for external capture backends Michael Richardson (Oct 09)
Denis Ovsienko <denis () ovsienko info> wrote:
>> I will attempt to collect some text into a single proposal that can be
>> criticized/ameneded/etc. I'll start from the beginning of this
>> thread.
>>
>> I will put that proposed text as a PR against the tcpdump-htdocs
>> github. I hope to get this out in the next week.

> Please do not take this discussion off-list, it...

Re: RFC: a loadable plugin framework for external capture backends Denis Ovsienko (Oct 09)
Please do not take this discussion off-list, it is too early to publish
anything on the web site.

Re: RFC: a loadable plugin framework for external capture backends Denis Ovsienko (Oct 09)
Thank you for posting an overview of the problem and the proposed
solution Robin.

There is an important point that Guy and Michael have already made a
few times in March in the pull request comments, and which has also
reemerged at least once in this thread. Which is that a data interface
between libpcap and a plug-in seems to fit the problem space better
than a callable API. Consider this paragraph:

[...]

[...]

What is says is that libpcap...

Re: RFC: a loadable plugin framework for external capture backends Robin Jarry via tcpdump-workers (Oct 09)

More Lists

Dozens of other network security lists are archived at SecLists.Org.