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?