Mark Phillips wrote:
If g_esp_enable_null_encryption_decode_heuristic is true, attempts to
decode the ESP packet contents:-
The code assumes that if this is a transport ESP NULL encrypted
packet it will contain a 12 byte (ie. SHA1 or MD5) authentication
trailer,
Note that "tvb_length_remaining(tvb, 0)" is equivalent to
"tvb_length()", and that "tvb_length()" returns the amount of *captured*
data in the tvbuff, which isn't necessarily the actual length of the
packet; if it's not, the calls that use "len - 14" and "len - 13" don't
necessarily fetch the data in the trailer.
Handling trailers correctly is a bit tricky, due to the possibility that
the captured data might have been cut short by a "snapshot length" or by
"slicing" or whatever the particular network analyzer that captured the
data calls it.
The right thing to do is probably to use "tvb_reported_length()" to get
the actual packet length on the wire, and to check whether the trailer
data is present, using, for example, "tvb_bytes_exist()". If it's not
present, you'd have to skip the heuristic, otherwise it's safe to fetch
"pad" and "encapsulated_protocol" and use them.
epan/dissectors/packet-udp.c
----------------------------
Fix UDP length calculation in decode_udp_ports. The code did not
correctly allow for the UDP header which means that if there is
additional data AFTER the UDP (ie. the ESP authentication field), its
length will be included in the length passed to the protocol contained
within the UDP packet.
I've checked that in, with some other cleanups of the length processing.