Re: Inconsistent availability of proto_tree values during the first of two passes

[Paul Offord <Paul.Offord () advance7 com>]

> 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.

Yes, that's the case for TRANSUM.  TRANSUM analyses the packets that make up Request and Response APDU pairs and 
computes values.  These computed values are added to the protocol tree of the first packet of the Request APDU during 
the second and subsequent scan. 

> 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.

Agreed, except in the case of TRANSUM the user will probably want to add a TRANSUM-computed value as a column.  For 
example, if you use tshark to just output the Packet List entries (summary lines) it's likely that TRANSUM-computed 
values would be included in that listing.

> 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).

Agreed.

-----Original Message-----
From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Guy Harris
Sent: 10 April 2017 18:39
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Subject: Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 10, 2017, at 12:30 AM, Paul Offord <Paul.Offord () advance7 com> 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 <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

______________________________________________________________________

This message contains confidential information and is intended only for the individual named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if 
you have received this e-mail by mistake and delete this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not necessarily represent those of Advance Seven 
Ltd. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept 
liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex 
CM24 1SJ

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe