tcpdump Mailing List

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

List Archives

Latest Posts

Re: RFC: a loadable plugin framework for external capture backends Vadim Goncharov (Oct 18)
/var/run is more portable (e.g. BSDs)

Why version in every message?

Format of other messages is not described...

What is this "sealing" ? And I do not see memfd_create() on OpenBSD; in
FreeBSD function is briefly described as:

The memfd_create() function creates an anonymous shared memory object,
identical to that created by shm_open() when SHM_ANON is specified.

Again, why every?

That's acceptable.

Re: RFC: a loadable plugin framework for external capture backends Vadim Goncharov (Oct 18)
Yes, according to Google, the primary functions used are:

CreateFileMapping(): Creates a file mapping object.
If you pass INVALID_HANDLE_VALUE instead of a real file handle, Windows backs the shared memory using the
system paging file (making it anonymous/non-persisted, similar to memfd_create()).
You can assign it a string name (making it a named shared memory object, similar to shm_open()) or leave it
unnamed and share...

pcap-int.h outside of libpcap Denis Ovsienko (Oct 18)
Hello all.

libpcap pull request [1] among other changes is going to make it more
difficult to do a wrong thing (that is, to include pcap-int.h from
any source tree that is not libpcap) without realising it. This has
been an FAQ [2] for almost five years. If anybody is aware of a good
reason to delay this change, please make it clear, otherwise it is
going to be merged soon.

1: https://github.com/the-tcpdump-group/libpcap/pull/1789
2:...

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

Re: exit status codes semantics in tests Denis Ovsienko (Oct 16)
DLT name-to-number translation requires more attention. I do not
remember if the choice of EX_USAGE instead of EX_DATAERR achieved some
specific useful effect or just stayed this way since early revisions.
This translation is not the main focus of this test program, since
recently there is another test program with separate tests that cover
this corner of the API specifically. filtertest.c may not require a
different status code for DLT, but it...

Re: exit status codes semantics in tests Guy Harris (Oct 16)
...

I.e, EX_USAGE should not be used for any cases where a command-line argument is *intentionallY* made incorrect in
TESTrun because the program is being used to test to make sure that a particular argument fails - whether it's an
invalid filter expression for the particular link-layer type (or for *any* link-layer type), or to make sure that an
invalid string name for a link-layer type returns -1 from...

Re: exit status codes semantics in tests Denis Ovsienko (Oct 16)
Yes, pretty much. I used something that at the time I thought was 100%
commonplace. The set of values could be mapped 1:1 to another, purely
internal set, and the build-time check for sysexits.h could be dropped.
Meanwhile implementing the current revision has made some silent bugs
manifest at least.

[...]

If TESTrun has received EX_USAGE from a test program, it means a bug in
TESTrun because every command line is an internal product of...

Re: exit status codes semantics in tests Guy Harris (Oct 16)
So the problem is, at least in part, that the BSD <sysexits.h> header (also adopted by at least some C libraries used
in Linux distributions) is that, as I remember, it started out as error exits for sendmail (or maybe even
delivermail!)), and thus doesn't include all the exit codes that we might want for our tests.

This means that an attempt to have all the test exit codes "make sense" may fail because it's...

exit status codes semantics in tests Denis Ovsienko (Oct 16)
Hello all.

This started as a comment for libpcap pull request 1787, but it seems
to be useful beyond the scope of the pull request, so let me post this
to the list in case it helps anyone to work on new libpcap tests.
--------------------------------------------------------------------

The current use/non-use of EX_DATAERR (65) and EX_OK (0) in filtertest,
translatetest and enumeratetest, as well as of EX_NOINPUT (66) in
filtertest, has to...

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

More Lists

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