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

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.]

I don't think setting something in pinfo would work, though: there may 
be (and often are) multiple SCTP chunks in a given frame and when you're 
retransmitting, there is a high chance that some chunks will be 
retransmissions while others are new transmissions.  We wouldn't want a 
single retransmitted chunk to mess up dissection of all the others in 
that frame.