I'd like to resurrect this. Here's a quick summary:
As making the code consistent has been rejected and the tap idea won’t work, where do we go from here? Thanks and regards…Paul -----Original Message----- Guy Harris has posted comments on this change. Change subject: tshark: Always have the same conditions to determine if tree should be created ...................................................................... Patch Set 2: Code-Review-2 OK, the problem here is that the TRANSUM "dissector" is doing both tap-like things (reading the protocol tree and processing data) and post-dissector-like things (adding stuff to the protocol tree based on the results of that processing). Given that taps are run *after* post-dissectors, this means that it has to "cheat" and do the tap-like things in the post-dissector, but post-dissectors are, like other dissectors, handed a protocol tree only if there's a need to generate
one. For this, we need a way to do the "read the protocol tree and process it" stuff *before* the post-dissector is run, i.e. a way to register taps to be run *before* the post-dissectors. (In the longer term, we probably need to re-think both taps and post-dissectors in a number of ways, and make whatever changes are necessary to get done what the taps and post-dissectors are currently doing in ways that don't involve
abusing those mechanisms to get things done. I'm a little suspicious, for example, of the Parallel Redundancy Protocol trailer post-dissector - it's a protocol that's actually processing part of the packet data; see the "This is horribly broken" comment I added to it a while ago. 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.) -- To view, visit
https://code.wireshark.org/review/20078 To unsubscribe, visit
https://code.wireshark.org/review/settings Gerrit-MessageType: comment Gerrit-Change-Id: I69bb395b55b73f26665d90f341c92a978e50aa70 Gerrit-PatchSet: 2 Gerrit-Project: wireshark Gerrit-Branch: master Gerrit-Owner: Michael Mann <mmann78@xxxxxxxxxxxx> Gerrit-Reviewer: Guy Harris <guy@xxxxxxxxxxxx> Gerrit-Reviewer: Michael Mann <mmann78@xxxxxxxxxxxx> Gerrit-Reviewer: Paul Offord <paul.offord@xxxxxxxxxxxx> Gerrit-Reviewer: Petri Dish Buildbot <buildbot-no-reply@xxxxxxxxxxxxx> Gerrit-HasComments: No ______________________________________________________________________ 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 ______________________________________________________________________ |
- Follow-Ups:
- Prev by Date: Re: [Wireshark-dev] buildbot down?
- Next by Date: Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
- Previous by thread: Re: [Wireshark-dev] buildbot down?
- Next by thread: Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes
- Index(es):