Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.
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)?
