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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to