Donald White said:
> It went so well that I mentioned it to my employer. They are now
> interested in converting two static dissertors that I developed about
> three years ago for Solaris and Linux to windows plugins so they can use
> some windows laptops for network monitoring in the lab. They are also
> I think interested in not having me periodically rebuild and distribute
> new ethereal versions. They like the idea of a binary windows
> distribution to which a couple of files are copied to the plugins
> directory.
Note that the plugin API and ABI are subject to change between Ethereal
releases.
> In looking at the code there were two problems. The first dissector
> uses the proto_registrar_get_name() function. This is because the
> meaning of some fields depends on the values of other fields. I used
> this function to get the field name and then use a value string array to
> display the alternate meaning. The code looks like this:
>
> proto_tree_add_uint_format(XX_opcode_tree, hf_XX_subtype, tvb, 9,
> 1,
> subtype, format,
> proto_registrar_get_name(hf_XX_subtype),
> val_to_str(subtype,
> XX_subtypes,
> unknown),
> subtype);
>
> The difficulty is that the semantics of subtype varies with the value of
> type.
...which presumably means that the code also uses some other variable with
the value of "type".
How is it used? What is the value of "format" in that case? Is it "%s:
%s", or something else?
If it's "%s: %s", then is "XX_subtypes" associated with the field that
uses "hf_XX_subtype"? If so, then "proto_tree_add_uint()" should be
sufficient. If not, then perhaps you should have different
"hf_XX_subtype" variables and fields, each associated with a different
"XX_subtypes" value_string table, and use "type" to select which
"hf_XX_subtype" variable to use.
> My second problem is that the second dissector calls the first. This is
> because the first protocol is sometime encapsulated in the second. How
> can this work if both are plugins?
It can work if you call through a dissector handle (as per Tomas Kukosa's
reply) - and that's how dissectors should be called even if they *aren't*
plugins, as calling through a handle automatically takes care of allowing
the second dissector to be disabled, setting "pinfo->current_proto" before
calling the subdissector and restoring it after the subdissector returns,
and may handle other stuff in the future.
