This IE has been recently renamed in GSUP protocol spec [1] and main
implementation (libosmocore) [2] from "PDP Type" to "PDP Address",
update it here too.
While at it, properly dissect the type_org, type_nr and address buffers.
[1] 602fabc6d5
[2] 74ee02420a
Similar to the UMTS MM Context, when the Extended Access
Restriction Data length is greater than 1, handle the length
but indicate that we don't dissect it yet.
Also fix two of the UMTS MM Context expert infos being added to
the wrong tree.
Fix#19630
The Endace ERF format has extended the 'Interface Id' from 2 bits (interface 0-3) to 3 bits (interface 0-7).
The Interface Id high order bit is not adjacent in the flags field.
Extend wtap handling for ERF records.
Extend epan dissection and display of ERF format.
The existing erf.flags.cap field is retained and extended to 0-7.
A new erf.flags.if_raw field is added for the unformatted value.
Note proto_tree_add_split_bits_item_ret_val() cannot be used here because it only supports input from the tvb and not from a non-tvb value.
Some of the functions in proto.c when handling a FT_BOOLEAN field
allow it to be part of a 64 bit unsigned integer with a 64 bit
bitmask. Other functions do not. Some of the functions start out
allowing a 64 bit bitmask and then switch to casting the value to
a 32 bit unsigned integer (but others don't.) Consistently allow
a boolean to be extracted using a 64 bit bitmask by changing the
various proto_tree_add_boolean functions to allow a 64 bit unsigned
integer value parameter.
There was only one function adding a boolean that already took
a 64 bit value, proto_tree_add_boolean_bits_format_value64, a
counterpart of proto_tree_add_boolean_bits_format_value. It was
never used anywhere and not WS_DLL_PUBLIC, so it is safe to remove
in favor of having the latter take a uint64_t.
Note that _proto_tree_add_bits_format_value, as a comment says:
"does not receive an actual value but a dimensionless pointer to that value.
For this reason, the type of the header field is examined in order to determine
what kind of value we should read from this address.
The caller of this function must make sure that for the specific header field
type the address of a compatible value is provided."
Both proto_tree_add_boolean_bits_format_value and
proto_tree_add_boolean_bits_format_value64 called that function, one
passing a pointer to a guint32 as a void*, the other passing a
pointer to a guint64. In both cases it was cast to a guint32*, which
was less than ideal in the value64 case. Fix that.
This is related to #19552, as it is necessary in order to add support
for passing a UInt64 value to a boolean field (as oppposed to extracting
it directly from the tvb.)
Vendor Data for the Status Message CM and the Status Message Interface
are not required to have a multiple of 2 as length.
Also ASAM CMP UDP encapsulation was missing.
Closes: #19626
Use the ws_log system instead of a special #define for RTMPT.
If Wireshark isn't compiled for the Debug target, the compiler
will optimize away all these calls.
Ping #19519
We remove layers when a dissector rejects a packet and returns 0.
When a dissector handles desegmentation, it can accept a packet
(return a non zero length) but actually consume zero bytes by
setting desegment_len to a different value and desegment_offset to 0.
That indicates that no bytes were actually consumed because a
future segment is needed.
In such a case, nothing should be added to the tree anyway. On the
next pass the dissector shouldn't be called again (or should have
the same behavior again). The layer needs to be removed on the first
pass in case there are additional PDUs still to be processed in the
frame, so that those PDUs get the same layer number on the first
pass that they'll get in subsequent passes, which affects reassembly
and other various file scoped structures that use the layer number.
Fix#19609
RFC 3550 does not define the structure of Profile-Specific
Extensions for RTCP at all. As the name implies, they are
supposed to be defined by a profile, with the understanding that
different applications would use different profile names.
In practice, those few standards that use Profile-Specific
Extensions all claim to use the standard "RTP/AVP" profile
from RFC 3551, which does not define any RTCP SR/RR profile-
specific extension, and add a proprietary extension. The ones
we know about so far as MS-RTP and IPMX, which unfortunately
use different values for the length (bytes vs the common RTP
practice of "number of 32-bits words minus 1"), but do use
a 16 bit type field.
Use a FT_UINT16 dissector table and register the known MS-RTP
types to that, instead of dissecting all profile-specific
extensions as MS-RTP and calling packets malformed.
Fix#19393
Add information about legacy version to the blurbs for client_version
and server_version.
Scan ClientHellos and ServerHellos for the supported_versions extension.
If we find it, add a PI_CHAT (usual workflow) expert info to the now
legacy_version field indicating that it MUST be ignored and that
the supported_versions extension MUST be used instead.
Add a server version expert info, similar to the one for the client
version, if the legacy version field specifies 1.3, because that's
not allowed in [D]TLS 1.3 because of middleboxes.
Related to #19624
tvb_get_raw_bytes_as_string doesn't check lengths, because it's
used elsewhere when the length is unknown. If we use
tvb_get_string_enc, that checks the offsets and throws an
exception as appropriate, but then we have to use g_utf8_strreverse
due to the possibility of UTF-8 REPLACEMENT CHARACTERs.
To handle embedded nulls properly, we need to be using counted
strings (like wmem_strbuf_t) in more places.
Fix#19621
Stat tap windows can be opened by the GUI (e.g., a
ServiceResponseTimeDialog) when no file is open, and persist
past a file being closed, i.e. outside of wmem_file_scope().
Items concerning the taps should not be created in wmem_file_scope().
This fails an assert, which crashes when built for a Debug target.
To use wmem, we would need to create a scope appropriate for the lifetime
of the ServiceReponseTimeDialog or other Tap dialog (or else add a
callback mechanism to srt table to free items created in epan scope.)
Partially revert 47b310da47
(the part where the stat taps are concerned.)
Related to #19620
Queried DNS names can be enabled for DNS staticstics with a preference.
Due to performance reason this is disabled by default.
Kind of related to #16728 and #16173
This patch changes the display order of the IEEE802154 address fields
only for the IEEE802154 tree root. The order of the address fields
for the other trees is not changed. The order is now source address
first. This is not the same as the order in the frame, where the
destination address is first. However, reading it from left to right
makes more sense when the source address is first.
This commit implemements PLDM dissector
for the Platform specification of the protocol
which is done following DMTF guideline
documentation -
https://www.dmtf.org/sites/default/files/standards/documents/DSP0248_1.2.0.pdf
Testing : For verification of dissector
pcap file collected during host poweron
is used as well as used custom pcaps.
Signed-off-by: Riya Dixit <riyadixitagra@gmail.com>
There's a number of variables that are lengths that should probably
be unsigned, but at least make sure negative values don't get assigned
to the chunk size, which can lead to an infinite loop. (It's read from
the packet as an unsigned 32 bit integer, but it should never in
practice have a value in the top half of that range.)
Fix#19617
If Wi-Fi packet is encapsulated in an UDP payload (IPIP tunneling),
then we can use this functionality to decode it as 802.11.
This is intended primarily for [1].
[1] - https://docs.zephyrproject.org/latest/samples/net/capture/README.html
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Fixed dissector cannot parse `zbee_zdp.assoc_device_count`
field error. Thanks to Mohammed Suhel mhs@exegin.com for
original implementation.
Change-Id: I3f65aee3d5cc156b8512b3e877746522439b823b
Only 1 of the 4 bytes comprising the window field was actually
being read, causing the value to be incorrect. The offset pointer
was correctly increased by 4 on the following line, so this is
clearly just an oversight.
The configure-window-mask field was being dissected using the
"window value mask" bitmasks. It was interpreted correctly when
dissecting the actual fields, though, so this is clearly just
another minor oversight.
Before:
window: 0x00000001
configure-window-mask: 0x0003, background-pixmap, background-pixel
x: 448
y: 156
After:
window: 0x03800001
configure-window-mask: 0x0003, x, y
x: 448
y: 156
This is a little annoying because the OTOA field that determines the
encoding is many fields after the OAdC field. Also annoying because
the encoding is faintly absurd, and not the same as the other
"IRAString" encoding; that one is also a hex string, but uses
*unpacked* GSM 7 bit encoding. Here we have a hex string encoding of
a SMS-like "number of used semi-octets" followed by packed GSM 7 bit
encoding.
Fix#19599
Add Huffman decoding from libngttp2 library (MIT licensed),
and use it in HTTP/3 to display the decoded QPACK bytes.
(HTTP/2 and HTTP/3 use the same Huffman encoding.) These
files are not part of the public libnghttp2 library but
normally internal.
Note that libnghttp3 does not supply a function to inflate
headers like nghttp2_hd_inflate_h2.
Related to #16761
Correcting offset miss in !13077
Due to offset for octet 4 is skipped earlier, the remaining lenght becomes wrongly.
To correct the fault, offset for octet 4 is need to be added after IE has been decoded
Build on !13975 to add human-readable descriptions for all heuristic
dissector tables in Wireshark.
Chosen names are meant to give some info on when a heuristic dissector
lookup will be made. Terms like 'fallback' are used when the heuristic
is only consulted if other checks do not result in dissection, for
example.
People with more intimate knowledge of the protocols and dissectors
involved are encouraged to suggest or implement better descriptions.
Add a field to `struct heur_dissector_list` to hold a human-readable
description of the heuristic dissector list. The field is named
`ui_name` to parallel `struct dissector_table`.
Add `register_heur_dissector_list_with_description()` to register a new heuristic
dissector list with a description as well as a name. Change
`register_heur_dissector_list()` to be a thin wrapper which passes a
null description.
Add `heur_dissector_list_get_description()` to get the description from
a `heur_dissector_list_t` (which is an opaque type).
Modify the Qt user interface so that heuristic tables listed in *View →
Internals → Dissector Tables* show the description in the left column
and the short name in the right column, as is the case for other
dissector table types. For heuristic dissector lists which do not have a
description, repeat the short name in the left column to resemble how
the dialog was presented before this change.
Revise function name based on feedback
X.75 is not the same thing as LAPB, and we already *have* a LAPB
dissector that registers for WTAP_ENCAP_LAPB. Two dissectors
registering for a value in the wtap_encap table means one of them will
lose, so it does not work; in this case, the LAPB dissector loses.
Fixes#19595.
If the supported_versions extension is provided in the Client Hello,
display the mimimum supported version given in the extension in the
Protocol column if the session TLS version is unknown. Use the minimum
version because we don't know what the server will agree to, but it
must be at least this version.
This only affects when the Server Hello or other authoritative
messages haven't been seen, so in first-pass dissection (live
capture or one pass tshark) or a capture that doesn't contain
authoritative messages at all.
Fix#16114
If we have a packet that isn't long enough to fit an entire header,
but the first byte does look like a message type, and we can do
reassembly, ask for reassembly.
Fix#19593
For RTMP connections where we get the handshake, continue to use
the initial value of 128 as done in the protocol; we should get
any Set Chunk Size messages.
For connections where we don't get the initial handshake, i.e.
the connection is already in progress when the capture is started,
allow setting a different default chunksize. Note that both too
large and too small values will cause problems, but the since the
initial bytes of chunks can have any value, it's very difficult
to do this heuristically.
Fix#12403 (by setting the preference to a large value, e.g. 60000,
everything is dissected correctly in that capture.)
Some systems repeatedly send out SDP setup information for the same
RTP conversation. We end up setting up multiple conversations
(it's not clear we need to, since most of the information we copy
to per-packet info for subsequent passes.)
When doing so, copy the per-SSRC number space information that
determines what cycle number we're on for extended sequence numbers
and timestamps (since those fields can and do wrap.)
This doesn't hurt at all if the setup information is for different
conversations, even ones using the same SSRC; it aligns the cycle
number but that's fine. It helps a lot in cases where the RTP
sequence number has already overflowed and then we get a duplicate
SETUP message; we need to stay on the same cycle.
Fix#19592
RTMPT doesn't use the native reassembly API, so store the frames that
are involved in reassembly of a packet and mark the depended upon
frames itself so that exporting selected packets doesn't omit them.
Dissect the X.509 v3 Certificates used in OPC UA.
Use proto_tree_add_bytes_with_length for adding NULL bytes to
the tree with a (0) length different than the length taken up
in the tvb. It's somewhat nicer than changing the item length later.
Dissector is improved as follows:
- Code cleanup
- Added comments
- Offset calculations more obvious
- Segment data is put into segment hf instead of data dissector
- Padding is calculated and shown to fix incomplete dissector warnings
This patch does:
- clean up the address handling and limit to guint16 (see UDS)
- add address length to the data exchanged to UDS
- make UDS show the correct length in the protocol line instead of 2
- show address in UDS as generated as they are passed to UDS
RF4CE NWK heuristics should not attempt to verify the command ID from a command frame type when security is enabled, since in such case the command ID will be encrypted
A problem with the RTMP dissector is that it allocates space up
front for messages based on a 24 bit message length field, and if
that length is bogus (e.g., fuzzed data), that can easily lead to
memory exhaustion. (#6898) However, the real value can be quite large,
and limiting the value with a preference causes real data to fail to
dissect and report as malformed (#3790).
An ideal solution would be to use the standard reassembly API, possibly
by having the TCP dissector do it via setting pinfo->desegment_offset
or pinfo->desegment_len, or possibly by having reassembly tables within
the dissector. Quirks about the protocol make this a bit difficult.
In the meantime, instead of allocating all the memory for a reassembled
packet upfront upon reading the message length, limit the initial
allocation size, and call wmem_realloc if needed. In the cases where
the length is bogus and we don't actually get message bytes later,
we don't allocate nearly as much memory, but in the cases where the
message really is that large, dissection will work without having to
fiddle with a preference.
Mark the preference as obsolete, because users shouldn't need to change it.
(We can reduce the initial max allocation size from this if need be
with little penalty, saving some memory when there's bogus values in
exchange for more reallocation for legitimate large messages.)
Fix#3790.
This check should be for when the maximum number of iterations
reaches zero, rather than declaring a loop the first time it is reached.
AMF dissection is being aborted and never succeeding.
Fixup 24403a9a35
A zeroed sessionkey is the failure state that is checked, but we
can return early from the function if there are problems with
the challenge response. Move the memset to the top of the function,
as is already done with v2.
Fix#19570
If hashing a newly created GBytes, unref the GBytes after computing
the hash (and before returning it.)
Fix#19558 (in combination with 45b929a1b6
and 6f17dcd67d)
If the full checksum and partial checksum are the same (because
the contribution from the TCP payload doesn't change it), don't
call it a partial checksum.
This is already done in UDP.
If we're replacing the principal, unref the current one, if it
exists.
Push a cleanup function to free the principal and label in case
of hitting an exception dissecting the packet.
Related to #19557
Extended EH Elements, which are still not defined as of DOCSIS 4.0
and must be ignored (CM-SP-MULPIv4.0-I08-231211), are not recursive
but instead have a full byte each for type and length instead of
a nibble, allowing specifying more than 15 extended header types or
extended header types with length longer than 15.
Increment the position for the first type/length byte to make the
logic more straightforward.
Part of #19557
Make sure we fully initialize an endpoint_guid struct. Blind attempt
at fixing
```
==23447== Use of uninitialised value of size 8
==23447== at 0xDAF0816: wmem_map_lookup (wsutil/wmem/wmem_map.c:264)
==23447== by 0x7DE388C: get_domain_id_from_tcp_discovered_participants (epan/dissectors/packet-rtps.c:6518)
==23447== by 0x7DE33AB: dissect_rtps (epan/dissectors/packet-rtps.c:13741)
```
in #19558.
Update IAX2 handling for 2a9bc63325
and b61c0ac536.
Since a non-existent header field in the array is now 0 instead of -1,
change the test.
Fixes warnings like:
** (tshark:166575) 04:45:49.318472 [Epan WARNING] -- Dissector bug, protocol IAX2, in packet 4903: epan/proto.c:10972: failed assertion "n > 0 && (guint)n < gpa_hfinfo.len" (Unregistered hf!)
Related to #19557
Try dissecting with usb.protocol both using device class triple and
interface class triple. This allows dissecting Bluetooth requests on
composite devices and/or when Device Descriptor class code is not one
of the Bluetooth codes.
Set URB transfer type in USB conversation info when handling control
requests. Set endpoint to magic NO_ENDPOINT8 value when control request
is directed to interface to prevent using whatever value was last stored
there (do not set endpoint to 0 to prevent clear_usb_conv_tmp_data()
from clearing interface class, subclass and protocol values).
Mostly just passing pinfo around a little bit more, but in rf4ce-nwk we
weren't doing anything with the allocated value anyway, so just use the
regular proto_tree_add_item.
According to IEEE 802.1Q 21.5.3.2, if the Chassis ID Length field is 0,
then the Chassis ID Subtype is not present. Thus the number of octets
used for the Chassis ID is 1 (the length field itself) if the length is
0, and 2 plus the length value if the length is > 0.
According to 21.5.3.6, the Management Address Length field should not
be present if the Management Address Domain Length has the value zero.
If it is present anyway (as in the file provided in #13720), handle it
but add an expert info.
Fix#13720
The length values given to proto_tree_add_item for SBAS MT1 - MT5
dissection did not always correctly match the bitmask in
hf_register_info causing a retrieval of wrong values. Align the length
values and bitmasks for a correct retrieval of field values.
Update to the latest specification, which specifies the currently used
value for 'invalid' as 'backward compatible (do not use)'.
See
IEC 61850-9-2 Edition 2.1 2020-02,
Section 8.6 Definitions for basic data types – Presentation layer functionality,
Table 21
Be aware that in the specification the bits are numbered in reverse (it
specifies the least significant bit as bit 31 instead of as bit 0)!
Signed-off-by: Ferry Huberts <ferry.huberts@pelagic.nl>
With the growth of the member registry they became part of the
protocol registrations for use with decode as.
Extend the code space reserved for member registrations, to
exclude these and new members for the foreseeable future.
Instead of storing all found SCTP associations in one linked list,
use maps.
Store associations where only one vtag is known in one map, hashed
by the ports. (This effectively is a list indexed by the ports.) Store
associations where both vtags are known in another map, hashed by the
vtags. After an association has been setup, most lookups should be
fast, using the vtags. This should be much faster than searching the
entire list of associations each time for captures with many
associations.
Assume vtag collisions are rare. When we have INIT ACK packets, the only
packets that have both vtags in a single packet, do not require that
addresses match. Otherwise, when matching two half associations into
a full association, require that addresses match as well as ports.
Requiring address matching for cases lacking INIT ACK packets (such as
a stream of DATA frames back and forth) prevents false positives
(especially in cases where ephemeral ports are not used and source and
destination ports are the same.)
Eventually we ought to track the additional addresses given in INIT,
INIT ACK, and ASCONF packets and use those as well.
Fix#19544
Always send the association information to the SCTP tap, if
we've filled in at least one tvb. Always add it to the tree
as well, by using the association index calculated for the
first chunk.
Note in a comment that we should only need to calculate the
association index for the first chunk of bundled chunks; while
there are some chunk types with exception verification tag
handling (RFC 9260 8.5.1), they shouldn't be bundled with other
chunk types. We should have an expert info for that situation.
(Previously, we were calculating the association index for all
chunks and using for the packet the last one calculated.)
Initialize the association index and direction when beginning
dissection, in case we throw an exception when getting the
chunk type to see if RFC 9260 8.5.1 applies.
Part of #19544
Martin Mathieson
Pau Espin
Vadim Yanitskiy