close#19485
At the same time, this commit fixed a bug introduced from MR !12306 that
cause the encoding attribute unable to be parsed (the {,50} should be
{1,50}).
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
Guy Harris