-----Original Message-----
From: [email protected] 
[mailto:[email protected]] 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 <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to