This is our old Q&A Site. Please post any new questions and answers at


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?

asked 22 Jul '13, 04:56

ws_user13's gravatar image

accept rate: 0%

edited 31 Oct '13, 02:38

Hi again!

Still need a resolution for this! Can anyone help?

(31 Oct '13, 02:40) ws_user13

This sort of discussion is best held on the dev mailing list.

(31 Oct '13, 02:49) grahamb ♦

I can't understand how can this happen. The reassemble should end at the last fragment (so when your "more" variable is set to False). Even with the same ID it should not be overwritten by the next datagram fragment.

I maybe misunderstood something.

(31 Oct '13, 08:32) Afrim

a problem has occurred with decoding reassembled fragments lately.

what kind of problem? Can you provide a sample capture file?

(01 Nov '13, 05:30) Kurt Knochner ♦

Yes, the reassembly should end at the last fragment. The "more" variable is set to false...

But if the first fragment of the next datagram is located in the same frame and has got the same ID its entry overwrites the previous.

The entries in the reassembly table are just bound to the ID and the frame number. If there is more than one entry with the same ID and frame number, which happens very often in our daily work, the last entry wins and the others are lost.

It would be great if the entries in the reassembly table get an additional attribute so that nothing will be overwritten. I already sent a mail to the dev mailing list as grahamb suggested. As for the sample capture file I must apologize but I cannot post such a file due to security reasons.

(03 Nov '13, 23:57) ws_user13
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 22 Jul '13, 04:56

question was seen: 2,112 times

last updated: 03 Nov '13, 23:57

p​o​w​e​r​e​d by O​S​Q​A