ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Is there a good way of handling "per pdu" info ?

From: "Neil Piercy" <Neil.Piercy@xxxxxxxxxxxx>
Date: Tue, 13 Nov 2007 16:00:53 -0000
> -----Original Message-----
> >>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?

That is the issue I'm facing!

> > 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 think what is actually needed is the concept of a PDU handle on an
arbirtary point in the parsing - e.g. the concatenation of the frame
number and the byte offset in that frame would be a suitable handle for
a PDU which started at a "real" point in a frame, but this still would
not work for constructed TVBs (e.g. a TVB carrying the decrypt from
SSL). For that you would need have the PDU handle be based on the
hierarchy of TVBs in some way. This is all sounding challenging to me,
but could it be made to work for the normal case of a TVB being at an
offset into a frame, and e.g. tvb_get_handle(tvb,offset) to return a PDU
handle ?

If you could do that then the per-packet info is good enough as you say
with the list of entries.

Neil