Extract the FCS length information from that field, and reject captures
that have a non-zero "class" field (the 10-bit reserved field that was
once intended to allow other "classes" of link layer type, with class 0
being "LINKTYPE_ values", but the original use case doesn't appear ever
to have been used).
The block is lightweight and doesn't have any options so the create
function doesn't really do anything, but it needs to be registered
so that when systemd journal files are opened, the wtap_block_create()
call works and doesn't segfault. Fix#17875
It's common to put multiple certificates in one RFC 7468 file in order to store
a certificate chain, as described in the introduction to RFC 7468 itself.
Support this usage by presenting each such certificate (or any other encoded
structure - the code doesn't discriminate) as a separate packet.
The new parsing code supports arbitrary line lengths, so update the detection
code to support arbitrary line lengths as well. Instead of probing up to 20
lines, we now try to find the first pre-encapsulation boundary in the first
2048 bytes of the file. I chose this new limit so that it works roughly the
same in practice as the old one (it's equal to 20 lines times 80 characters
per line, rounded to a power of two).
Repeated words were found with:
egrep "(\b[a-zA-Z]+) +\1\b" . -Ir
and then manually reviewed.
Non-displayed strings (e.g., in comments)
were also corrected, to ease future review.
Currently used to define ssize_t on platforms that lack it.
Fix some Windows build errors caused by moving the definition into a
separate header.
Fix some narrowing warnings on Windows x64 from changing the definition
of ssize_t from long int to int64_t.
The casts in dumpcap are ugly but necessary. The whole code needs
to be rewritten for portability, or the warnings disabled.
In wtap_dump_init_dumper(), when constructing a dummy IDB for files
that don't have one, if the tsprecision value is anything other than
the default, then the OPT_IDB_TSRESOL option also needs to be set.
Without it, for a pcapng the timestamps will be written according to the
tsprecision and time_units_per_second values, but when it is read,
the values will be interpreted incorrectly.
It would probably be better if the consistency of these values were enforced.
In addition to setting tsprecision and time_units_per_second, add
the OPT_IDB_TSRESOL option as well, because pcapng expects that to
be set if tsprecision is anything other than the default.
Rcv.Wind.Shift and Snd.Wind.Shift were not displayed correctly by
the BBLog dissector and the TCP dissector was not using the
information about the shift values available in the BBLog file.
Each "packet" in the USB encapsulation formats for at least
Linux and Darwin corresponds to an OS-level USB request, so
the packets can be much larger than a USB-level packet.
The default max packet length of 256 KiB prevents Wireshark
from loading capture files that contain requests >256 KiB.
(Saving such a capture already works fine.)
Fix this by making the Linux, Darwin, and FreeBSD formats
use the same max packet length as the USBPCap format, which
is 128 MiB.
/home/pi/wireshark/wiretap/file_wrappers.c: In function ‘file_fdopen’:
/home/pi/wireshark/wiretap/file_wrappers.c:1136:27: error: comparison of integer expressions of different signedness: ‘__blksize_t’ {aka ‘long int’} and ‘unsigned int’ [-Werror=sign-compare]
if (st.st_blksize <= MAX_READ_BUF_SIZE)
^~
cc1: all warnings being treated as errors