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

Jeff Morriss wrote:
> > Anders Broman wrote:
> > > > Hi,
> > > > SCCP reassembly will add both segments from duplicated packets thus 
> > > > producing garbage in the reassembled packet.
> > > > An "easy" fix could perhaps bee to add a flag in pinfo "duplicate" 
> > > > or "suspected duplicate" and ignore such frames in reassembly, 
> > > > possibly the Dissector doing reassembly could have a preference 
> > > > wether to use the flag or not - thoughts?
> > > I had tried to solve this before in the SCCP dissector by trying to 
> > > use the "segments remaining" as a quasi-sequence number >(and 
> > > assuming Wireshark's generic reassembly routines handled duplicate 
> > > data correctly), but I couldn't get it to work because the "segments 
> > > remaining" (of course) goes down as you get more packets, but the 
> > > reassembly routines want incrementing sequence numbers.  (I thought 
> > > of building new routines with decrementing sequence numbers but after 
> > > looking at >the reassembly code I gave up pretty quickly.)
> > >
> > > Another option might be to (in SCTP, for example) not pass duplicate 
> > > TSNs to the subdissectors, instead marking them as 
> > > >"[retransmission]" in COL_INFO.  That would actually have some 
> > > usability benefits: I can't count the number of times I (or >a 
> > > colleague) have been confused by a trace only to eventually realize 
> > > we were looking at (a lot of) retransmissions.  >[Okay, just adding 
> > > TCP-style COL_INFO blurbs for retransmissions would achieve the same 
> > > usability benefit.]

Rev 36159 modified the SCTP dissector to not pass (detected) 
retransmissions to subdissectors.  Comments/feedback are welcome.