Re: Inconsistent availability of proto_tree values during the first of two passes

[Guy Harris <guy () alum mit edu>]

On Apr 11, 2017, at 12:13 AM, Guy Harris <guy () alum mit edu> wrote:

> On Apr 10, 2017, at 11:57 PM, Paul Offord <Paul.Offord () advance7 com> wrote:
>
> > OK - So just to summarize, we need to:
> >
> >      • Short Term - Add a flag somewhere that can be set by a dissector, post-dissector or tap to request that a 
> > proto_tree is produced on the first pass
> >      • Long Term – Add a facility that allows a dissector, post-dissector or tap to request a list of specific 
> > protocol field values values during the first pass
> >
> > Is that right?
>
> Something such as that; the short-term solution is exactly that, the long-term solution might involve providing the 
> values of those protocol fields on *every* pass or on the first pass.  (It may also involve the way to deliver them, 
> given that a given protocol might appear more than once in the protocol stack, given various forms of 
> tunneling/encapsulation.)

OK, I've checked in a change that allows a postdissector to specify an array (GArray) of hfids for fields that it's 
going to be extracting from the protocol tree.  With that change, when the packets are being read in for the first 
time, *or* redissected after, for example, a preference change, the protocol tree will be built if any postdissector 
has specified any such fields (as well as in all the other cases where it currently happens to be built).

I've modified MATE and TRANSUM to use that API if they're enabled.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe