Wireshark-dev: Re: [Wireshark-dev] Is there a good way of handling "per pdu" info ?
From: "Didier" <[email protected]>
Date: Tue, 13 Nov 2007 22:44:03 +0100
On Tue, 13 Nov 2007 09:07:19 -0700, Bryant Eastham wrote
> Richard van der Hoff wrote:
> >Stephen Fisher wrote:
> >> On Mon, Nov 12, 2007 at 06:05:38PM -0000, Neil Piercy wrote:
> >> 
> >> 
> >>>I know there is per-packet info, but is there a way of
> >>>adding/retrieving per PDU info which copes with multiple PDUs in a
> >>>packet ? How does a dissector even know if it is handfling the first,
> >>>second etc PDU in a packet ?
> >> 
> >> 
> >> This has been requested before, but has not been implemented to date
> in
> >> Wireshark.  A workaround you can use is to use a linked list from
> GLib
> >> (which has a nice easy interface to them) and store that in the per
> >> packet info.  Each item in your list would correspond to a different
> >> PDU.
> >
> >But, as Neil asked, how would you know which PDU you were
> >handling in the dissector?
> >
> >> One of us should get around to implementing per-pdu packet info in
> >> Wireshark itself.  It wouldn't be too difficult.  All we need is
> spare
> >> time :)
> >
> >Hrm; it gets quite a lot harder when your PDUs can
> >themselves span 
> >multiple packets (ie, there is no correspondence between PDUs and 
> >packets). See H.223 for details...
> I do not consider myself an expert by any means, but here is what I
> ended up doing.
> The easy part is the data structures; however I stayed away from lists.
> Wireshark does a great job of giving you the right structures for the
> task (check se_tree_create_non_persistent and se_tree_lookup32). My
> particular PDU state involves encryption state. I create appropriate
> conversations and put my PDU structures in them.

> In the TCP case I use a combination of the sequence and the offset. The
> offset is TVB_RAW_OFFSET(tvb). Assuming that you call this on the tvb
> that represents your PDU you should always get the same number - however
> it is not unique to the session, only the tvb. To make it unique I 
> add the seq field of the tcpinfo structure. The structure pointer is 
> present in the pinfo->private_data for tcp dissectors, so I stash 
> By the way, if experts find holes in my approach I would love to know!
Not an expert either but if you use the same table for both directions you may
have duplicate if TCP relative sequence number is set.
cf bug: