Wireshark-dev: Re: [Wireshark-dev] SCCP reassembly broken for duplicated SCTP messages.
From: Anders Broman <anders.broman@xxxxxxxxxxxx>
Date: Thu, 3 Mar 2011 17:04:37 +0100
 

-----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