tcpdump Mailing List

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

List Archives

Latest Posts

Re: Accurate ECN support in tcpdump/libpcap Denis Ovsienko (Feb 06)
Helo all.

So, I have spent a few weeks researching this direction in more detail,
you can find the current results below.

[...]

This is a work in progress.

I tried modelling the arithmetic "tcphf" after tcp[] and realised that
tcp[] as it is now is not a good model because it has always been
IPv4-only (for the avoidance of doubt, the current tcp[tcpflags] is a
case of the same problem). Then I prototyped a draft of IPv6 support in...

activities report for January 2026 Denis Ovsienko (Feb 02)
January 2026
============

The accounted activities in January 2026 stand for 159:20 working hours
and 61 commits (45 in libpcap and 16 in tcpdump-htdocs). There are 5884
new tests in libpcap.

One substantial direction of work in libpcap was fixing of the
"gateway" primitive, which incurred refactoring work on the IPv4/IPv6
processing code and the tests. This has been completed, so "gateway" is
going to work correctly in...

About IP TSO printing Francois via tcpdump-workers (Jan 30)

SECURITY.md Michael Richardson (Jan 28)
Hi, I've proposed two PRs (libpcap/tcpdump) which adds a SECURITY.md file to
both projects. They are:
* https://github.com/the-tcpdump-group/tcpdump/pull/1403
* https://github.com/the-tcpdump-group/libpcap/pull/1613

This is based upon some discussion at the GVIP-project.org's Summit#01.
I attach the SECURITY.md for discussion here.

# SECURITY reporting for TCPDUMP.

## Ethical Reporting Guidelines

If you have not read the The Menlo...

Re: capture and inject device capabilities in libpcap Denis Ovsienko (Jan 28)
The libpcap pull request is up for review again. If you think it would
be a useful thing to use in Wireshark or elsewhere, feel free to merge
or to point out issues that need fixing. Otherwise it is not blocking
any of my work, so it can wait quite a while longer.

activities report for December 2025 Denis Ovsienko (Jan 01)
December 2025
=============

The accounted activities in December stand for 120:10 working hours and
40 commits (5 in tcpdump, 20 in libpcap and 15 in tcpdump-htdocs).
There are 310 new tests in libpcap.

Most notably, tcpdump 4.99.6 and libpcap 1.10.6 have been released.
This libpcap release fixes two minor vulnerabilities (CVE-2025-11961
and CVE-2025-11964), a more detailed account of other improvements is
available in the change logs. In...

Re: capture and inject device capabilities in libpcap Guy Harris (Dec 19)
My inclination is to have libpcap supply devices regardless of whether they have no-capture or no-inject set, and have
the caller choose what to show.

That way, it can be changed at the application level if the existing application behavior is an issue. For example, a
sniffer could start out not showing no-capture devices and, if people ask why the XXX interface isn't showing up, and
it turns out that it's a device that doesn't...

Re: Improving DPDK support Stephen Hemminger via tcpdump-workers (Dec 12)

Re: Improving DPDK support Denis Ovsienko (Dec 12)
Yes. How much of the existing code to preserve, if any, would be up to
anyone who can get pcap-dpdk.c into shape.

One of the directions of work done in libpcap in recent few years has
been removing of modules that could/should not be maintained anymore
(e.g. AirPcap, Enetfilter, NIT, Septel, STREAMS NIT, TurboCap and
[Tru64/Ultrix] Packet Filter). Another was fixing of various bit rot
in the remaining modules where practicable (DAG, DLPI,...

Re: Improving DPDK support Guy Harris (Dec 12)
As this is talking about libpcap, presumably you mean "which would have a program using libpcap, such as tcpdump or
Wireshark, running as a seondary process"; they might be the *primary* users of libpcap, but they're not the *only*
users (Snort and scapy both use it).

Presumably this would still allow it to be used as a sniffer, as that's what tcpdump and Wireshark are, and as that's
the primary purpose of libpcap (to...

Improving DPDK support Stephen Hemminger via tcpdump-workers (Dec 11)

Re: BPF ISA web page Vadim Goncharov (Dec 06)
It should contain not only "mnemonics" (BTW, A and X registers are uppercase)
but also also layout of instruction and actual codes such as BPF_K or BPF_IND.
This will allow reader to understand potential of extensions. When I tried to
design next step of BPF ISA (alternative to eBPF and comaptible to classic
BPF), I've even drawed them like RFC-style diagrams:

https://github.com/nuclight/bpf64/blob/main/bpf64spec.md

Re: dlt_choice table in pcap.c Guy Harris (Dec 04)
The full fun story is at https://gitlab.com/wireshark/wireshark/-/issues/2010

Re: dlt_choice table in pcap.c Guy Harris (Dec 04)
I think the capture code in tcpdump, which I think later became the separate libpcap library, originally just supported
the BPF capture mechanism, which used DLT_ values to indicate link-layer types. Thus, libpcap used DLT_ values in its
APIs; there *were* no LINKTYPE_ values.

Unfortunately, when they added new link-layer types to BPF, various OSes that picked up BPF sometimes chose values such
that the same numerical value corresponded to...

dlt_choice table in pcap.c Michael Richardson (Dec 04)
Guy, we have this lovely table in pcap.c:

static struct dlt_choice dlt_choices[] = {
DLT_CHOICE(NULL, "BSD loopback"),
DLT_CHOICE(EN10MB, "Ethernet"),
DLT_CHOICE(EN3MB, "experimental Ethernet (3Mb/s)"),
DLT_CHOICE(AX25, "AX.25 layer 2"),
DLT_CHOICE(PRONET, "Proteon ProNET Token Ring"),
...

I feel like it ought to be indexed by LINKTYPE instead....

More Lists

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