Wireshark mailing list archives

GPRS SNDCP acknowledged mode packet reassembly (bug 2857)


From: "Mike Morrin" <Mike.Morrin () ipaccess com>
Date: Mon, 25 Jan 2010 14:37:12 -0000

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






This message contains confidential information and may be privileged. If you are not the intended recipient, please 
notify the sender and delete the message immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom


___________________________________________________________________________
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

Current thread: