If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
Support decrypting captures with Fast BSS Transition roaming present
by now also scanning (re)association frames for relevant information
elements and feeding it into the dot11decrypt engine.
Both (re)association request and response frames are scanned to allow
for potentially missing one frame and still be able to derive PTKs
needed for successful decryption.
Closes#17145
Change-Id: I08436582e4f83695dc606ddb92ff442d6258ef9b
If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
Add comments in various switch statements warning people *not* to add
standardized block types or option codes that aren't in the pcapng spec.
If you want a standardized block or option type, go through the
standards process.
Give details on what happens when running Wireshark from a GUI on
UN*Xes, or, at least, on {macOS,Ubuntu+GNOME,Ubuntu+KDE}, although
it's probably similar on other UN*Xes and on other desktop environments.
Have routines to report capture-file errors, using libwireshark error
codes and strings, that call through a pointer, so they can pop up
dialogs in GUI apps, print a message to the standard error on
command-line apps, and possibly do something different on server
programs.
Have init_report_message() take a pointer to structure containing those
function pointers, rather than the function pointers themselves, as
arguments.
Make other API changes to make that work.
At least on my just-now-installed Kubuntu 20.04 VM, G++ wasn't installed
by default, and you need that to compile Wireshark (you can avoid it if
you're not building the GUI code, but the GUI code is Qt-based, so it's
in C++). Add both GCC and G++ to the basic list.
The "Selected packet" caption is wrong, as there could be more than one
packet selected. Furthermore, in the non-Windows "export specified
packets" dialog, the caption is "Selected packets only", so go with the
full caption.
The "Marked packets" caption also lacks the "only" that it has in the
other dialog; add it as well.
Only a tiny amount of code outside libwiretap needs to know about
pcap/pcapng LINKTYPE_ values, and all that code needs to know is, for a
given LINKTYPE_ value, what the corresponding WTAP_ENCAP_ value is.
Nothing should need to know, for a given WTAP_ENCAP_ value, what its
LINKTYPE_ value is.
Make it the case that nothing *does* need to know, for a given
WTAP_ENCAP_ value, what its LINKTYPE_ value is. Export
wtap_dump_can_write_encap() and use *that*, in the "import hex dump"
code, what formats can be written to a pcap file.
Dialogs has same order of buttons:
- dialog specific (Flow Sequence, Find Reverse, Analyze, Reset Diagram)
- common voice functions (Prepare Filter, Play Streams)
- exports (Copy, Export)
- Close of dialog
Names were unified:
- Copy really copying to clipboard
- Save/Export was unified to Export
Combine exp_pdu_file_open() is called only by do_export_pdu(); just
combine them into one routine.
Get rid of the exp_pdu_t * argument to do_export_pdu(); instead, have
the exp_pdu_t structure be a local variable in that routine. There's no
need to initialize exp_pdu_data.pkt_encap in
ExportPDUDialog::on_buttonBox_accepted() - do_export_pdu() already does
so.
The return value of do_export_pdu() isn't used; don't return anything.
It's *not* for use by plugins, it's *only* for use by existing built-in
file type/subtype modules to provide support for an old deprecated
mechanism in Lua code.
The export PDU API now allows writing to a different file type. tshark
already has a -F flag for the output file type. If that option is given,
respect it for export PDU. Also, rec.rec_header.packet_header.pkt_encap
expects WTAP encapsulation types, not PCAP encapsulation types, so don't
call wtap_wtap_encap_to_pcap_encap(), or else it won't actually write to
pcap files, only pcapng (using the wrong sort of encap numbers eventually
leads to WTAP_ENCAP_PER_PACKET, which we don't write to non-pcapng.)
Allow "-U ?" as well as an empty argument; an empty argument is a bit
counterintuitive.
Simplify the introductory line of output - asking for a list of taps
isn't an error in which the user failed to supply a tap name, it's a
case where the user suplied a request for a list of tap names.
Just use fprintf() to print the list, and indent the elements of the
list, as we do with other lists of valid arguments.
List the valid arguments if the user specified an invalid argument as
well.
On Windows, a write to a pipe where the read side has been closed
apparently may return the Windows error ERROR_BROKEN_PIPE, which the
Visual Studio C library maps to EPIPE, or may return the Windows error
ERROR_NO_DATA, which the Visual Studio C library maps to EINVAL.
So, on Windows, for errors other than the ones for which we're reporting
a special error message, check for EINVAL with a *Windows* error of
ERROR_NO_DATA and, if that's what we have, don't print an error message;
otherwise, print an error message that reports a message based on the
Windows error (rather than a relatively uninformative "Invalid argument"
error).
This should fix issue #16192.
Clean up indentation while we're at it.
The right format to use is "%" G_GUINT64_FORMAT. A guint64 might be an
unsigned long or it might be an unsigned long long; do not assume which
one it will be on all platforms.
Add missing entries, regularize the descriptions, etc..
Note that pcap and pcapng are the native formats.
Fix various issues.
Update the editcap -F output to match urrent reality.
While we're at it, sort the libwiretap modules, putting observer.c in
the right place.
The default value for the CAN-ID Mask is currently 0. If no config is
present, all comparisons would be always true. This leads to all CAN
packets are being dissected by this dissector by default.
This is a huge performance problem and surely not intended.
This patch sets the default of the CAN-ID Mask to 0xffffffff, so that
in the unconfigured case, only the CAN-ID 0 would be dissected.
Guy Harris