Wireshark · Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.

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

Sake Blok wrote:
> On 3 mrt 2011, at 15:00, Anders Broman wrote:
>
> > 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?
> >  
> > There is a similar bug in the TCP reassembly causing it to not show the reassembled packet.
> > 1 0.000000 10.80.79.132 10.62.180.97 TCP [TCP segment of a reassembled PDU]
> > 2 0.000004 10.80.79.132 10.62.180.97 TCP [TCP segment of a reassembled PDU]
> > 3 0.238283 10.80.79.132 10.62.180.97 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
> > 4 0.716280 10.80.79.132 10.62.180.97 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
>
> SSL reassembly and decryption also does not like duplicates. Instead of solving it in each and every upper layer protocol, I think it could be solved by having an option to "Auto-ignore duplicate packets", preferably referencing the frame of which it is a duplicate in the INFO column.

Shouldn't the reassembly code (I suppose SSL reassembly uses that code) 
just ignore duplicates [for all protocols that have sequence numbers]? 
In my mind, SCCP should be somewhat of a special case because it does 
not have sequence numbers (it is designed to run on lower layers that 
prevent duplication or mis-sequencing).

Okay, maybe I need to go look in the reassembly code...

Decryption might be a-whole-nother problem--unless it's failing because 
of reassembly problems?