Re: GPRS SNDCP acknowledged mode packet reassembly (bug 2857)

[Jaap Keuter <jaap.keuter () xs4all nl>]

Hi,

I assume this goes over a stream oriented transport protocol only?

Thanks,
Jaap

Mike Morrin wrote:
> I was having a go at fixing this bug, and the problem (as stated in the 
> bug report) of correctly identifying the correct endpoint (TLLI and 
> SAPI) is fairly easy to solve.
>
>  
>
> Unfortunately, having got that in place, reassembly still does not work 
> because the acknowledged mode SNDCP Segmentation protocol has 
> characteristics which are not compatible with the current reassembly 
> functions.
>
>  
>
> For a given endpoint, SNDCP fragments are sequentially numbered modulo 
> 512 (using the LLC N(S)), the fragment number does not reset to 0 at the 
> beginning of each SNDCP packet.  Only the first fragment of each packet 
> has the NPDU number of the packet, and the size of the packet is only 
> known when the last fragment is received with a !more flag. 
>
> This all means that the fragment buffer may contain fragments from 
> several different packets, and these cannot (generally) be segregated 
> until all of the fragments of a packet are received.
>
>  
>
> The current reassembly functions has deep rooted assumptions that the 
> first fragment of a packet has sequence number 0, and that the fragment 
> list contains fragments from only one packet, both of these assumptions 
> must be broken to reassemble acknowledged mode SNDCP (are there other 
> protocols that break these assumptions?).
>
>  
>
> So assuming I don’t lose enthusiasm for this, I see only 2 solutions:
>
>    1. Write a completely new reassembly function that is specialised to
>       this protocol.
>    2. Generalise the existing reassembly functions so that they don’t
>       have the 2 assumptions above, and (with a new wrapper) can handle
>       protocols like acknowledged mode SNDCP.
>
>  
>
> I think 2. would be a nicer solution, but it is significantly more 
> difficult due to the obscure nature of some of the existing reassembly 
> code.  Any advice out there?
>
>  
>
> Mike

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe