From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@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.bro...@ericsson.com<mailto:anders.bro...@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-requ...@wireshark.org?subject=unsubscribe
