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 proto_tree values during the first of two passes On Apr 11, 2017, at 10:43 PM, Paul Offordwrote: > 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. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 11, 2017, at 10:43 PM, Paul Offordwrote: > 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. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
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 On Apr 11, 2017, at 12:13 AM, Guy Harriswrote: > 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 >> • 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? > > Something such as that; the short-term solution is exactly that, the > long-term solution might involve providing the values of those protocol > fields on *every* pass or on the first pass. (It may also involve the way to > deliver them, given that a given protocol might appear more than once in the > protocol stack, given various forms of tunneling/encapsulation.) OK, I've checked in a change that allows a postdissector to specify an array (GArray) of hfids for fields that it's going to be extracting from the protocol tree. With that change, when the packets are being read in for the first time, *or* redissected after, for example, a preference change, the protocol tree will be built if any postdissector has specified any such fields (as well as in all the other cases where it currently happens to be built). I've modified MATE and TRANSUM to use that API if they're enabled. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 11, 2017, at 12:13 AM, Guy Harriswrote: > 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 >> • 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? > > Something such as that; the short-term solution is exactly that, the > long-term solution might involve providing the values of those protocol > fields on *every* pass or on the first pass. (It may also involve the way to > deliver them, given that a given protocol might appear more than once in the > protocol stack, given various forms of tunneling/encapsulation.) OK, I've checked in a change that allows a postdissector to specify an array (GArray) of hfids for fields that it's going to be extracting from the protocol tree. With that change, when the packets are being read in for the first time, *or* redissected after, for example, a preference change, the protocol tree will be built if any postdissector has specified any such fields (as well as in all the other cases where it currently happens to be built). I've modified MATE and TRANSUM to use that API if they're enabled. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 10, 2017, at 11:57 PM, Paul Offordwrote: > 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 > • 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? Something such as that; the short-term solution is exactly that, the long-term solution might involve providing the values of those protocol fields on *every* pass or on the first pass. (It may also involve the way to deliver them, given that a given protocol might appear more than once in the protocol stack, given various forms of tunneling/encapsulation.) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
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 specific protocol field values values during the first pass Is that right? -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris Sent: 11 April 2017 04:25 To: Developer support list for WiresharkSubject: 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 >> 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 > Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 10, 2017, at 3:04 PM, Paul Offordwrote: >> 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
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 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-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris Sent: 10 April 2017 18:39 To: Developer support list for WiresharkSubject: 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 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_xx > 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 10, 2017, at 12:30 AM, Paul Offordwrote: >> 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_xx > 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
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 code that works > only in Wireshark but not in TShark. OK but just to be clear, I'm not trying to write a Wireshark-only post-dissector. This is a port of transum.lua which supports Wireshark and tshark. > 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_xx 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. -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris Sent: 10 April 2017 06:43 To: Developer support list for WiresharkSubject: 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 least on the first pass through the packets, it requires a protocol tree would be better, as it wouldn't encourage people to write code that works only in Wireshark but not in TShark. (The only such code should be taps with a GUI. Even the taps that produce tables of information shouldn't be program-dependent - there should be a layer that shows the table in text form in TShark and as a table window in Wireshark.) 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)? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 9, 2017, at 10:37 PM, Paul Offordwrote: > 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 least on the first pass through the packets, it requires a protocol tree would be better, as it wouldn't encourage people to write code that works only in Wireshark but not in TShark. (The only such code should be taps with a GUI. Even the taps that produce tables of information shouldn't be program-dependent - there should be a layer that shows the table in text form in TShark and as a table window in Wireshark.) 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)? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
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 during the first of two passes On Apr 9, 2017, at 2:08 PM, Paul Offordwrote: > When running tshark. And what mechanism do you propose to use to determine whether it's running in Wireshark or TShark? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 9, 2017, at 2:08 PM, Paul Offordwrote: > When running tshark. And what mechanism do you propose to use to determine whether it's running in Wireshark or TShark? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
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 WiresharkSubject: 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? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 9, 2017, at 1:07 PM, Paul Offordwrote: > 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? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
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 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris Sent: 09 April 2017 21:01 To: Developer support list for WiresharkSubject: 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 particular protocol dissectors - that might be what TRANSUM, > and possibly MATE, *really* want to be.) and as somebody said in https://www.wireshark.org/lists/wireshark-dev/201702/msg00082.html > Alternatively, we could have a set of flags used when post-dissectors are > registered, including "this post-dissector needs a protocol tree", and, if > there are any active post-dissectors that require a protocol tree, one will > be generated. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
On Apr 9, 2017, at 12:48 PM, Paul Offordwrote: > 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 particular protocol dissectors - that might be what TRANSUM, > and possibly MATE, *really* want to be.) and as somebody said in https://www.wireshark.org/lists/wireshark-dev/201702/msg00082.html > Alternatively, we could have a set of flags used when post-dissectors are > registered, including "this post-dissector needs a protocol tree", and, if > there are any active post-dissectors that require a protocol tree, one will > be generated. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe