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.