Re: How can I reassemble fragments from two different datagrams in the same frame?

["Kukosa, Tomas" <tomas.kukosa () unify com>]

Hi Daniela,

I do not remember if I solved exactly the same problem but I fought with reassembling some time ago.

Looking to my code it seems that solution was to pass different 'id' parameter for each datagram.

Best regards,
  Tomas


From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Pitzschel, 
Daniela
Sent: Thursday, October 31, 2013 11:34 AM
To: wireshark-dev () wireshark org
Subject: [Wireshark-dev] How can I reassemble fragments from two different datagrams in the same frame?


Hi,

a problem has occurred with decoding reassembled fragments lately. I've searched the FAQ and mailing lists but found 
nothing about it.

When the last fragment of a datagram would be reassembled in frame x but another fragment of a next datagram would 
start in the same frame x, the entry of the last fragment of the first datagram will be overwritten by the next 
fragment of the next datagram.

By chance I found a test in wireshark\epan\reassemble_test.c which is deactivated but the comment says the following 
which describes exactly my problem:

/* Test 2 partial frags from 2 diff datagrams in the same frame */

/* datagram #1: frame 1 + first part of frame 2

datagram #2: last part of frame 2 + frame 3

Is this a valid scenario ?

The result of calling fragment_add_seq_check(&test_reassembly_table, ) for these fragments is a reassembled_table with:

id, frame 1 => first_datagram;  ["reassembled in" frame 2]

id, frame 2 => second_datagram; ["reassembled in" frame 3]

id, frame 3 => second_datagram;

Note that the id, frame 2 => first datagram was overwritten by the entry for the second datagram.

Is this OK ? IE: When dissected/displayed will the reassembled datagram 1 appear with frame 2 ?? */

/* visit id frame frag len more tvb_offset

   0    12     1     0    50   T      10

   0    12     2     1    20   F       5

   0    12     2     0    25   T      25

   0    12     3     1    60   F       0

*/

/* Is this a valid scenario ? Is this OK ? IE: When dissected/displayed: Will the reassembled datagram 1 appear with 
frame 2 ?? */

This is a valid scenario! So, how can I resolve this problem?

Is there a chance that wireshark can resolve it by changing the key mechanism so that the key does not only depend on 
the id and the frame?

If not, what can I do?

___________________________________________________________________________
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