Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Thu, 03 Mar 2011 10:29:31 -0500
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.