On Apr 10, 2017, at 12:30 AM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:
>> So would you need the full protocol tree *every* time the packet is dissected, or just the *first* time (meaning you'd save the results of the first-pass processing and not require it later)?
>
> TRANSUM only needs the values in the first pass, but during the second pass it adds a section to the end of the visible tree using proto_tree_add_xxxxxx function and I assume that means it needs the full tree at that point. I imagine other dissectors and post-dissectors would also need the full tree on the second pass.
There's "the first pass", which is guaranteed to occur, and then there's "everything else", which is not guaranteed to include a second sequential pass through all the packets; if it does, that's an implementation detail. Building up state from a chronological scan of the packets is what you have to do in the first pass, with any information you can't recompute from the contents of a single packet saved for use when re-dissecting a packet.
If a tree isn't being generated, because it isn't necessary (e.g., if the code calling the dissectors is only trying to get the column contents) there's presumably no need for TRANSUM - or any other dissector or post-dissector - to add anything to the non-existent tree.
So this is a case where a "generate the tree on the first pass" indication is what's needed (and that would probably not be needed for post-dissectors that only need *particular* field values if there were a way for a post-dissector to get the values of those fields without generating a protocol tree, but that's the "needs more work" improvement I've mentioned elsewhere).
