tcpdump Mailing List
Covers the classic tcpdump text-based network sniffer and its libpcap sniffer library component.
List Archives
- Jan–Mar
- Apr–Jun
- Jul–Sep
- Oct–Dec
- 2026
- 29
- 1
- –
- –
- 2025
- 10
- 42
- 25
- 51
- 2024
- 19
- 34
- 22
- 36
- 2023
- 77
- 8
- 20
- 16
- 2022
- 21
- 47
- 37
- 17
- 2021
- 90
- 5
- 32
- 16
- 2020
- 57
- 69
- 72
- 61
- 2019
- 46
- 47
- 37
- 45
- 2018
- 41
- 58
- 149
- 32
- 2017
- 57
- 54
- 24
- 59
- 2016
- 33
- 73
- 63
- 48
- 2015
- 112
- 79
- 62
- 108
- 2014
- 133
- 84
- 69
- 112
- 2013
- 127
- 157
- 55
- 107
- 2012
- 176
- 84
- 53
- 144
- 2011
- 177
- 234
- 187
- 215
- 2010
- 217
- 131
- 85
- 141
- 2009
- 220
- 182
- 186
- 145
- 2008
- 233
- 140
- 139
- 269
- 2007
- 154
- 118
- 251
- 226
- 2006
- 200
- 147
- 71
- 162
- 2004
- 392
- 374
- 377
- 208
- 2003
- 315
- 283
- 259
- 304
- 2002
- –
- –
- –
- 319
Latest Posts
activities report for March 2026
Denis Ovsienko (Apr 02)
March 2026
==========
The accounted activities in March stand for 123:25 working hours and 22
commits (13 in libpcap, 5 in tcpdump and 4 in tcpdump-htdocs).
Two main directions of this work were progressing of the pull request
queues and prototyping of a few bug fixes that still require more work
to become ready for merging.
Other accounted activities include:
* various infrastructure upkeep work,
* various minor improvements to QNX support...
Re: Error in the pcap_next_ex(3PCAP) man page
Denis Ovsienko (Mar 26)
So far six functions have been deprecated in libpcap. If a future
major release removes these functions, it would be an ABI change and
smaller changes like the above could be made in the same go.
Re: Error in the pcap_next_ex(3PCAP) man page
Guy Harris (Mar 26)
Merged, but not with the "for historical reasons" part. Should that go in a BUGS section, or somewhere else?
Re: Error in the pcap_next_ex(3PCAP) man page
Guy Harris (Mar 26)
That's the pull request at https://github.com/the-tcpdump-group/libpcap/pull/1662
The version before that change had the same problem.
The underlying problem in the man page is that it doesn't note that -2/PCAP_ERROR_BREAK can also be returned... if
somebody calls pcap_breakloop().
*That* problem was introduced when pcap_breakloop() was added; that was added in
commit 991d444f7116bef16893826b46f3950f62281507
Author:...
Re: Error in the pcap_next_ex(3PCAP) man page
Denis Ovsienko (Mar 26)
The problem stated in this thread seems to be that pcap_next_ex(3PCAP)
does not document PCAP_ERROR_BREAK as a valid return value when the
pcap_t stands for a live capture. This requires a straightforward
separate fix.
Another problem is that in commit 6e15abc I missed the subtlety of
pcap_next_ex() branching into two code paths with different semantics
of -2: one for a live capture and another for a savefile. From a code
style point of view,...
Re: Error in the pcap_next_ex(3PCAP) man page
Guy Harris (Mar 25)
To quote the comment in pcap_next_ex():
/*
* Return codes for pcapint_offline_read() are:
* - 0: EOF
* - -1: error
* - >0: OK - result is number of packets read, so
* it will be 1 in this case, as we've passed
* a maximum packet count of 1
* The first one ('0') conflicts...
Error in the pcap_next_ex(3PCAP) man page
Aaron Rainbolt (Mar 24)
Hi,
In the "Return Value" section of the pcap_next_ex(3PCAP) manpage, it
says that "pcap_next_ex() returns... PCAP_ERROR_BREAK if packets are
being read from a ``savefile'' and there are no more packets to read
from the savefile...". This is incorrect; the source code states that
PCAP_ERROR_BREAK can be returned if the pcap_next_ex() call is
interrupted by pcap_breakloop():
#define PCAP_ERROR_BREAK...
Re: POSIX and float rounding
Guy Harris (Mar 19)
It could solve it reliably *if* you choose a rounding mode *other* than round-to-nearest; I don't think the other modes
have the problem of "which of 0 and 1 is nearest to .5?"
Unfortunately, fesetround(), prior to C23, doesn't offer a way to tell the floating-point environment how to break the
tie, as it offers no choice between different flavors of round-to-nearest. C23 distinguishes between FE_TONEAREST,
which is...
Re: POSIX and float rounding
Denis Ovsienko (Mar 19)
Thank you for the detailed analysis. Are you saying that fesetround()
cannot solve this problem reliably?
The simplest workaround would be to fork the test into one QNX-only
version and another except-QNX version (assuming QNX does not change its
rounding method).
Re: POSIX and float rounding
Rick Jones via tcpdump-workers (Mar 19)
Re: POSIX and float rounding
Guy Harris (Mar 19)
In any case, given all this mishegoss, the right answer is probably to have the script see how the floating-point value
0.5 is printed with %.0f, and choose which test to perform based on that, in the hopes that whatever rounding the
scripting program does matches what tcpdump will do.
Re: POSIX and float rounding
Guy Harris (Mar 19)
As for a rationale for QNX's behavior, for what it's worth, Google's Artificial Brain says:
Key Details regarding QNX roundTiesToAway Behavior:
• Behavior: For a number like 0.5, round(0.5) returns 1.0, and round(-0.5) returns −1.0.
• Library: Part of libm (general-purpose math library) and libm-sve (optimized for ARMv8).
• Context: Unlike some IEEE 754 default behaviors that...
Re: POSIX and float rounding
Guy Harris (Mar 19)
https://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.doc.neutrino_prog/posix_conformance.html
says
For the fprintf() function, the low-order digit rounding for numbers in double format is round-to-nearest.
and appears to be completely silent on which IEEE 754 "what about ties?" flavor it implements.
Re: POSIX and float rounding
Guy Harris (Mar 19)
The Wikipedia says:
https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules
Tl;dr: there are *five* rounding rules:
• Round to nearest, ties to even – rounds to the nearest value; if the number falls midway, it is rounded to the
nearest value with an even least significant digit.
• Round to nearest, ties away from zero (or ties to away) – rounds to the nearest value; if the number falls
midway, it is rounded to the...
Re: POSIX and float rounding
Guy Harris (Mar 19)
So that's true on *all* of the platforms, including QNX?
That's annoying. It appears that QNX's definition of "to nearest", in the "the two choices are equidistant" case, is
different from that of all other platforms (and from what I guess I was taught in school, as I've always thought you
were supposed to round 0.5 up to 1).
Perhaps it's time to see what IEEE 754 has to say on the topic.
More Lists
Dozens of other network security lists are archived at SecLists.Org.
