| Main Archive Page > Month Archives > wireshark-dev archives |
Re: [Wireshark-dev] TCP dissector handling TCP Fast Retransmit
From: Jeff Morriss <jeff.morriss.ws_at_nospam>Date: Fri Apr 29 2011 - 16:23:47 GMT
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Jeff Morriss wrote:
> 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.)
I got some more feedback that the change helps, so I scheduled it to be
backported to 1.4.7.
___________________________________________________________________________
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