Normally, 'control' and 'otherbss' flags are set when
using monitor mode, but certain Wi-Fi drivers (e.g. MT7921)
need to explicitly have these flags set in order to capture
control frames.
Make sure we fetch AWS_PROFILE if it exists. Don't add AWS_PROFILE or
AWS_REGION if they're already in the profile and region lists. Fix our
default values.
The libsinsp plugin API recently changed the way plugins are opened.
Update falcodump to match.
Plugins might return a nested and "$ref"ed config schema. Update our
parsing code to match.
The remote-capture-command option does not work when selecting
remote capture command selection 'other' from the extcap capture
options dialog. Fix strcmp statement to actually check for 'other'.
Fixes: #18381
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.)
Changes:
- The tool now recognizes which software is running on a device - IOS, IOS XE
or ASA. Based on it, it uses correct sequence of commands to setup
capture, read captured packets and clear the capture.
- The tool reads packets on the fly so you don't have to wait till
--remote-count of packets is reached.
- The tool reads timestamps from capture on the device for IOS and ASA (on
IOS-XE, there is no timestamp in dump).
- Except Windows platform the tool handles early stop of capture on the device
and clear of capture buffer on the device (it finish the capture).
- There are special interface names to allow the tool to generate
specific capture types.
- Data collection and config cleanup is handled in two separated ssh
sessions.
- Documentation updated.
Closes#17672.
Changes:
- The tool now recognizes which software is running on a device - IOS, IOS XE
or ASA. Based on it, it uses correct sequence of commands to setup
capture, read captured packets and clear the capture.
- The tool reads packets on the fly so you don't have to wait till
--remote-count of packets is reached.
- The tool reads timestamps from capture on the device for IOS and ASA (on
IOS-XE, there is no timestamp in dump).
- Except Windows platform the tool handles early stop of capture on the device
and clear of capture buffer on the device (it finish the capture).
- There are special interface names to allow the tool to generate
specific capture types.
- Documentation updated.
Closes#17672.
Changes:
- The tool now recognizes which software is running on a device - IOS, IOS XE
or ASA. Based on it, it uses correct sequence of commands to setup
capture, read captured packets and clear the capture.
- The tool reads packets on the fly so you don't have to wait till
--remote-count of packets is reached.
- The tool reads timestamps from capture on the device for IOS and ASA (on
IOS-XE, there is no timestamp in dump).
- Except Windows platform the tool handles early stop of capture on the device
and clear of capture buffer on the device (it finish the capture).
- There are special interface names to allow the tool to generate
specific capture types.
- Documentation updated.
Closes#17672.
Rename init_progfile_dir to configuration_init. Add an argument which
specifies our configuration namespace, which can be "Wireshark"
(default) or "Logwolf".
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.
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.
For historical reasons our logging inherited from GLib the logging of
some levels to stdout. Namely levels "info" and "debug" (to which we
added "noisy").
However this practice is discouraged because it mixes debug output
with application output for CLI tools and breaks many common usage
scenarios, like using tshark in pipes.
This change flips the logic on wslog to make logging to stderr the
default behavior.
Extcap subprocess have a hidden dependency on stdout so add that.
Some GUI users may also have a dependency on stdout. Because
GUI tools are unlikely to depend on stdout for programatic output
add another exception for wireshark GUI, to preserve backward
compatibility.
This should allow simultaneous logging to the console and the log
file when running an extcap from the CLI.
One difference is that the extcap error/warning dialogs in the GUI
have extra information in standard wslog format (may or may not
be a good thing).
If we have a log file write everything to the file, to provide
a complete picture in the log.
Debug information cannot be written to the parent process when
running in child mode.
This matches the original implementation and allows displaying
logs to the console, including debug information, when running
an extcap from the CLI for testing and development purposes.
This should make extcap logging bug-for-bug compatible with the
behavior before dc7f0b88bb.
Extcaps require a log file when invoked in child mode. It also has
a specific flag to enable debugging, other that the wslog options.
Fix the logging to:
1. Enable debug log level if --debug is used.
2. Do not emit messages to the stderr if debug is enabled.
This brings extcap logging to the same feature level it had before
wslog replaced GLib logging.
Gerald Combs