Wireshark-dev: Re: [Wireshark-dev] Fragmentation
From: Rick Bywater <[email protected]>
Date: Wed, 4 May 2011 16:31:22 -0400

It sounds like you might have some inside information that I could use.

I am developing a dissector which decodes a protocol running on top of UDP.  It uses the fragment_add_seq_next to string together all of the packets.  It is quite complicated as I often see multiple packets of my protocol strung together over several UDP packets and often the initial packet does not contain enough of the header to include the length of my protocol's packet.  Nonetheless, I believe that the reassembly is now working as desired.  However, the call to the dissector which completes the reassembly always has a NULL tree.  So, I never have a tree to place the dissection.

With your final comment about making sure to execute the reassembly prior to the tree check, I thought you might know why my dissector would be called without a tree?  Any guidance would be greatly appreciated.

Rick Bywater

: David Aggeler <[email protected]>
>Date: Tue, 22 Feb 2011 21:15:36 +0100
> Subhasree,
>Welcome to the club. Even though my opinion is not shared widely, there's no good TCP reassembly API in place to handle unknown length reassembly at TCP level reliably. If >yo know the length, tcp_
>It sounds like you need to use 'fragment_add_seq_next()' to add the items to a list and then use 'process_reassembled_data()' to copy the data parts into a new tvb structure and >pass it on to the dissector. They are not designed for TCP, but for all protocols, hence they do not obey TCP sessions and TCP sequence numbers.
>Even though I do not consider my using in packet-dcm.c a reference, you still may want to look at dissect_dcm_pdv_fragmented() to have a look how I used it for TCP >reassembly. There are other dissectors as well that us this at TCP level.
>The trick is to get offset right, i.e. matching your protocol. I had to debug the fragment_add_seq_next() to understand it.
>Doing this is prone to out of sequence packets and there's no guarantee, that the dissector is called in order of the packets coming in. So that's what I currently live with.
>And make sure you do this before filtering by 'if (tree) ..'