Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] GPRS SNDCP acknowledged mode packet reassembly (bug 2857)

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Mon, 25 Jan 2010 21:37:04 +0100
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