On Feb 12, 2017, at 11:40 PM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:
> I'll accept whatever strategy there is for taps vs. dissectors. A few points:
>
> * TRANSUM can only work if it is able to calculate values based on other dissected values (such as smb2.msg_id), so provided the dissected values are available to the tap on both passes (via a protocol tree or otherwise) that would be OK
If the tap is registered with TL_REQUIRES_PROTO_TREE, the protocol tree will be provided to it on all passes. If it's one of these new "early" taps, the protocol tree will have the results of all dissectors except for post-dissectors.
> * I've never written a tap before but I think if the tap runs after all other dissectors this wouldn't be a problem for TRANSUM
It has to run before the post-dissectors that add things to trees...
...unless we allow taps that are handed a protocol tree to add fields to the protocol tree, in which case the post-dissector would be unnecessary and the new type of "early" taps would also be unnecessary.
> * When a dissector registers a tap, Wireshark passes a protocol tree to a dissector based on the criteria Michael defined, so some thought would be needed regarding this for consistency (unless Tshark shouldn't work like Wireshark)
The only form of consistency that we will ever provide, with regard to providing a protocol tree to modules, is "a tap that requests a protocol tree will always be handed a protocol tree".
The criteria for deciding whether to provide a protocol tree to dissectors are internal to particular releases of particular protocols, are not part of any Wireshark APIs, and are subject to change without notice. "Consistency", whether between Wireshark and TShark, between "Wireshark running with color filters" and "Wireshark running with no color filters", between releases of Wireshark/TShark, etc., doesn't apply to that.