Wireshark · Wireshark-dev: Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets

[Guy Harris <guy@xxxxxxxxxxxx>]

On May 5, 2011, at 10:39 AM, Fernandez, Rafael wrote:

> The issue is the following:
> 
> In epan/dissectors/packet-tcp.c-tcp_dissect_pdus():
> line 1993: get_pdu_len returns 322. Sets plen to 322.
> line 2053-2061: length_remaining is 144. Thus (length_remaining < plen) is true. Sets pinfo->desegment_offset and pinfo->desegment_len. tcp_dissect_pdus returns.

...meaning that the TCP segment handed to tcp_dissect_pdus() didn't have a complete message, so there's nothing more for it to do at that point.

> In my_dissector.c:
> 1. Once tcp_dissect_pdus returns, dissect_message returns.
> 2. dissect_message gets called soon after and calls tcp_dissect_pdus again.

...when the next segment is available.

dissect_message() should, at that point, have been handed to it by the TCP dissector a reassembled tvbuff containing:

	the 144 bytes from the TCP segment that was handed to it in the previous call;

	following it, up to 178 bytes of additional data from the next segment;

in which case...

> In packet-tcp.c-tcp_dissect_pdus:
> Line 1993: get_pdu_len gets called again. It read 4 bytes starting from the 178th (322-144) byte of the application message. Thus, it returns a garbage size.

...get_pdu_len() should be handed the reassembled tvbuff in question, with an offset argument of 0, so it should be reading the same 4 bytes that it did on the first call, *not* the first 4 bytes of the second segment.

dissect_message() is the dissector you registered with TCP as the dissector for your protocol, right?

> Don't you think there is an issue with this?

There's an issue with *something*, but, given that tcp_dissect_pdus() has worked and continues to work fine for a number of other protocols, it's not a simple or obvious issue.