Call fflush in udpdump and ciscodump after writing the pcap header
so that it is actually written out even if no packets have arrived yet.
By doing so, dumpcap no longer blocks in cap_pipe_open_live waiting
for the pcap header from the extcap pipe until the first packet is
captured, but instead goes on to (attempt to) open its output.
This means that if we capture no packets that a capture file with
a header but no packet records will be created (and, if not a temp
file, will have to be cleaned up), but that is consistent with tshark
and Wireshark behavior otherwise.
This means you can no longer do a capture to a FIFO or Named Pipe
in this order:
1) Start dumpcap
2) Create the FIFO or Named Pipe
3) Start the flow of packets to the UDP port
which only worked when not dissecting packets. It was broken if tshark
also needed to dissect packets, but evaded the checks for if we were
writing to a FIFO or Named Pipe resulting in behavior mysterious to
users, such as only writing to one of the Named Pipe readers on Windows
(or failing if there aren't enough instances), or having tshark and
the other pipe reader compete for the pipe input and eventually failing
on UN*X.
Instead, the FIFO or Named Pipe needs to be created before launching
dumpcap, or else an ordinary file will be created (on UN*X), or an
error about not being able to open the output (on Windows, since
Named Pipes have a magic prefix, and you can't create an ordinary
file with a named pipe filename.)
Fix#17900.
snprintf(), sensibly, takes a size_t argument specifying the size of the
buffer. g_snprintf(), bogusly, takes a gulong argument specifying the
size of the buffer, so we had to do casts to avoid narrowing complaints,
but we're just using snprintf() now (as we require C11 or later), and
don't need the casts any more.
Related to #18009 - Have randpkt default to pcapng, allow selecting
a different capture file format via the common -F option that other
command line tools use, and document it.
For the randpktdump extcap, just use pcapng.
This fixes --all-random, because --all-random requires different
encapsulation per packet. It also fixes the related -r option to
randpkt (though note that picking a file format that doesn't support
ENCAP_PER_PACKET with -r causes problems.)
Document -r in the randpkt man page.
Fix#18944
Forcing the use of a dedicated header to replace pcap.h is
unnecessary code and mental overhead in this case. We can
use config.h instead for the same purpose of defining a
macro symbol before including pcap.h.
After android T, BT process might be called i.e.
com.google.android.bluetooth, instead of com.android.bluetooth
It depends on what APEX version is installed.
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.)
John Thacker