On Apr 10, 2017, at 12:30 AM, Paul Offord <[email protected]> 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). ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
