| Main Archive Page > Month Archives > wireshark-dev archives |
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
From: Guy Harris <guy_at_nospam>Date: Thu May 05 2011 - 19:59:13 GMT
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
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-request@wireshark.org?subject=unsubscribe