Guy Harris wrote:
Note that the plugin API and ABI are subject to change between Ethereal
releases.
Yes, having now added the proto_registrar_* functions to the API, I
realize that this is true. This means I really need to work within the
API of a current binary release. It is this rebuilding of the ethereal
executable that we wish to avoid.
...which presumably means that the code also uses some other variable with
the value of "type".
Yes, that is right. There is an unambiguous type field that can be
interpreted with a header_field_info variable and proto_tree_add_item().
This determines the meaning of the subtypes. This condition is
several layers deep, there are also sub-subtypes and so on. The tree is
also wide with a span of from 4 to 12. While the message header has
only 12 bytes in it. The result are hundreds of subtypes. I tried to
register just one header_field_info variable for each physical field in
the message header. Our testers probably have a a large number of
filters assuming these names by now.
How is it used? What is the value of "format" in that case? Is it "%s:
%s", or something else?
The format string is as you describe. We want the subtype fields to all
have the same abbreviation but with a changing value string depending on
the type. The most common subtype is defined in a header_field_info
variable and displayed with proto_tree_add_item(). The name field from
that variable and an alternate value_string variable are used for the
"overloaded" values and interrpretted with proto_tree_add_uint_format().
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.
I remember trying to define multiple header_field_info variables for
each subtype, but I used the same abbreviation in each and ran in to
trouble. I think now that I should consider a hidden field to provide a
common abbreviation for filters.
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.
This is an excellent suggestion which I have implemented. I remember
now handles making their appearance last summer, when we migrated from
8.?? to 9.12 and our registration functions broke. I quickly fixed this
without thinking of the broader implications. Thanks to you and Tomas,
they are clearer to me now. This also indicates how we work. We ignore
ethereal development until we are forced to enhance our dissectors, then
we decide that we may as well update to the current ethereal as well and
do it as quickly and mechanically as we can.
Thanks,
Don
