Wireshark mailing list archives
Re: Inconsistent availability of proto_tree values during the first of two passes
From: Paul Offord <Paul.Offord () advance7 com>
Date: Tue, 11 Apr 2017 06:57:58 +0000
OK - So just to summarize, we need to: 1. Short Term - Add a flag somewhere that can be set by a dissector, post-dissector or tap to request that a proto_tree is produced on the first pass 2. Long Term - Add a facility that allows a dissector, post-dissector or tap to request a list of specific protocol field values values during the first pass Is that right? -----Original Message----- From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Guy Harris Sent: 11 April 2017 04:25 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 3:04 PM, Paul Offord <Paul.Offord () advance7 com<mailto:Paul.Offord () advance7 com>> wrote:
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.
That's not a TRANSUM-specific issue. If the user wants to use *any* custom columns, from *any* dissector or post-dissector field, the protocol tree currently has to be generated - and, given that custom columns work, we *already* arrange to construct the protocol tree whenever we're asking for columns and at least one column is a custom column (see various calls to have_custom_cols()), so if the code calling the dissectors is only trying to get the column contents *but* at least one column is a custom column, the tree will be constructed. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org<mailto: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
Current thread:
- Re: Inconsistent availability of proto_tree values during the first of two passes, (continued)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 09)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 09)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 09)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 09)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 09)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 09)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 10)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 10)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 10)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 10)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 10)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 11)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 11)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 11)
- Re: Inconsistent availability of proto_tree values during the first of two passes Guy Harris (Apr 12)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 12)
- Re: Inconsistent availability of proto_tree values during the first of two passes Paul Offord (Apr 09)