Re: SCCP reassembly broken for duplicateded SCTP messages.

[Sake Blok <sake () euronet nl>]

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.

How does that sound?

Cheers,


Sake


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe