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@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
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@xxxxxxxxxxxx> 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:
-
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 ??)
-
Reassembly would be building this tvbuff
-
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,
