I completely agree with your answer. That is what I expect to happen.
I was able to download wireshark-1.5.2-SVN-36997, compile against it, and the
issue still happens.
I must note that there is a [TCP Previous segment lost] and a [TCP
out-of-order] 10 frames apart and it is also where the problem starts occurring
until the end of the capture file.
I now register a different dissector for UDP and TCP.
Nonetheless, This is my current code:
void dissect_tcp_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4,
get_tcp_message_len,
dissect_tcp_message);
}
void dissect_tcp_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
if (check_col(pinfo->cinfo, COL_PROTOCOL))
col_set_str(pinfo->cinfo, COL_PROTOCOL, "MyMessage");
gint32 length, type, legacy;
if(tvb_bytes_exist(tvb, 0, MESSAGE_HEADER_SIZE))
{
length = tvb_get_letohl(tvb, 0);
type = tvb_get_letohl(tvb, 4);
legacy = tvb_get_letohl(tvb, 8);
}
else
{
call_dissector(data_handle, tvb, pinfo, tree);
return;
}
if (check_col(pinfo->cinfo, COL_INFO))
{
col_add_fstr(pinfo->cinfo, COL_INFO, "[%s] ",
typeAsString(type));
col_set_fence(pinfo->cinfo, COL_INFO);
}
if(!tree)
{
return;
}
proto_item *base_item, *header_item, *body_item;
proto_tree *base_tree, *header_tree;
base_item = header_item = body_item = NULL;
base_tree = header_tree = NULL;
base_item = proto_tree_add_item(tree, proto_mymessage, tvb, 0, -1,
FALSE);
base_tree = proto_item_add_subtree(base_item, ett_mymessage);
header_tree = proto_item_add_subtree(base_item, ett_mymessage);
header_item = proto_tree_add_item(base_tree, hf_header, tvb, 0,
MESSAGE_HEADER_SIZE, FALSE);
body_item = proto_tree_add_item(base_tree, hf_body, tvb,
MESSAGE_HEADER_SIZE, -1, FALSE);
header_tree = proto_item_add_subtree(header_item, ett_mymessage);
proto_tree_add_int(header_tree, hf_header_length, tvb, 0, 4, length);
proto_tree_add_string_format_value(header_tree, hf_header_type, tvb, 4,
4, "", "%s [%d]",
typeAsString(type),
type);
proto_tree_add_int(header_tree, hf_header_seq, tvb, 8, 4, legacy);
}
guint get_tcp_message_len(packet_info *pinfo, tvbuff_t *tvb, int offset)
{
return tvb_get_letohl(tvb, offset)+MESSAGE_HEADER_SIZE;
}
-----Original Message-----
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: Thursday, May 05, 2011 2:59 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
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
CONFIDENTIALITY AND SECURITY NOTICE
The contents of this message and any attachments may be confidential and
proprietary and also may be covered by the Electronic Communications Privacy
Act. This message is not intended to be used by, and should not be relied upon
in any way, by any third party. If you are not an intended recipient, please
inform the sender of the transmission error and delete this message immediately
without reading, disseminating, distributing or copying the contents. Citadel
makes no assurances that this e-mail and any attachments are free of viruses
and other harmful code.
___________________________________________________________________________
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
