Re: Filebacked-tvbuffs : GSoC'13

[Anders Broman <anders.broman () ericsson com>]

From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Ambarisha B
Sent: den 3 maj 2013 11:38
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13

On Thu, May 2, 2013 at 9:55 PM, Anders Broman <anders.broman () ericsson com<mailto:anders.broman () ericsson com>> 
wrote:
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.

Alternatively if the file is rewritten on the first pass writing the reassembled data together with the packet holding 
the last fragment the reassembled data could be read together with the packet
But that might have other problems and might require changes to the file format description (pcap-ng) some sort of 
prototyping to test the idea maybe?

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).

Thanks and regards,
Ambarish

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe