Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Thu, 03 Mar 2011 15:39:42 -0500
Jeff Morriss wrote:
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...

Does rev 36131 help? (After throwing caution--or the belief that I could not grok that code--to the wind) I found a small bug in the reassembly code: if the length of the retransmission, when added to the length of data already seen, was greater than the expected size of the reassembled packet, we stopped reassembling. If the retransmission was close to the final fragment and the final fragment was (as is common) smaller than the others, you'd see the problem.

I suspect there's another bug in there, though: isn't it common in TCP to see something like:

Frame	TSNs included:
-----	--------------
1	0-49
2	50-99
3	50-150 [50-99 are a retransmission but 100-150 are new]

If so, the current code will (I think) drop the data from frame 3.

Anyway, if this doesn't help, can you send me a capture where reassembly doesn't work (due to packet duplication/retransmission)?