From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Ambarisha B Sent: den 2 maj 2013 11:26 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13
>On Wed, May 1, 2013 at 9:46 PM, Anders Broman ><a.bro...@bredband.net<mailto:a.bro...@bredband.net>> wrote: >It may be problematic to obtain the fragments from the original file in case >it is gziped or if the fragments are >parts of decrypted packets so writing to a new file might be the best option. > >Agreed. Jeff suggested that we've decently fast random access to gzipped >files. So, the way I see it, we've two ways of dealing with encrypted >files(and bzip'ed files): > > 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) >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. >If encrypted packets are not so common, 2 would be ok. But I think 1 is the >right way to do it. What do you guys think? Or are there more ways of dealing >with this? Preferably we need one unified way of treating all packet reassembly. Cheers, 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