On Nov 13, 2011, at 9:41 AM, mmann78@xxxxxxxxxxxx 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.