Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.
Anders Broman wrote:
Hi,
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?
I had tried to solve this before in the SCCP dissector by trying to use
the "segments remaining" as a quasi-sequence number (and assuming
Wireshark's generic reassembly routines handled duplicate data
correctly), but I couldn't get it to work because the "segments
remaining" (of course) goes down as you get more packets, but the
reassembly routines want incrementing sequence numbers. (I thought of
building new routines with decrementing sequence numbers but after
looking at the reassembly code I gave up pretty quickly.)
Another option might be to (in SCTP, for example) not pass duplicate
TSNs to the subdissectors, instead marking them as "[retransmission]" in
COL_INFO. That would actually have some usability benefits: I can't
count the number of times I (or a colleague) have been confused by a
trace only to eventually realize we were looking at (a lot of)
retransmissions. [Okay, just adding TCP-style COL_INFO blurbs for
retransmissions would achieve the same usability benefit.]
I don't think setting something in pinfo would work, though: there may
be (and often are) multiple SCTP chunks in a given frame and when you're
retransmitting, there is a high chance that some chunks will be
retransmissions while others are new transmissions. We wouldn't want a
single retransmitted chunk to mess up dissection of all the others in
that frame.
