These were detected by running check_typed_item_calls.py
with --consecutive, which flags items that have different
labels but the same filter string. Usually this is because
of copy/paste.
Quite a few similar bugs still exist, will address in a future commit.
Simple decompression algorithm that encodes a single byte and the
number of times it is repeated.
This algorithm can only be used in chained compression packets.
The compression header "reserved" field is now a flags field.
If the flags have the CHAINED bit, the meaning of the offset field
changes and becomes a length field.
"old" compressed method:
[COMPRESS_TRANSFORM_HEADER with Flags=0]
[OPTIONAL UNCOMPRESSED DATA]
[COMPRESSED DATA]
new "chained" compressed method:
[fist 8 bytes of COMPRESS_TRANSFORM_HEADER with Flags=CHAINED]
[ sequence of
[ COMPRESSION_PAYLOAD_HEADER ]
[ COMPRESSED PAYLOAD ]
Implements [1]. Some code was intentionally simplified from the previous draft
implementation, pending some real-world motivation.
[1]https://datatracker.ietf.org/doc/rfc8754/
Until now, mistakenly, the buffer for decompressing compressed BLIP messages
has been statically allocated as 16 Kb, but that is not valid behavior.
16 Kb is the maximum size of a _compressed_ frame. In theory, due to the
ability to zipbomb, there is virtually no upper bound on what the maximum
size of an uncompressed frame could be. However, to keep sanity, it has
been made into a preference with a reasonable default that is not likely to
be exceeded (64 Kb). The behavior before for this was that wireshark would
crash because the dissector would return NULL for a decompressed buffer due
to error and then try to deference it later. A null check has been added,
so that the behavior is now that the packet will show
'<Error decompressing message>' instead, and log why it couldn't handle the
compressed message. Closes#16866.
In requests:
There appear to be 2 bytes of unknown data (typically 0) after the
2-byte Request Flags field (are they just 2 bytes of additional flags?).
Skip past them before dissecting the iterator.
If there are no bytes remaining in the packet after the parent ID, stop
dissecting; some packets seem to stop there. For those requests, assume
that the response will contain :
entry ID;
entry flags;
subordinate count;
modification time;
base class;
relative distinguished name;
although the last of those might be something else (it appears to be of
the form "CN={name}").
In replies:
For each returned entry, if the requested field flags in the request had
the DSI_OUTPUT_FIELDS bit set, fetch the returned field flags and use
that to determine what fields are present; otherwise, use the requested
field flags.
In dissect_nds_request():
Fill in fieds of the ncp_record structure only on the first pass; once
the first pass is complete, the structure's fully filled in.
That fixes cases where NDS replies aren't fully dissected because the
NDS verb isn't added to the ncp_record structure when the request is
dissected.
Fill in elements as soon as we have the value needed to fill it in, so
that it's filled in even if we throw an exception later, and so that
it's filled in only if we have the value in the packet, so that a valid
value isn't overwritten by a later packet that doesn't have the value.
This fixes cases where, in the second pass, NDS replies aren't fully
dissected because the NDS verb is overwritten in the ncp_record
structure when a continuation of the request is dissected.
Note that we should perhaps make the object_name field a pointer to a
wmem-allocated string, so that NULL can indicate "not set, hence not
known".
Following changes in the file:
1. Explain usbll_address_t and usbll_data_t.
2. Grouping header fields belonging to the same type of packets.
3. Removed unnecessary condition check for usbll_data pointer
in dissect_usbll_data function.
4. Brief comments on the Macros.
5. Correct code indentation at a few places.
Signed-off-by: Ameya Deshpande <ameyanrd@outlook.com>
Use the DSI_ defines, rather than the raw hex values for bits, to make
it clearer what's being tested.
Make all of the DSI_ #defines, rather than just some of them, unsigned.
Playing with the sample capture from bugzilla bug 10562, dissection of
packet 491 (ecmp file_info request) brought up an expert info about a
malformed packet.
The request contains a list of requested attributes. For each attribute,
only the attribute ID is part of the request. The current code tries to
dissect each attribute, this fails when we only have a list of
attribute IDs...
Add a subtree for the list of IDs (and the length of that list).
While at it, remove some unnecessary variable initializers.
Commit 873d5980cd improved STUN heuristic to match TURN ChannelData messages.
It was based on the assumption that, looking at the "stun.type.method" field,
it should be trivial to determine if the current packet carries a TURN message
or not. However, at least one STUN/TURN implementation (Facetime) uses
unknown/custom TURN methods to set up a Channel Data. Fortunately, standard
TURN attributes are still used in the replies.
Improve such heuristic taking into account specific TURN attributes, too.
The list attributes have been taken from RFC5766.
Stream Specification: https://www.ilda.com/resources/StandardsDocs/ILDA_IDN-Stream_rev001.pdf
The stream specification only defines IDN messages. The other packet commands
like ping request, ping response, etc. (see line 25 - 31 in packet-idn.c)
are part of the hello specification which is not released yet. We were still
able to implement some hello packets since we received a preliminary version
of the hello specification, because we need the hello packets for our work.
related to #16707
Stream Specification: https://www.ilda.com/resources/StandardsDocs/ILDA_IDN-Stream_rev001.pdf
The stream specification only defines IDN messages. The other packet commands
like ping request, ping response, etc. (see line 25 - 31 in packet-idn.c)
are part of the hello specification which is not released yet. We were still
able to implement some hello packets since we received a preliminary version
of the hello specification, because we need the hello packets for our work.
related to #16707
This adds a protocol post-dissector for Community ID support to
Wireshark/tshark: https://github.com/corelight/community-id-spec
The protocol is disabled by default. It establishes one new filter
value, "communityid".
Includes test cases and baselines to verify correct Community ID
strings based on similar testsuites in the existing Zeek and Python
implementations.
Define a bew type name type-name="OctetStringOrUTF8" type-parent="OctetString"
to be used with OctetStrings that CAN be strings. This is a Wireshark
unique addition to the xml dixtionarys and makes use of BASE_SHOW_ASCII_PRINTABLE.
If a time field uses a standard enconding, we can call proto_tree_add_item()
to add it to the tree. There's no need to parse the time field ourselves.
Update two places in the afs dissector where the manual parsing can
easily be replaced with a proto_tree_add_item() call.
Martin Mathieson