Re: "tree check" vs "visit"ed

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

On Nov 13, 2011, at 9:41 AM, mmann78 () netscape net wrote:

> I'm working with a dissector that implements "request/response tracking" modeled after 
> README.request_response_tracking.  The one problem I noticed with the dissector is that it checks the "if visited 
> flag" (pinfo->fd->flags.visited) per the example, but it also checks to see if the "protocol tree" is NULL.  What 
> happens is in the "first pass", tree = NULL, so the dissector doesn't do much (because there's no protocol tree).  In 
> the "second pass", tree != NULL, but the packet has since been "visited", the request/response handling doesn't get 
> called.

For "pass" in the sense of "sequential pass over all packets", there is no guarantee that there's more than one "pass", 
that pass being the one where the file is read in.  However, packets can, after they've been dissected in the first 
pass, be subsequently visited in any order (no guarantee that it's sequential).

There is also no guarantee that tree will, or will not, be null on the first pass; dissectors should make no 
assumptions about that.

All work to construct state needed for request/response tracking, etc. must be done in the first pass, regardless of 
whether tree is null or not (see the note two paragraphs ago about visits to packets after they've been dissected in 
the first pass, in particular "no guarantee that it's sequential").  (The code in README.request_response_tracking does 
*not* check whether a protocol tree is being built or not, so the problem is that the dissector isn't closely enough 
modeled after that code.)

> I thought I had read on this mailing list that the "tree checks" have been added to the necessary "internal APIs", so 
> they aren't needed in a dissector.  Is that true?

The checks aren't needed for correctness.  They can still be done to avoid doing dissection work that *only* adds 
information to the protocol tree, rather than building state.
___________________________________________________________________________
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