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). _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
