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.
Powered by MHonArc 2.6.10