|Main Archive Page > Month Archives > wireshark-dev archives|
Jeff Morriss wrote:
> On 03/07/2011 10:54 AM, Gerald wrote:
>> --- On *Mon, 3/7/11, Jeff Morriss /<email@example.com>/* wrote:
>> From: Jeff Morriss <firstname.lastname@example.org>
>> Subject: Re: [Wireshark-dev] TCP dissector handling TCP Fast
>> To: "Developer support list for Wireshark"
>> 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:
>> 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
>> 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 <email@example.com>