[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

Jeff Morriss wrote:
> On 03/07/2011 10:54 AM, Gerald wrote:
> > --- On *Mon, 3/7/11, Jeff Morriss /<jeff.morriss.ws@xxxxxxxxx>/* wrote:
> >
> >
> >     From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
> >     Subject: Re: [Wireshark-dev] TCP dissector handling TCP Fast 
> > Retransmit
> >     To: "Developer support list for Wireshark" 
> > <wireshark-dev@xxxxxxxxxxxxx>
> >     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.