Call the Vector Informatik BLF format "Vector Informatik Binary Logging
Format (BLF) logfile", to give more details to people who don't
necessarily know what "BLF" means (British Lung Foundation?).
Note that in the introductory comments to blf.c and blf.h as well.
Note that we should perhaps report unknown flags/packet timestamp type
values as errors or warnings.
Note that we can, and should, report at least some 802.11 radio
information to our caller.
This patch adds the format 2 and 3 of the ObjectHeader, so that the blf
code does not stop reading the file, when one of these header formats is
present.
Minor refactoring was necessary.
Add support for displaying one or more packet hashes that
have been recorded in EPB options.
A patch to add support for EPB hash option is pending for next
DPDK release.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
It's set from the result of mktime(), which returns a time_t, and it's
assigned to a time_t that's ultimately assigned to the time_t secs
member of an nstime, so no reason for it to be a guint32.
This should squelch Coverity CID 1509354.
When reading memory-mapped Linux capture files, fix up the "real" length
field, in case the file was written by a program doing a capture done
with a version of libpcap with a bug that causes it to incorrectly set
the "real" length for isochronous transfers.
Libpcap assumes that packet length is greater or equal to captured data
length. However, due to a bug in libpcap, it was possible for libpcap to
generate isochronous URB packets (WTAP_ENCAP_USB_LINUX_MMAPPED) with
captured data length greater than packet length. The discrepancy comes
from slightly different semantics in Linux kernel.
Linux kernel usbmon packet documentation mentions:
unsigned int length; /* 32: Length of data (submitted or actual) */
unsigned int len_cap; /* 36: Delivered length */
Wireshark shows usbmon packet length as URB length (usb.urb_len) and
len_cap as Data length (usb.data_len). For usbmon isochronous IN packets
containing data (URB complete), usbmon length is "actual". Actual length
is the sum of payload packets length received from device. Delivered
length refers to the amount of data associated with usbmon packet, that
is the isochronous descriptors and actual isochronous data. There can be
multiple isochronous descriptors in single URB and the actual payload in
special cases can be noncontiguous (there can be gaps).
Libpcap when reading usbmon capture calculates packet length based on
usbmon packet structure size (64), "actual length" and number of
isochronous descriptors. This gives expected packet length as long as
there are no gaps between isochronous data. If there are gaps, the
calculated packet length will be smaller than delivered length.
Wireshark should show the frame length and captured length as provided
by the capture engine, even if the capture length is greater than frame
length. Silently limiting captured length essentially hides the issue
from the user and allows misbehaving capture engine to go unnoticed.
Passing unmodified Frame Length and Capture Length to dissectors (and
thus complete tvb) allows USB dissector to show all ISO Data fields
captured on Linux usbmon interface using bugged libpcap.
Fixes#18021
USB 2.0/1.1/1.0 devices (or 3.x and newer when connected to hosts that
are not Super-Speed capable) operate at one of three speeds:
* Low-Speed (1.5 Mbps)
* Full-Speed (12 Mbps)
* High-Speed (480 Mbps)
Supporting speed specific linktypes allows speed specific dissection
without the need for user to manually set the speed.
Rename the following build targets, similar to the recent macOS target
name changes:
nsis_package_prep to wireshark_nsis_prep
nsis_package to wireshark_nsis
Rename some NSIS files to reflect that they're specific to Wireshark.
Update the documentation and CI configurations.
Support merging files with IDBs in the middle of the file.
Use wtap_get_next_interface_description when doing the initial
list of interfaces so that we can correctly get IDBs later.
Note that while IDB merge modes "any" and "none" work as expected, the
default "all" mode can't really work for IDBs in the middle of the file
without adding a two-pass mode. In "all" mode, if there are any such IDBs,
merge them with duplicates iff the interfaces at the beginning of the
files were merged.
Related to #15502 and #16542.
If we do a save with copy, so that we just copied the binary
file, everything in the wtap structure should be the same except
for the filename and the file descriptors, so just change that
instead of closing wtap and reopening it.
The current behavior of calling wtap_open_offline does not work
for files that have blocks (SHBs, IDBs, NRBs, DSBs, ISBs, etc.) in
the middle of the file instead of at the beginning, but we shouldn't
have to waste time rescanning the entire file either.
In the case where a specific file format reader was manually selected,
this will keep the same file format as selected instead of switching to
the auto-detection when opening the copy, just as SAVE_WITH_MOVE already
does and presumably what the user wants.
Update wtap_fdreopen to change the wtap struct's pathname if
wtap_fdreopen is called with a different filename than currently.
Fix#17472
If merge_files_common() is called with a non NULL value for out_filenamep,
that always indicates tempfile mode, even if the tempdir is not set.
A NULL value for the tempdir is handled by wtap_dump_open_tempfile,
which writes to the OS default temp directory.
Only write to stdout if both out_filename and out_filenamep are NULL.
Fixes a crash introduced by commit 1e0d117eb7
when selecting Merge from the GUI and the new temp_dir option is not set.
Add a "section number" field to wtap_rec, with a presence flag, and
provide the section number (0-based) for pcapng files.
Display it (1-based) if present.
This allows the "needs to be reloaded" indication to be set in the close
process, as is the case for ERF; having a routine that returns the value
of that indication is not useful if it gets seet in the close process,
as the handle for the wtap_dumper is no longer valid after
wtap_dump_close() finishes.
We also get rid of wtap_dump_get_needs_reload(), as callers should get
that information via the added argument to wtap_dump_close().
Fixes#17989.
Add asterisks to doxygen generates for existing
supported_block_type comments.
Add < to #define's so that doxygen associates comments
with the #define above, instead of below.
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).
Guy Harris