tcpdump Mailing List

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

List Archives

Latest Posts

Re: Should applications close pcap_get_selectable_fd()? Michael Richardson (Aug 14)
Guy Harris <gharris () sonic net> wrote:
> On Aug 13, 2026, at 4:22 PM, Mark Delany <fzx () xray emu st> wrote:

>> This is probably more a documentation clarification than anything else as a light troll
>> through the archives suggests the answer...
>>
>> pcap_fileno(3) is fairly explicit about suggesting that the returned fd is the same one as
>> that used internally by...

Re: Should applications close pcap_get_selectable_fd()? Mark Delany (Aug 13)
Exactly my thoughts. We don't know anything about the relationship and shouldn't assume otherwise.

Either works for me. What would you say about pcap_fileno() as the manpage currently
implies pretty tight coupling?

Will do (at least for one of those).

Mark.

Re: Should applications close pcap_get_selectable_fd()? Guy Harris (Aug 13)
Please file an issue on this at https://github.com/the-tcpdump-group/libpcap/issues to serve as a reminder. (And if you
have a change to the manual page that you'd like to suggest, feel free to file a pull request.)

Re: Should applications close pcap_get_selectable_fd()? Guy Harris (Aug 13)
The documentation needs to be changed to make it clearer that it should *not* be closed, because it could be, but is
not guaranteed to be, the same file descriptor as the one used for the capture mechanism. (Some capture mechanism might
require separate readable and selectable FDs. Npcap requires the Windows equivalent - a HANDLE on which to do reads,
writes, and DeviceIoControl()s, and another HANDLE representing an event that can be waited...

Should applications close pcap_get_selectable_fd()? Mark Delany (Aug 13)
This is probably more a documentation clarification than anything else as a light troll
through the archives suggests the answer...

pcap_fileno(3) is fairly explicit about suggesting that the returned fd is the same one as
that used internally by pcap, however pcap_get_selectable_fd(3) is much less forthcoming
on the matter.

My naive reading is that pcap_get_selectable_fd() returns a unique fd for my own purposes
and that I should close it when...

Re: activities report for July 2026 Denis Ovsienko (Aug 02)
In these use cases "ret" [a] seems to fit better because if the
return value is a sum of several components, it most likely will be in A
after the required number of "add x" and "add #k".

For somebody who is prepared to do that an additional "txa" hardly
makes the task any more difficult.

Re: activities report for July 2026 Guy Harris (Aug 02)
Somebody who wants to capture TCP packets and wants the packets to be cut off after the first 20 bytes of TCP
*payload*, especially if they're running on a link layer that has a variable-length header?

Or just "...after the first 20 bytes of IPv4 header" with a variable-length link-layer header?

(No API support for that in libpcap, though. They'd have to write their own filter code.)

Re: activities report for July 2026 Denis Ovsienko (Aug 02)
[...]

This would be a monumental task, but the gain could be zero because:

* "ret x" would have the same effect as "txa; ret" because the value of
A makes no difference after the return, except each "ret x" per
filter program would save one BPF instruction, and

* libpcap always generates filter programs with one or two return
instructions, and

* the only type of return instruction libpcap generates is...

Re: activities report for July 2026 Guy Harris (Aug 02)
Because not all cBPF (in the sense of the classic BPF machine language) implementations support it.

None of FreeBSD, NetBSD, OpenBSD, DragonFly BSD, Darwin, Illumos (closest thing to Solaris I could get), or Linux
support it, and neither does the BPF implementation in libpcap.

Perhaps one could argue that it *should* be supported, but, at least in libpcap, we'd only be able to use it in 1) our
own cBPF interpreter and 2) in-kernel cBPF...

Re: activities report for July 2026 Vadim Goncharov (Aug 02)
Why not?..

activities report for July 2026 Denis Ovsienko (Aug 02)
July 2026
=========

The accounted activities in July stand for 115:20 working hours and 18
commits: 9 in libpcap, 5 in tcpdump and 4 in tcpdump-htdocs. There is
48 more tests in libpcap and 3 fewer tests in tcpdump. In libpcap other
improvements are as follows:

* The test tooling now allows to define a custom timeout for individual
tests, this is expected to reduce the number of false negatives
caused by DNS.
* The optimiser now handles...

CMake fails to detect <net/bpf.h> on QNX 8.0. Denis Ovsienko (Aug 01)
Hello all.

There is a traditional peculiarity of the build systems I came across
and could not explain. It starts seemingly simple: a native build of
libpcap (the current master branch with a couple WIP commits on top) on
QNX SDP 8.0.5 works using Autoconf, but fails using CMake 4.2.3.

Autoconf:
checking for net/bpf.h... yes
checking for sys/ioccom.h... yes
checking if net/bpf.h defines BIOCSETIF... yes
checking packet capture type... bpf...

activities report for June 2026 Denis Ovsienko (Jul 03)
June 2026
=========

The accounted activities in June 2026 stand for 36:15 working hours and
13 commits (10 in tcpdump-htdocs, 2 in tcpdump and 1 in libpcap). Main
directions of this work were:
* initial follow-ups to the shutdown of Cirrus CI,
* progressing of a few bug reports and pull requests,
* progressing of various unfinished prototypes,
* upgrading of various Debian hosts from 12 to 13, and
* other infrastructure upkeep work....

Re: UNALIGNED_MEMCPY enh via tcpdump-workers (Jun 10)

Re: UNALIGNED_MEMCPY Denis Ovsienko (Jun 10)
On Raspberry Pi 0 (armv6l):

# echo 1 >/proc/cpu/alignment

kernel: alignment: ignoring faults is unsafe on this CPU. Defaulting to
fixup mode.

# cat /proc/cpu/alignment
User: 0
System: 0 (0x0)
Skipped: 0
Half: 0
Word: 0
DWord: 0
Multi: 0
User faults: 3 (fixup+warn)

Yet setting this to 4 (signal) and running a test program that triggers
a signal on SPARC neither triggers the...

More Lists

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