Write WTAP_ENCAP_MPEG_2_TS to its native format, which
means just writing the packet bytes. This allows opening
up a transport stream, filtering, and writing the result
back in its native format instead of a pcap/pcapng.
Use the special SCSI handling and exception for when data is
truncated due to a too short allocation_length. See packet-scsi.h
for discussion.
Related to #13397
MS-RSVD, in specification versions 7.0-10.0, changed the
SenseInfoExLength and SenseDataEx fields so that instead of
SenseDataEx being a variable length field with length given by
SenseInfoExLength, SenseDataEx was a fixed 20 octet field where
SenseInfoExLength gave the length of meaningful data in the field.
Then it was changed back.
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rsvd
Luckily, there's a Length field that measures the size of the struct
with the other fixed fields plus SenseDataEx, but not the other
variable field, the DataBuffer. In the version with the fixed 20
octet field, Length MUST be 36 (which indeed is the only value
consistent with a 20 length SenseDataEx.)
Fix#13397.
We create the task on the first pass, but should only do
so if we haven't seen the request ID yet (it is guaranteed
to be unique on the client by spec.) Don't create it a
second time for the response on the first pass if we've seen
the request.
When creating the task on a response, fill in the request/response
frame information correctly (that is, reversed from a request)
instead of treating the response as a request.
The op-code value won't be known if we haven't seen the request
yet, but if it happens later we can see it on the second pass.
Previously we created the task on the first pass a "request" task
even for responses, which caused some quirks on first-pass dissecting
and on redissection after changing preferences.
Related to #13397
Some capture options can be overridden with command line arguments.
We want those options, like -p, -n/-P, -H, -S, and --update-interval,
to take precedence over preferences, at least until the user saves
preferences or switches profiles (at which point the new settings
will be applied.) That means we have to apply preferences to capture
options before we read most command line arguments.
However, preferences can be altered at the command line, including
the preferences that affect the capture options. So we have to
read the command line arguments that alter preferences after
reading preferences (which has to be after reading command line
arguments that control what preferences are read, like the
configuration profile), but before applying preferences to the
capture options.
Add a new "process some command line options" function that only
gets the command line options that override preferences. Final
interleaved command line / preference / capture options sequence:
1. Read command line arguments that affect what preferences to read
2. Initialize capture options to default value
3. Read preferences
4. Read command line arguments that affect value of already read
preferences
5. Apply preferences to capture options
6. Read other command line arguments, set capture options final values
7. Apply other preferences
Fix#14549
RFC 9000 12.2 "Coalescing Packets" notes:
"Retry packets (Section 17.2.5), Version Negotiation packets (Section
17.2.1), and packets with a short header (Section 17.3) do not contain
a Length field and so cannot be followed by other packets in the same
UDP datagram."
However, if we have a DCID with a non-zero length, then we can search
for coalesced packets by searching for the DCID. If the DCID length
is sufficient, then this has a low probability of false positives.
Note that we are still not relaxing another condition mentioned:
"Senders MUST NOT coalesce QUIC packets with different connection IDs
into a single UDP datagram." An implementation might do so through
GSO, I suppose (particular if multipath is in use?)
Fix#19109
Mongo uses the same port whether using TLS or not. When dissecting
over TCP, used some heuristics based on the opcode to determine whether
or not it looks like Mongo directly. If not, reject it; the TLS
heuristics are good and should pick it up.
Still register the port in the TLS port dissector, just don't set
TLS as the default for that TCP port, in order to test insecure Mongo.
Also, use whether the Response To field is nonzero for setting
the Info column as a response, since recent Mongo uses the
same Message opcode for both requests and responses.
Fix#14381
When changing a value in Advanced preferences the index given to
dataChanged() must be made for correct parent.
Update all columns because the font may have changed.
The recent files are read from recent_common in main.cpp, which
happens before the prefs are read. (This is largely unavoidable,
as we need some things in recent first, notably the last used
preference Configuration Profile.)
That means we add the recent files before we've read the preference
that determines the maximum number of recent files, so it still
has its initial value of 10 - the number of files in recent_common
will be whatever value the last used Configuration Profile had
for the preference, and could be greater (or lesser) than 10.
It could also be different than the value for the preference
after the preferences are loaded, if Wireshark is started with
command line options like -C, -o, or -P.
Add a parameter so that on initial startup, when recent_common is
read, we add all the files to the list heedless of the pref value.
Add connections so that the Menu and the Welcome Page list update the
list of recent files whenever the Preferences are changed
(including from changing Configuration Profiles), because
that might change the max number of recent files.
Add a few guards for putting too many items in the recent common
file or the menu, for when the preference changes so that the
maximum count is lower than it was previously.
Fix#16782
As per
https://ask.wireshark.org/question/32969/what-does-ko-mean-in-http-load-distribution-statistics/
1) treat a "100 Continue" as OK rather than an error; it's not obvious
why 100 is different from other 1xx status values, and ">" rather than
">=" might just have been a mistake;
2) use "Error", rather than "KO" for 4xx and 5xx (and undefined)
statuses, as it's not necessarily obvious what "KO" means.
Initially taken from the Wiki page (including images, compressed
with tools/compress-pngs.py), and expanded to cover lastest additions.
Link the Help button from the 802.11 Decryption Keys UAT to the page.
Fix#11273
This isn't used anywhere, but since we're storing key as
a GByteArray the bytes are multiplied by 8, instead of 4 when
it was stored as a string.
Fixup 24570a3573
Have parse_key_string take a pointer to char* (such as
the one from a uat_update_cb_t) and set the failure reason
when returning NULL. This should be more user friendly than
just "Invalid key format".
Related to #11273
dot11decrypt and packet-ieee80211 don't need to do the same
conversion from string to byte array, and they don't need to
uselessly copy the strings around
parse_key_string does all the validity checking; it doesn't return
a decryption_key_t with a valid type otherwise, so the 802.11
dissector shouldn't waste time checking that.
Just have parse_key_string store the key as a GByteArray.
For WPA with password, that means we store the length instead of
using a null-terminated string, but that's a bonus anyway since
it allows us to handle opaque byte strings with internal NULs, which
802.11 does technically allow.
Also clean up the API a bit by passing a struct to a static
function, making it easier to change later.
The 802.11 key UAT has several ways to specify keys. Most of them
are hex byte strings, but the wpa-pwd method allows specifying
a passphrase and optionally the SSID separated by a colon. The
wpa-pwd method also allows percent-encoding, which therefore
means that percent must be percent-encoded (as "%25").
The SSID is percent-decoded upon input parsing. The key is
percent-decoded upon use. Percent-decode the WPA passphrase
upon parsing too, instead of waiting until use. The methods
other than wpa-pwd enforce that the key is uses hex bytes, so
percent-encoding should have been a no-op for those.
By percent-decoding immediately, we can check if the length of
the passphrase is legitimate *after* decoding, instead of before.
Percent-decoding can only shorten the number of octets.
Enforce only one colon present before percent-decoding, because
we can't tell whether the user intended one of the other colons
(and which one) to be in the password or the SSID, or if it
just marked an implicit comment field.
The Wireless toolbar has the SSID in a different column, removing
the need to look for a separator. That would make more sense
(see #11273), but would be less backwards compatible.
Eliminate an unnecessary string copy. Eventually we would want
to return an error string explaining why parsing failed, so the
user gets something more than just "Invalid [X] key format".
Fix#10296
Add support for command line parameters, rename the preference to match.
Use the correct `SSLKEYLOGFILE` environment variable name in the text.
Rename SSL to TLS, we are no longer in 1999. Clarify that applications
other than browsers can be selected. Various dialog text improvements.
Move the Launch button to the right to make it stand out more.
Relates to #19471
Zigbee R23 adds a definition for a previously reserved field which now
denotes that Frame Counter verification is required. This field is
now dissected.
WS_LOG_DOMAIN has to be set before the first time ws_log.h is
included (or else the domain will be set to null.)
It generally should be set immediately after config.h
For the dot11decrypt files, it's set in dot11decrypt_debug.h,
so that should be the include immediately after config.h
Other header files can end up including wslog.h - for example,
dot11decrypt.c was not getting its log domain set properly because
of the following chain of includes:
epan/proto.h -> epan/packet_info.h -> epan/address.h ->
wsutil/ws_assert.h -> wsutil/wslog.h
John Thacker