Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jeff Morriss
Sent: den 3 mars 2011 16:30
To: Developer support list for Wireshark
Subject: 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.
What about passing the TSN in pinfo->private_data and use that as a sequence number?
Regards
Anders
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
