Hi,
I’m not sure I get you, it currently works something like this on the first pass:
A packet is read from the file, the frame data structure is built and the file pointer is preserved
in fdata, a tvb is built with the packet data this tvb is passed to the first dissector,
The tvb may be manipulated(a new one created with different data or a sub tvb) this is then passed
to the next dissector which might decide that part of this tvb is a fragment
And call the fragment function which makes a copy of it and stores it in a hashtable. The packet
dissection ends, the tvb(s) are destroyed and the next packet is read.
If this packet completes the reassembly the fragments are merged and the fragments released, we now
have a copy of the completed segment in the completed fragments hashtable.
Subsequent passes:
We now display packet x, the packet is re-read from file using the file offset in frame data, pinfo->visited
is 1 so no reassembly is made. If this packet is a reassembled packet we will lookup
The data in the reassembled packets hashtable make a tvb from the stored buffer and display that
tvb, this tvb is destroyed once we are done with the packet.
Thanks, that explanation puts what you were trying to say into perspective. I was thinking that the reassembly "lived" just for the first pass and the reassembled data is extracted from the tvb for subsequent passes.
If it is reassembled fragments themselves, we want to store (not tvbuffs), isn't this more appropriate than storing that data in separate files and maintaining file pointers into those separate files?
Yes, as a first step one could experiment with attaching the reassembled buffer to per-frame-data which is in the fdata struct,
something like
-
On the first pass when defragmentation is complete instead of moving the packet to the “completed reassembly hash” store it in per frame data.
-
When the first pass is completed, release all reassembly hash tables etc.
-
On subsequent reads get the reassembled data from fdata.
-
If the file is re-read all data must be freed and the process repeated.
When the logic of doing this is in place it should be easier to proceed with the next step, I think.
Note:
-
I think per-frame-data does not handle multiple occurrences of the same protocol in the same frame currently, this may have to be fixed first.
-
The frame data struct should be kept as small as possible(one per frame makes a lot of data for large captures).
