Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.
On 03/03/2011 03:39 PM, Jeff Morriss wrote:
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)?
[Finally got back to this again...]
Anders had sent me a couple of captures that exhibited the problem. I
got those working in rev 36304: it wasn't a problem in the reassembly
code but rather the TCP dissector's desegmentation logic. Since the SSL
dissector had almost exactly the same code in it, I copied the changes
over there too. Hopefully that helps Sake's case.
