Wireshark · Wireshark-dev: Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13

[Anders Broman <anders.broman@xxxxxxxxxxxx>]

 

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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.broman@xxxxxxxxxxxx> 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