wireshark-dev October 2010 archive
Main Archive Page > Month Archives  > wireshark-dev archives
wireshark-dev: Re: [Wireshark-dev] composite tvbuffs

Re: [Wireshark-dev] composite tvbuffs

From: John Sullivan <jsethdev_at_nospam>
Date: Tue Oct 12 2010 - 18:55:23 GMT
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>

On Tuesday, October 12, 2010, 3:27:09 PM, Jeff Morriss wrote:
> I think composite tvbuffs probably do work, but their use is hindered by
> the fact that each tvb that you get (each time a frame is handed to your
> dissector) is freed/reused after the packet is dissected. That is,
> Wireshark does _not_ keep the entire capture file in memory. Because of
> that, there's relatively little need/use for the composite functions and
> it's why you need to allocate copies of whatever data you want to
> reassemble.

This. I was digging into the RTMPT dissector again over the weekend,
hoping I could move from allocating memory for every reassembled pdu
to just creating composite tvbs overlaying the original packets. This
would have been a big win memory-wise, since the reassembled packets
have to live for the entire capture session (multiple non-contiguous
chunks based on multiple prior TCP segments), but turns out not to be
possible for the above reason.

So it looks like it's necessary to either tvb_memdup from the original
data, then add a tvb_new_real_data to a composite and use that, or
se_alloc the entire buffer up front, tvb_memcpy into it and use a
tvb_new_real_data from that which has a lower overhead in terms of
tvbuff structures.

(I have a concern that neither of those will free up the used memory.
tvb_memdup uses g_malloc and there is no notification of when this is
safe to free so AFAICS it is leaked. The se_alloced blocks will of
course be freed once the capture is closed, but what of the extra tvb
structures on top of them? I presume they are permanent rather than
seasonal so ought to be tvb_freed at some point, but again I can't see
any notification of when that should happen, so it doesn't.)

-- ___________________________________________________________________________ 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