On Apr 3, 2007, at 4:53 PM, Bob Doolittle wrote:
Thanks. My subdissector is now being called, and is updating the List
window
properly. But for some odd reason the sub-protocol isn't appearing
in the
Details window tree, and I'm handling it identically to how I handled
the parent
protocol, which is drawing properly. I've verified that the proto
has been
registered properly. I've verified that the same tree is being
passed into the subdissector, and that it's making the
proto_tree_add_item call
for the proto in the parent tree, but it's not appearing.
So the "tree" argument to the subdissector is non-null?
What's the code in the subdissector that adds the top-level entry for
the protocol?
Is there something special that has to occur for a single plugin to
add two
separate protos to the tree?
A single plugin can contain multiple dissectors; they can be in a
single source file, or multiple source files.
The only thing that's necessary for a single source file to contain
multiple dissectors is to make sure that the registration and handoff-
registration routines in that source file (there can be more than one
such routine) register all the dissectors properly.
Are there any good examples of dissectors in the wireshark source
that add
multiple protocol layers to the tree? Is this bad practice - should
I be
using multiple plugins for multiple layers, and if so, how do I
force them
to be initialized in the necessary order (e.g. so that the parent
proto can
create the dissector table before the child proto adds itself :)?
You should be using multiple *dissectors* for multiple protocol
layers, but it sounds as if you're already doing that.
The problem probably has nothing to do with multiple dissectors in a
plugin. That works (see, for example, the DOCSIS plugin).
