Wireshark mailing list archives
Re: TCP dissector handling TCP Fast Retransmit
From: Jeff Morriss <jeff.morriss.ws () gmail com>
Date: Wed, 23 Mar 2011 22:17:10 -0400
On 03/07/2011 10:54 AM, Gerald wrote:
--- On *Mon, 3/7/11, Jeff Morriss /<jeff.morriss.ws () gmail com>/* wrote:
From: Jeff Morriss <jeff.morriss.ws () gmail com>
Subject: Re: [Wireshark-dev] TCP dissector handling TCP Fast Retransmit
To: "Developer support list for Wireshark" <wireshark-dev () wireshark org>
Date: Monday, March 7, 2011, 10:09 AM
Gerald wrote:
> Hi all,
>
> I'm working on a dissector for a TCP-based protocol, and I'm
wondering if there is any good way to handle when a TCP
retransmit/fast retransmit occurs in the middle of the stream.
>
> I will try to explain what is happening in one test case.
>
> First my dissector is called with some data. The TCP response
spans many TCP packets, so I keep setting pinfo->desegment_offset to
0 and pinfo->desegment_len = DESEGMENT_ONE_MORE_SEGMENT.
>
> After about 5 packets there is a TCP retransmission of the first
packet, and the retransmitted data is sent to the dissector.
>
> Then the data that should have been next in the stream is sent to
the dissector, but without any of the previous data, leaving the
dissector unable to handle it.
>
> So I guess I have 2 questions.
>
> 1) Is there any way to handle this elegantly so that I can get a
good dissection that ignores the retransmitted data?
>
> 2) Barring #1, is there any (hopefully simple) way to determine
if the data received by the dissector is retransmitted data?
I've spent a little time in the past few days looking at this issue,
based on this thread:
http://www.wireshark.org/lists/wireshark-dev/201103/msg00016.html
I got a couple of (private) captures off-list that show where the
TCP desegmentation stuff is breaking in the face of retransmissions
and have been trying to figure out what is going on and how to fix it.
Stay tuned.
___________________________________________________________________________
Thanks. If it makes any difference, I have discovered that if I go
through and manually ignore the retransmissions in the UI, the
reassembly works fine.
I finally got back to this and fixed it in rev 36304. Please let me know if it works for you too. (I did not schedule it to be backported to the 1.4 trunk--it might make sense to do so if it works for everybody.)
___________________________________________________________________________ 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
Current thread:
- TCP dissector handling TCP Fast Retransmit Gerald (Mar 07)
- Re: TCP dissector handling TCP Fast Retransmit Jeff Morriss (Mar 07)
- Re: TCP dissector handling TCP Fast Retransmit Gerald (Mar 07)
- Re: TCP dissector handling TCP Fast Retransmit Jeff Morriss (Mar 23)
- Re: TCP dissector handling TCP Fast Retransmit Gerald (Mar 07)
- Re: TCP dissector handling TCP Fast Retransmit Jeff Morriss (Mar 07)
