Wireshark · Ethereal-dev: Re: [Ethereal-dev] [Patch] revised: tap-tcp_close

[Jason House <jhouse@xxxxxxxxx>]

Guy Harris wrote:
> What's a "search"?

I was commenting from memory... looking back at the code, I was thinking
of read_tree, but that is something very specific to processing display
filters...  After looking more carefully, at existing taps, the way to
"search" would be to call proto_get_finfo_ptr_array... Which is very
benign, but requires prep by either placing a field in the filter
string.  (If the tap is only interested in a field it must create
filters such as "fieldX || !fieldX".  A tap can't call
proto_tree_prime_hfid directly since priming occurs before the listener
is called) 

> Passing the epan_dissect_t might not be useful except for tap listeners
> not tapping off of a dissector, as the protocol tree wouldn't be
> complete; those listeners might be called after the entire dissection is
> complete.

  After looking at the code in greater detail, I think that
epan_dissect_t can still be useful for a tap listener based off an
arbitrary protocol dissector.  Even during mid-dissection,
proto_get_finfo_ptr_array will return a list of all the fields of the
desired type that were encountered during dissection so far.  As long as
the tap listener can somehow prime the edt->tree, it can have quick
access to fields that it is interested in.  The approach used previously
(tap-protocolinfo) was to make the fields part of a filter expression.
  Tap listeners would still need to exercise some caution because
multiple calls to a given protocol dissector could have already occurred
in the dissection of the packet.  ie. a search for tcp.urgent_pointer
could return multiple urgent pointers, but only the most recently added
one would be useful.
  A less recoverable problem would be items that aren't always added to
the tree every time the protocol is dissected.
  Of course, if the tree was walked manually, starting from the last
subtree for the protocol in question would eliminate issues of previous
dissect_XXX calls causing confusion.