Quote the path name variables in -fmacro-prefix-map so that source or build
directories with spaces work when compiling with recent gcc or clang.
Fix#17487 (LocatePythonModule was removed recently so that doesn't
need fixing.)
If get an EMFILE on UN*X, try to raise the soft limit for the
number of open file descriptors if it's less than the hard limit.
Raise it to the minimum of what we need and the hard limit.
On macOS before Big Sur, you can't always raise the soft limit to
the current hard limit as returned by getrlimit, because that can
be set to, e.g., RLIM_INFINITY even when there's an effective lower
limit set by kern.maxfilesperproc on sysctl (Mojave to Monterey)
or the possibly lower fixed limit OPEN_MAX (10240) from Leopard
until some version before Mojave.
Use a workaround for this based on some from Wine.
merging is embarrassingly parallel, so long as we preserve ordering
when merging intermediate results, so we can process files in
batches if we hit RLIMIT_NOFILE and have the same output[1] we would
otherwise.
[1] One minor exception is in the SHB comments, but currently those aren't
written properly anyway. Another minor exception is that the ordering
of addresses within the NRBs can vary (be reversed), but both of these
are underlying issues, not having to do with the algorithm of batch
processing and merging.
Wireshark currently supports merging lots of files at once through
drag and drop, but not through the File->Merge dialog; we might
want to change the latter.
Fix#17598
Store the Show Packt Bytes "Decode As" and "Show As" settings in
recent.
The options for "Show as" for Show Packet Bytes are a superset of the
"Show data as" for Follow Stream, and they're conceptually doing
the same thing. Use the same enum for both - Follow Stream doesn't
support all these options, but maybe it should in the future.
To do this, we break the strict correspondance between the index
in the respective comboboxes and the value of the enum. Use
findData when setting the current index so that this doesn't matter;
this also keeps us from having to be as strict about keeping new
entries in alphabetical order.
Fix#17796
check_tfs.py brings up two errors about open coded true_false_string
variables where existing global ones could be used.
Error: epan/dissectors/asn1/ansi_map/packet-ansi_map-template.c
ansi_map_Odd_Even_Ind_bool_val - could have used tfs_odd_even
from tfs.c instead: {"Odd", "Even"}
Error: epan/dissectors/asn1/ansi_map/packet-ansi_map-template.c
ansi_map_ConfidentialityModes_bool_val - could have used tfs_on_off
from tfs.c instead: {"On", "Off"}
Fix these errors by using the recommended tfs.
ansi_map_Odd_Even_Ind_bool_val is already unused and commented out, it
seems that check_tfs.py can't detect this.
This will hopefully fix the pipeline failures in !12239.
This change adds a dissector for the X.75 protocol,
commonly used on ISDN B-channels.
The protocol is defined in ITU-T Rec. X.75 (10/96).
X.75 is similar to LAPB, but has no further protocols on top
of the asychronous link layer.
Try to run our merge requests in Debug mode to make sure the
test suite has the best chance of catching any issues.
This means we no longer have a Release build. This build was intended
to catch warnings that only appears with -O3 optimization level.
It seems to have been successful at that. If that becomes an issue
again we may want to add a new job with a Release type build.
This should help catch more runtime errors and assertions that
sometimes slip through the cracks (and may also be related with recent
changes to the build configuration) and should be easily caught in
the tests.
Note that the WTAP_OPTTYPE_ values don't correspond to particular
options, they correspond to data types for options (some options
correspond to options with structured types defined in the pcapng
specification, but most correspond to generic types). I needed to remind
*myself* of that, so I'm adding it for the benefit of others.
The CI+ scrambler capabilities extension is a sequence of two elements.
Add a value string for the "capability" element in this sequence.
In the .TYPE_ATTR section, a sequence element must be addressed as
<sequence name>/<element name>. The generated header field for capability
is an FT_UINT64, we need a 64-bit value string.
iPerf3 is quite different from iPerf2 and so requires its own dissector.
Recognizes "control connection" messages (session cookies, connection
request refusal, etc) and data (labeled with its length, UDP messages
have their sequence number parsed)
It registers with TCP and UDP port 5201, which is unused by any other
dissector in Wireshark.
Add "utf-8" as an output mode to the follow tap for tshark.
This produces the same output that the Qt version does (passing
through all valid UTF-8, including control codes and internal
NULs, substituting illegal UTF-8 sequences with REPLACEMENT CHARACTER,
and not handling UTF-8 sequences split between unreassembled frames),
except for some differences which are common to how the tshark
and Wireshark Follow output differs for ASCII and EBCDIC as well:
Tshark includes additional header information and a line length
before each section of output, and leaves end-of-line terminators
untouched; Wireshark, due to the use of Qt code, automatically
translates end-of-line terminators to a LF (including from, e.g.
HTTP), except in "raw" mode. Neither tshark nor Wireshark write
in text mode, i.e. translate end of line terminators to a platform
specific CRLF on Windows.
Related to #19280
Some routines that are built only if libpcap 1.10.x is built with remote
capture support, but that are unconditionally declared in pcap/pcap.h,
now have stub implementations in macOS 14 that always fail and set the
error string to "not supported". (This was probably done because those
routines are now declared as "weakly linked symbols":
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
om macOS 14.)
This means CMakeLists.txt finds them when you build on Sonoma, so we end
up calling them.
The only place where we didn't arrange that we *only* use them if the
device name begins with rpcap://, indicating that it's a remote-capture
URL, was the code in dumpcap that produces packet counts for the
sparklines in the Wireshark main screen. That meant that all opens
failed, and dumpcap reported that failure to Wireshark, so no sparklines
were drawn. Check for rpcap:// in that case as well, and use
pcap_open_live() if it's not present.
For all code that calls the routines in question, if the any of the
routines in question fail, check for an error string of "not supported",
and replace it with "Remote capture not supported", so as to make the
cause of failure clearer.
Fixes#19349.
Value strings without quotes are prone to semantic confusion
with protocol names or reserved keywords.
Add a deprecation warning in preparation for removal in future
releases.
Add `hosts:` tap to `tap` method of `sharkd` which returns a list of
resolved hostnames found in the capture file, thus providing the same
information as `tsharks -z hosts`. The `hosts:` tap accepts an
optional list of comma-separated protocol names `ipv4`, `ip` (synonym
for `ipv4`) or `ipv6`. For example, `hosts:ipv4` returns only IPv4
hosts, `hosts:ipv6` returns only IPv6 hosts and `hosts:ipv4,ipv6`
returns both IPv4 and IPv6 hosts. If no protocol names are
given (i.e. if the request is just `host:`), both IPv4 and IPv6 hosts
are returned. In the response, IPv4 and IPv6 hosts are returned in
separate `ipv4_hosts` and `ipv6_hosts` arrays containing objects with
`name` and `addr` fields. Both arrays are sorted by the `name` field
of each object.
