Both dynamic and egfx channel had problems during the second pass.
For the dynamic the problem is that the reassembled packet usually contains multiple PDUs,
so the first pass works correctly, but given that there's multiple PDUs we can't attach
a single data to pinfo for the second pass. To fix that we compute a hash for the PDU and attach
the correct contextual info associated with this hash, that info will be used during the
second pass.
The patch fixes the same kind of bug in the egfx channel and zgfx uncompressed bits (the zgfx
compression is stateful so we need to save the uncompress buffer for the second pass).
In the dynamic channel, in capabilities packets some fields are present only after version 1
of the protocol.
Added some new EGFX version capabilities (also is listed the bogus 10.6 version that was
exposed in the previous specs).
The display of versions in EGFX capability message has been reworked to correctly show
a tree.
Use ws_utf8_truncate to ensure that truncating the result of
tvb_format_text will not split a UTF-8 character. (50 bytes
is not necessarily 50 UTF-8 characters, but 50 UTF-8 characters
don't necessarily have a visible width of 50 characters anyway.)
Fix#18831
Just because a field's value is used in the string that's hashed to
compute a JA3 or JA3S hash, that doesn't mean it should be put into a
variable named "ja3_value", as that doesn't indicate what it *is*. Use
meaningful names instead.
You're Not Supposed To Do That, as per RFC 8446 section 4.1.2 "Client
Hello".
Also do the equivalent check for DTLS, as RFC 9147 Section 5.3 "Client
Hello" says You're Not Supposed To Do The Equivalent. We don't yet
handle DTLS 1.3, but if we ever do....
Fixes#18851.
While we're at it, improve two comments to clarify what
ssl_dissect_hnd_hello_common() does (and to fix one place where the old
comment was incorrect).
Increase the proto item size so that the ethertype is selected as part
of the cisco-metadata protocol.
Signed-off-by: Gabriel Ganne <gabriel.ganne@gmail.com>
Do not modify global data pointer when redissecting packets. This fixes
transient incorrect packet sequence errors when user navigates packet
list when live capture is in progress.
RTP is commonly multiplexed on the same UDP 5-tuple with STUN, DTLS, and
other protocols including ZRTP. RFC 7983 gives current best practices for
dealing with the multiplexing that doesn't involve assuming that version
0 packets are always the same protocol. Implement that for the "what to do
if RTP packets have the wrong version number" preference and set it as the
default.
Only use this setting when RTP is being dissected non-heuristically
(leave heuristic dissections to the other protocol's heuristic
dissector.)
This avoids a problem of the STUN heuristic dissector setting itself
to be the new dissector for an RTP conversation (cf issue #18148).
This also allows dissection of TURN ChannelData multiplexed on the
same 5-tuple as RTP set up by, e.g., SDP.
Fix#18832