Wireshark-dev: Re: [Wireshark-dev] [Help_Wireshark] difference between fragmentation reassembly

From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
Date: Tue, 4 Jul 2017 17:07:24 +0200
[adding wireshark-dev mailing list which should have been your destination address rather than my personal email]

Hi hhw hhw,


2017-07-04 16:36 GMT+02:00 hhw hhw <hhw.hhw7@xxxxxxxxx>:
Hi. i have a custom dissector is layered on top of UDP that splits up its own data stream.flag bytes that signals the presence of a multi-packet sequence and also the last packet, followed by an ID of the sequence and a packet sequence number.
can you help me in this question ?  

based on your packet capture, the reassembly API is behaving as expected.

packet nb  sequence id    sequence number  more flag  info
1          16             0                1          (Message Reassembled)
2          16             1                1          (Message Reassembled)
3          16             2                0          (Message Reassembled)
4          5              11               1          (Message fragment 11)
5          5              12               1          (Message fragment 12)
6          5              13               0          (Message fragment 13)


The first 3 packets have the same sequence identifier, they start from sequence number 0 without any missing fragment and the last fragment (SN=2) is identified by the more flag bit being 0 -> they get reassembled.
The last 3 packets are not reassembled because SN 0 to 10 are missing.

If you expect reassembly to be performed for packets 4 to 6, you must ensure that call the reassembly API with frag_number equal to 0 for packet 4, 1 for packet 5 and 2 for packet 6.

If you are really sure that no packet loss / reordering could happen (but it is hardly believable given that you operate on top of UDP), you could also try using fragment_add_seq() with REASSEMBLE_FLAGS_NO_FRAG_NUMBER flag:

        frag_msg = fragment_add_seq(&msg_reassembly_table,
            tvb, offset, pinfo,
            sequenceid, NULL, /* ID for fragments belonging together */
            sequenceno, /* fragment sequence number */
            tvb_captured_length_remaining(tvb, offset), /* fragment length - to the end */
            morefrag, /* More fragments? */
            REASSEMBLE_FLAGS_NO_FRAG_NUMBER);

But better avoid using this REASSEMBLE_FLAGS_NO_FRAG_NUMBER flag and instead put whatever code is required to know what is the beginning of a new fragmented message while you run on UDP that does not guarantee in order and lossless delivery.

Hope this help,
Pascal.