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
Otherwise the dissected fields shown up are really misleading.
It is totally fine sending len=0, as explained in TS 29.060 sec 7.7.28:
"If MS Network Capability is not included, its Length field value shall
be set to 0."
In Quic Connection Migrations are possible even without source
connection IDs. Currently, after connection migration Wireshark fails to
associate answers with zero length CIDs for the new address to the
original connection.
After migration when the client sends data from the new IP
the connection data needs to be associated with the new conversation.
So when the server answers and the connection is identified by the
conversation a connection is found.
Fix slot definition subfield format to give an 8 bit slot duration if set to 0, update the 11 bit mask to be 11 bits,
and add a custom formatter to print the slot duration in uS
epan/proto.c:9468 -- proto_register_field_init(): 'rdpudp.flags.ack' exists multiple times with incompatible types: FT_UINT16 and FT_BOOLEAN
epan/proto.c:9468 -- proto_register_field_init(): 'rdpudp.flags.data' exists multiple times with incompatible types: FT_UINT16 and FT_BOOLEAN
Similar to other changes to the dissection and display of UTC Time, changed
Smart Energy time fields to display both UTC text time and UTC Time as a
number with the number as the field value for t-shark. As UTC Time is used
elsewhere, broke that functionality out into the main ZCL file, but Smart
Energy applies a special meaning where the value 0 means 'now' independant
of the actual time, this is restricted to Smart Energy uses of UTC Time.
Thanks to Cole Wu <colewu9712@gmail.com> for the original implementation and
support.
The non-Huffman encoded QPACK bytes are added to the tree as
FT_BYTES, and they are expected to be probably printable
ASCII but treated as opaque data if not. That's
BASE_SHOW_ASCII_PRINTABLE, which makes the values a little more
useful in the tree.
Move some of the less useful messages to ws_noisy, the rest to
ws_debug. (A few of the errors could be ws_info, which isn't
displayed by default either.)
Part of #19519
Return the number of bytes decoded and placed in the tree and
set pinfo->desegment_offset and desegment_len so that the QUIC
disssector can desegment the HTTP3 Encoder stream.
Pass that number of bytes to the nghttp3 decoder so that we don't
end up passing the same bytes twice with reassembly.
Make it so the QUIC data stream desegmenting code puts a link
to the frame data was reassembled in for segments that begin
an MSP as well in more cases, as the TCP dissector does.
(There are a few more cases TODO to produce results similar to
TCP.)
Fix#19475
See
1. https://www.tcpdump.org/linktypes/LINKTYPE_NFLOG.html
2. The `nla_put(inst->skb, NFULA_TIMESTAMP, sizeof(ts), &ts))`
call in net/netfilter/nfnetlink_log.c in the Linux kernel source.
Add support for 16-byte and 12-byte seconds/microseconds time stamp, to
match what we already have for seconds/nanoseconds time stamps, in
`proto_tree_add_item()` etc., and use that.
Fixes#19525.
Store the QPACK encoder stream state, such as the number of insertions
in the current segment and the total so far, and retrieve it on subsequent
passes. Passing the data to the nghttp3_qpack_decoder on subquent
dissections creates confusion and inaccurate results.
We don't have to memdup the buffer unless we're actually doing the
decoding.
We can later use this information in order to defragment QPACK
table insertion instructions that are split across QUIC packets.
Related to #19475
Don't bother trying to desegment and calling the subdissector indicated
by the app handle / ALPN for a zero length stream payload segment. It
won't work, and it messes up our methods of determining if desegmentation
is needed.
Revisit this is there ever is a protocol on top of QUIC that must
be called with a zero length payload segment.
Fix#19497
Space is set aside in an array of hfs for UPSTREAMFIELD_NOTUSED (0),
presumably because that's easier than applying an offset to the
type value. However, an hf is never registered.
On 4.2 and earlier it ends up adding an empty "text only" field to
the tree, because the hfindex is initialized to zero (as a static
array). Since the hfindex 0 no longer corresponds to the text only
field (but means an unregistered field), the bug has been exposed.
There's already a FT_NONE field for an unknown type greater than
the maximum value. Let's use that for this type, which is also
contrary to spec.
Seen in fuzzed data (#19522)
SOME/IP-SD sends out a StopSubscribe entry followed by a Subscribe
entry, if the previous Subscribe was not answered. This patch adds an
expert info to show that.
Update the functions that get an interface name or description
to also take the section number in the record (0 if not present.)
Store a mapping of SHB number and interface number to global
interface number, and provide a function to access it. Use the
function to display the correct interface name and description
when there are multiple SHBs.
Use this information to rewrite interface numbers when writing a
pcapng file through wtap dumper, since we don't write additional
SHBs to a file when dumping. We could, but we'd have to store
exactly when to write the extra SHB when reading the file in
sequentially (unlike the other internal blocks, IDB, NRB, and
DSBs, that we intentionally move to the start.)
Since we're changing the number of sections, perhaps we should edit
the SHB options more?
Merging handles interface numbers in its own manner, but also needs
to know about the per-SHB interface ID to global ID mapping when
doing so.
Capinfos and capture file properties still require a bit more work
for proper output.
Fix#16531, fix#18049
Pass the tvbuff and offset into read_qpack_prefixed_integer
instead of raw pointers, and call tvb_get_ptr before doing
the pointer arithmetic. This throws a ReportedBoundsError if
we're trying to get something at an illegal offset, instead of
crashing.
Catch the ReportedBoundsError there and when adding the opcode
to the tree in order to break out of the loop instead of having
malformed packets and failing to pass information to the qpack
decoder.
Pass the entire stream buffer to the nghttp3 qpack decoder,
not just what is decoded; it saves state and doing so is
necessary in order to handle QPACK instructions that are split
across QUIC packet boundaries.
We don't properly put the QPACK information into the proto
tree when it's split across boundaries still, but it at least
is processed by the decoder so that the HEADERS are now properly
displayed.
The QPACK information is also still passed to the decoder every time
a packet is dissected, which eventually results in the decoder erring
out (especially with random packet access.)
Fix#19502. Related to #19475.
When copying an address to a struct declared on the stack
used as a temporary lookup key, use copy_address_shallow.
When copying an address to a wmem_file_scope()d conversation
data, use copy_address_wmem(wmem_file_scope(), ...)
This commit implemements PLDM dissector
for the base specification of the protocol
which is done following DMTF guideline
documentation -
https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.1.0.pdf
Testing : For verification of dissector
pcap file collected during host poweron
is used.
Signed-off-by: Riya Dixit <riyadixitagra@gmail.com>
Change "[TCP segment of a reassembled PDU]" to
"[TCP PDU reassembled in <frame #>]" in the Packet List.
This fixes a bug where the former message was displayed in cases
where the PDU was not in fact reassembled such as when a frame is
missing from the capture.
TCP: Show the frame in which a PDU is reassembled
Added six checks for "'[TCP PDU reassembled in'" which are necessary
to prevent the display of that info from breaking the testing
commits of others.
These commits are squashed.
TECMP 1.7 states that the first byte of the Device ID is always 0x00, so
we can detect ASAM CMP on this. The older TECMP versions allowed that
byte to 0xff for user-defined Device IDs. Since traces with TECMP 1.6
and before still exist, the ASAM CMP Detection is updated to allow the
first byte to be 0xff in TECMP too.
zbee_zcl.attr.utc is a string representation of the time. This time is based on an uncommon epoch.
Someimes the numerical value for UTCTime is convenient (e.g. sorting by numbers rather than
string represenations of time). This numerical value is now both displayed in the UTC Time field
and a second filter field utc_raw has been added for when the numerical value is needed,
for example when using t-shark.
Thanks to Cole Wu <colewu9712@gmail.com> for the original implementation and support validating
this update.
If the first QUIC packet in a frame is an Initial or 0-RTT packet,
then we know that the handshake cannot be completed until the other
side responds. Thus it is impossible for subsequent packets in the
same frame to be Short Header packets on the same connection (which
is what check_dcid_on_coalesced_packet() tests), as the 1-RTT keys
cannot have been negotiated. This is true even with GSO/GRO.
It is possible for Initial packets to be coalesced with 0-RTT or
Handshake packets, and it might be possible for a frame to have
a first QUIC packet be a Handshake packet and subsequent packets
be 1-RTT short header packets.
Fix#19503
There is no need to use parsed class version from descriptor, simply use
the interface protocol to determine USB Audio class version. Repurpose
the audio class data to store Entity ID to type mapping. The mapping is
necessary to determine control selectors that depend on entity type.
The packet reassembly was not always done correctly and was sometime making wireshark
to segfault. The patch reworks packet reassembly, making it a little simpler. It also
tracks first and last packet of reassembly, so if needed we could add links to these frame
in the future.
Also the progress information used to also be erronous in some intermediate packets, the
patch fixes that.
The eomtype variable is used only inside dissect_ipars. Make it a local
variable. It's always set before it's used, there's no need for an
initial value.