>-----Original Message-----
>From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jaap Keuter
>Sent: den 24 januari 2013 08:27
>To: Developer support list for Wireshark
>Subject: Re: [Wireshark-dev] Save meta data to pcap-ng file during first pass dissection in Wireshark?
>
>Hi,
>
>Interesting note. There's a basic architectural problem though, which hinders us now and also with this option. >It's that reassembly can take place at multiple protocol layers, and these boundaries not always line up (think >TCP).
>There is no sure fire way to define 'the reassembled packets' since it depends on the protocol layer you are
>looking at.
I'm not sure this would be a major show stopper I imagine the "reasembled_data_option" content to be as the reassembled buffer currently used.
>Besides that, storing and reading from a file, is slower than memory access, so that won't help. It would help >the memory footprint (after the first pass).
Yes this is a concern but we do read the packet back from file on the second pass any way, we might save
Memory on the first pass to as we only need to keep the fragments arount untill we can write them to file.
Opening a reassembled file and using it might be faster as reassembly is done.
Another worry when thinking about it some more is file formats other than pcap/ng, not sure if they will cause problems.
Regards
Anders
On 01/23/2013 09:53 AM, Anders Broman wrote:
> Hi,
> Would it be feasible to have wireshark write packets out to a new file
> as they are analyzed during the first pass and read packets in from
> that File for the rest of the session. By doing that reassembled
> packets could be stored in the pcap-ng packet block as a new option
> instead of In memory and read back in together with the frame and
> stored (pointed to) in the fdata structure. Other metadata could
> probably be stored too in order to Speed up filtering. The new file
> should have some marking that the first pass analysis is done and some
> stuff can be skiped if this file is read back in or Reanalysed if the user so decides as all the original data should be retained.
> I'm sure there a pitfals in this kind of strategy but are there any
> major Reasons why this cant/shouldn't be done? Comments? Ideas?
>
> Best regards
> Anders
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe