Anders Broman wrote:
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.
What about passing the TSN in pinfo->private_data and use that as a sequence number?
But then there's really no guarantee (especially on loaded associations)
that the segments will be in sequential chunks. IOW, SCCP would
probably (regularly?) see significant gaps in the sequence numbers.