Re: Filebacked-tvbuffs : GSoC'13

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

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.

Perhaps the completed segments hashtable should be holding filepointers to a file with the reassembled fragments rather 
than buffers again this is only viable if the performance is good enough
For large files.

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?

Regards
Anders


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

On Thu, May 2, 2013 at 5:17 PM, Anders Broman <anders.broman () ericsson com<mailto:anders.broman () ericsson com>> 
wrote:
> Just keep all the info in temporary files and clean up the files when free'ing the tvb's. In this case, can we use 
> the wiretap to deal with the temporary files as well?
The tvb:s only "live" in packet scope so what we need is file backed fragment (reassembled) storage (I think)

fragment_data scope is just the reassembly. The reassembled data is passed to sub dissectors as tvb, isn't it?
Also, "filebacked tvbuff" may not be the right name. What I had in mind was something like what Evans pointed out in 
the other thread:

  1.   A tvbuff which knows that it holds a list of frame_data/fragment_data and that the actual data is on the disk 
(TVBUFF_REASSEMBLY, maybe ??)
  2.  Reassembly would be building this tvbuff
  3.  When the reassembly is complete it gives back this tvbuff, to the dissector. Since the reassembly is complete, 
the tvbuff "has" all the packet data(though, its on the disk). This will be handed to the sub-dissectors.
If the data is backed in a temporary file, we'll have to maintain the offsets etc in the tvb layer, wouldn't we? That 
doesn't sound so good. Am I missing something here?
> In case of encrypted files, we can have a "large cache" so in the worst case we are back to where we are now with them.
It's not the file being encrypted it's the packet, think SSL, it's encrypted per-packet (right?) so each packet needs 
to be decrypted before the fragment can be stored, any protocol with similar behavior
Would have the same problem - data can't be directly accessed from the original file as it's manipulated before the 
fragment is stored.
My bad, I mean't encrypted packets. What I was thinking is that if the cache is large enough (as in as large as the 
packet iself), we wouldn't have to go to the original file again. All the decrypted packet would be there in the cache. 
Anyways, sounds too much like a hack.

Thanks alot for your patience,
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