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:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1392
Didier