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.
when a new AR is established between devices which already
has another AR, same station_info was used and it caused wrong
dissection problem of IOCS and IOData objects of related AR.
In order to fix problem, new struct is added in order to match
station_info and corresponding ARs. New struct is used for
keeping ARUUID, related inputCR and outputCR frame IDs and
setup/release frame numbers of ARs. ARUUID's are used for
adding station_info data to their corresponding conversations.
If matching ARUUID and Frame IDs are found in RTC frame
dissection, then corresponding IOCS and IOData objects are
dissected.
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
Gerald Combs