Validate UTF-8 encoding for pcapng string options. To
avoid two unnecessary memory allocations for invalid strings and
make the code cleaner a new wtap_block_add_string_option_owned()
function is used.
Add UTF-8 debug check for wiretap API.
Fixes#18703.
Rename flex macros using parenthesis (mostly a style issue):
DIAG_OFF_FLEX -> DIAG_OFF_FLEX()
DIAG_ON_FLEX -> DIAG_ON_FLEX()
Use the same kind of construct with lemon generated code using
DIAG_OFF_LEMON() and DIAG_ON_LEMON(). Use %include and %code
directives to enforce the desired order with generated code
in the middle in between pragmas.
Fix a clang-specific pragma to use DIAG_OFF_CLANG().
DIAG_OFF(unreachable-code) -> DIAG_OFF_CLANG(unreachable-code).
Apparently GCC is ignoring the -Wunreachable flag, that's why
it did not trigger an unknown pragma warning. From [1}:
The -Wunreachable-code has been removed, because it was unstable: it
relied on the optimizer, and so different versions of gcc would warn
about different code. The compiler still accepts and ignores the
command line option so that existing Makefiles are not broken. In some
future release the option will be removed entirely. - Ian
[1] https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html
This fixes a bug in the canfdmessage64 encoding in BLF that leads to
CAN-FD frames being interpreted as Remote Frames instead of correctly
ignoring the SRR flag. Makes canfdmessage encoding more robust as well.
All other functions are declared with two lines:
WS_DLL_PUBLIC <type>
<function_name(<args>);
Declare wtap_block_foreach_option() that way, too, for consistency.
A given protocol's packet format may depend, for example, on which
lower-level protocol is transporting the protocol in question. For
example, protocols that run atop both byte-stream protocols such as TCP
and TLS, and packet-oriented protocols such as UDP or DTLS, might begin
the packet with a length when running atop a byte-stream protocol, to
indicate where this packet ends and the next packet begins in the byte
stream, but not do so when running atop a packet-oriented protocol.
Dissectors can handle this in various ways:
For example, the dissector could attempt to determine the protocol over
which the packet was transported.
Unfortunately, many of those mechanisms do so by fetching data from the
packet_info structure, and many items in that structure act as global
variables, so that, for example, if there are two two PDUs for protocol
A inside a TCP segment, and the first protocol for PDU A contains a PDU
for protocol B, and protocol B's dissector, or a dissector it calls,
modifies the information in the packet_info structure so that it no
longer indicates that the parent protocol is TCP, the second PDU for
protocol A might not be correctly dissected.
Another such mechanism is to query the previous element in the layers
structure of the packet_info structure, which is a list of protocol IDs.
Unfortunately, that is not a list of earlier protocols in the protocol
stack, it's a list of earlier protocols in the dissection, which means
that, in the above example, when the second PDU for protocol A is
dissected, the list is {...,TCP,A,B,...,A}, which means that the
previous element in the list is not TCP, so, again, the second PDU for
protocol A will not be correctly dissected.
An alternative is to have multiple dissectors for the same protocol,
with the part of the protocol that's independent of the protocol
transporting the PDU being dissected by common code. Protocol B might
have an "over a byte-stream transport" dissector and an "over a packet
transport" dissector, with the first dissector being registered for use
over TCP and TLS and the other dissector being registered for use over
packet protocols. This mechanism, unlike the other mechanisms, is not
dependent on information in the packet_info structure that might be
affected by dissectors other than the one for the protocol that
transports protocol B.
Furthermore, in a LINKTYPE_WIRESHARK_UPPER_PDU pcap or pcapng packet for
protocol B, there might not be any information to indicate the protocol
that transports protocol B, so there would have to be separate
dissectors for protocol B, with separate names, so that a tag giving the
protocol name would differ for B-over-byte-stream and B-over-packets.
So:
We rename EXP_PDU_TAG_PROTO_NAME and EXP_PDU_TAG_HEUR_PROTO_NAME to
EXP_PDU_TAG_DISSECTOR_NAME and EXP_PDU_TAG_HEUR_DISSECTOR_NAME, to
emphasize that they are *not* protocol names, they are dissector names
(which has always been the case - if there's a protocol with that name,
but no dissector with that name, Wireshark will not be able to handle
the packet, as it will try to look up a dissector given that name and
fail).
We fix that exported PDU dissector to refer to those tags as dissector
names, not protocol names.
We update documentation to refer to them as DISSECTOR_NAME tags, not
PROTO_NAME tags. (If there is any documentation for this outside the
Wireshark source, it should be updated as well.)
We add comments for calls to dissector_handle_get_dissector_name() where
the dissector name is shown to the user, to indicate that it might be
that the protocol name should be used.
We update the TLS and DTLS dissectors to show the encapsulated protocol
as the string returned by dissector_handle_get_long_name(); as the
default is "Application Data", it appeaers that a descriptive name,
rather than a short API name, should be used. (We continue to use the
dissector name in debugging messages, to indicate which dissector was
called.)
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).
João Valverde