2011/5/6 Jeff Morriss :
> Oh, those out-of-order packets are quite possibly the problem: see the
> recent discussion here on "Handling TCP packets reordering".
Would love to fix this problem somehow, but I'm lack of knowledge of
wireshark's core :(
--
Max
___
On May 5, 2011, at 1:49 PM, John Sullivan wrote:
> I think knowing these things is pretty useful for the prospective
> dissector writer - it certainly gives a better feel for the dynamics
> of dissection and may help optimize the places where expensive work is
> done - so I think that section of
Fernandez, Rafael wrote:
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
ireshark
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
On Thursday, May 5, 2011, 9:06:27 PM, Chris Maynard wrote:
> Fernandez, Rafael writes:
>> There are only TCP packets in my capture file.
> That may be true, but as described in the doc/README.developer file in section
> 1.2 Skeleton code,
>A protocol dissector may be called in 2 different w
On May 5, 2011, at 1:06 PM, Chris Maynard wrote:
> Note, however, that you must fill in column information, create
> conversations, reassemble packets, build any other persistent state
> needed for dissection, and call subdissectors regardless of whether
> "tree" is NULL or not. ...
I.e
Fernandez, Rafael writes:
> There are only TCP packets in my capture file.
That may be true, but as described in the doc/README.developer file in section
1.2 Skeleton code,
A protocol dissector may be called in 2 different ways - with, or
without a non-null "tree" argument.
If the pro
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->de
support list for Wireshark
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
On May 5, 2011, at 8:59 AM, Fernandez, Rafael wrote:
> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
> offset)
> {
>gui
On May 5, 2011, at 8:59 AM, Fernandez, Rafael wrote:
> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
> offset)
> {
>guint remaining = tvb_length_remaining(tvb, offset);
>guint last_size = tvb_get_letohl(tvb, offset)+MESSAGE_HEADER_SIZE;
So, in your pro
Sent: Thursday, May 05, 2011 1:26 PM
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
Fernandez, Rafael writes:
> OK. This function returns exactly the same as yours. The rest of the code in
there for debugging purposes.
Fernandez, Rafael writes:
> OK. This function returns exactly the same as yours. The rest of the code in
there for debugging purposes.
You're right. I got distracted by the comparison still being done between
last_size and remaining.
> Don't you think there is an issue with this?
Can you try
On 05/05/2011 16:59, Fernandez, Rafael wrote:
> All,
>
> I used to have a very simple get_message_tcpmessage_len. But most of the TCP
> packets would then say [TCP segment of a reassembled PDU].
> I eliminated everything again. This is my current get_message_tcpmessage_len:
>
> guint get_message_t
rg
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
Fernandez, Rafael writes:
> This is my current get_message_tcpmessage_len:
>
> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
> offset)
> {
> guint r
Fernandez, Rafael writes:
> This is my current get_message_tcpmessage_len:
>
> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
> offset)
> {
> guint remaining = tvb_length_remaining(tvb, offset);
> guint last_size = tvb_get_letohl(tvb, offset)+MESSAGE_HE
hark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Chris Maynard
Sent: Thursday, May 05, 2011 10:00 AM
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
Fernandez, Rafael writes:
>
On 05/05/2011 16:27, Chris Maynard wrote:
> Graham Bloice writes:
>
>> The
>> get_message_tcpmessage_len function should also check that there
>> are enough bytes in the passed in tvb to call tvb_get_letohl(),
>> as the OP's code did.--
> I don't think that's the case
Graham Bloice writes:
> The
> get_message_tcpmessage_len function should also check that there
> are enough bytes in the passed in tvb to call tvb_get_letohl(),
> as the OP's code did.--
I don't think that's the case as tcp_dissect_pdus() is told how many bytes are
n
On 05/05/2011 16:00, Chris Maynard wrote:
> Fernandez, Rafael writes:
>
>> I am writing a dissector plugin and I am using tcp_dissect_pdus in order to
> reassemble packets. However, I
>> am experiencing issues when there are multiple application layer messages in
> one packet and the last one
>> i
Fernandez, Rafael writes:
> I am writing a dissector plugin and I am using tcp_dissect_pdus in order to
reassemble packets. However, I
> am experiencing issues when there are multiple application layer messages in
one packet and the last one
> is not complete. Specifically, I have 5 messages in o
Hi,
I am writing a dissector plugin and I am using tcp_dissect_pdus in order to
reassemble packets. However, I am experiencing issues when there are multiple
application layer messages in one packet and the last one is not complete.
Specifically, I have 5 messages in one TCP packet. There are 5
21 matches
Mail list logo
