Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

That sounds great. I'll have a play with it over the holiday weekend. Sent from Samsung Mobile on O2 Original message From: Guy Harris Date:13/04/2017 1:18 AM (GMT+00:00) To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Inconsistent availability of

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 11, 2017, at 10:43 PM, Paul Offord wrote: > Nice. I'll take a look. I've checked in some additional changes; with those changes, at least with one SMB file I have, if I enable TRANSUM, Wireshark, and TShark when run in 2-pass mode, produce the same output.

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

Nice. I'll take a look. Sent from Samsung Mobile on O2 Original message From: Guy Harris Date:12/04/2017 5:35 AM (GMT+00:00) To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 11, 2017, at 12:13 AM, Guy Harris wrote: > On Apr 10, 2017, at 11:57 PM, Paul Offord wrote: > >> OK - So just to summarize, we need to: >> >> • Short Term - Add a flag somewhere that can be set by a dissector, >> post-dissector or tap

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 10, 2017, at 11:57 PM, Paul Offord wrote: > OK - So just to summarize, we need to: > > • 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 > •

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

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

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

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

> 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

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

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

> Given that there are no such APIs, one would have to be added and, if we're > going to be adding APIs, an API by which a post-dissector can specify that, > at least on the first pass through the packets, it requires a protocol tree > would be better, as it wouldn't encourage people to write

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 9, 2017, at 10:37 PM, Paul Offord wrote: > Ah that was going to be my next question :-) > > Any ideas? Given that there are no such APIs, one would have to be added and, if we're going to be adding APIs, an API by which a post-dissector can specify that, at

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

Ah that was going to be my next question :-) Any ideas? Sent from Samsung Mobile on O2 Original message From: Guy Harris Date:10/04/2017 1:06 AM (GMT+00:00) To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Inconsistent availability of proto_tree values

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 9, 2017, at 2:08 PM, Paul Offord wrote: > When running tshark. And what mechanism do you propose to use to determine whether it's running in Wireshark or TShark? ___ Sent via:

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

When running tshark. -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris Sent: 09 April 2017 21:32 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev]

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 9, 2017, at 1:07 PM, Paul Offord wrote: > So if I add code to TRANSUM so that it only registers itself when running > with Wireshark, "when running with Wireshark" as opposed to what? ___

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

So if I add code to TRANSUM so that it only registers itself when running with Wireshark, would that be acceptable as a fix pending the redesign and recoding as you have described below? -Original Message- From: wireshark-dev-boun...@wireshark.org

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

On Apr 9, 2017, at 12:48 PM, Paul Offord wrote: > As making the code consistent has been rejected and the tap idea won’t work, > where do we go from here? As somebody said: > We might also want a way to have taps/"post-"dissectors that act as > extensions to