tcpdump Mailing List

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

List Archives

Latest Posts

Re: B.A.T.M.A.N. Advanced libpcap pull-request Michael Richardson (Aug 15)
Linus Lüssing <linus.luessing () c0d3 blue> wrote:
> I wanted to cautiously inquire about the pull-request I had filed
> about 5 years ago for adding B.A.T.M.A.N. Advanced support to
> libpcap here:

> "Add support for B.A.T.M.A.N. Advanced #980"
-> https://github.com/the-tcpdump-group/libpcap/pull/980

Oh, yeah, I remember now.
I had hoped to get Bill Fenner to review the pcap compiler changes....

B.A.T.M.A.N. Advanced libpcap pull-request Linus Lüssing (Aug 15)
Hello,

I wanted to cautiously inquire about the pull-request I had filed
about 5 years ago for adding B.A.T.M.A.N. Advanced support to
libpcap here:

"Add support for B.A.T.M.A.N. Advanced #980"
-> https://github.com/the-tcpdump-group/libpcap/pull/980

I'm not in a hurry and would need a while to add any change
requests anyway, due to other things having priorities right now.

But I had also been wondering why it might not be...

activities report for July 2025 Denis Ovsienko (Aug 15)
July 2025
=========

The accounted activities in July stand for 20:05 working hours and 8
commits (3 in libpcap, 3 in tcpdump, 2 in tcpdump-htdocs). There are 18
new tests in libpcap.

Other accounted activities include:
* rebuilding and upgrading of pkgsrc on netbsd-aarch64 (Clang 18.1 ->
19.1, GCC 14.2 -> 14.3), netbsd-mips and netbsd-mips64 from 2025Q1 to
2025Q2
* upgrading of FreeBSD from 14.2 to 14.3 on freebsd-amd64 and...

Returned mail: see transcript for details gerald--- via tcpdump-workers (Jul 17)

tcpdump support for "Mobility Support in IPv6" RFC 6275 Francois-Xavier Le Bail via tcpdump-workers (Jul 16)

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Guy Harris (Jul 08)
If by "layers" you're referring to the "parse this filter expression without taking the link-layer type into account"
API and the "generate cBPF/eBPF code" API, an abstract syntax tree is one possible encoding; others might be, for
example, a sequence of "operation, source 1, source 2, destination" quads, including conditional branch operations
(think of it as a higher-level link-layer type and...

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Guy Harris (Jul 08)
Yes, but is there a notion of a file descriptor for an "object" whose sole purpose is to, for example, fill in a stat
structure when you call stat() on it, and supports no other operations? A "dead" pcap_t's only purpose is to supply a
link-layer type and snapshot length - and, potentially, compiler target type - to APIs that, for whatever reason,
weren't designed to take those values as arguments.

That's a...

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Stephen Hemminger via tcpdump-workers (Jul 08)

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Denis Ovsienko (Jul 08)
The parse tree, as a means of data handover between layers, would be an
encoding. To make it possible to test the algorithms that
produce/consume this encoding, it would be necessary to have means of
serializing/deserializing the parse tree using some text form, then the
following test types would become possible:

1. Does this filter expression translate to this parse tree?
2. Does this parse tree become that parse tree after this optimisation?...

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Denis Ovsienko (Jul 08)
The need to have a pcap_t at all times is very similar to using file
descriptors or sockets: first you obtain a descriptor, then you
initialise it in various ways as necessary, then you have a very small
number of methods to read and to write, and by that time the only
things you need to specify are the descriptor and details of this
particular read/write (how many bytes, location, blocking/non-blocking).

libcurl and other libraries implement a...

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Guy Harris (Jul 07)
Yes.

What I was thinking of was to generate a higher-level intermediate representation in the parser; that IR would be
link-layer-independent, and would *not* be a form of cBPF or eBPF machine code, so, for example, it wouldn't know about
particular registers, and operations would not necessarily correspond to particular cBPF or eBPF instructions. There
could probably be a bunch of optimizations done to programs in that IR.

A separate...

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Guy Harris (Jul 07)
But that still requires pcap_open_dead(), which is somewhat of a greasy hack, as far as I'm concerned. If all you're
using libpcap for is to generate cBPF code, a pcap_t seems to be extra baggage.

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Denis Ovsienko (Jul 07)
A few years ago I noticed that bug reporters and myself sometimes
have to reconstruct the origin of particular BPF instruction manually,
for example,

(000) ldh [12]
(001) jeq #0x800 jt 2 jf 10
(002) ldb [23]
(003) jeq #0x6 jt 4 jf 10
(004) ldh [20]
(005) jset #0x1fff jt 10 jf 6
(006) ldxb 4*([14]&0xf)
(007) ldh [x + 16]
(008) jeq #0x50 jt 9 jf 10...

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Denis Ovsienko (Jul 07)
[...]

Yes, and that version could be the same old pcap_compile() if the
pcap_t contained the compilation style requests, as it already contains
the link-layer type and the snapshot. Something like this:

// This would be PCAP_TARGET_AUTO by default.
pcap_setopt(handle, PCAP_COMPILE_TARGET, PCAP_LINUX_WITH_VLAN);

pcap_compile(handle, fp, "tcp port 80", 1, PCAP_NETMASK_UNKNOWN);

Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle Michael Richardson (Jul 04)
Guy Harris <gharris () sonic net> wrote:
> In the longer term, the compilation process should probably be split
> into:

yes.

> a phase that compiles a filter into a target-independent *and*
> link-layer-independent *and* snapshot-length-independent intermediate
> representation, optionally doing whatever optimization can be done with
> that;

The "AST" phase (rustc) or "RTL"...

More Lists

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