Hi,
Up to a week ago, my ASN.1 dissector presented all its info in the
form of text [it only used 'proto_tree_add_text' to build the field
display].
Now I have started to change these to various forms of
'proto_tree_add_XXX_format'
I have encountered 2 problems that need to be discussed before I do
something about it....
One problem is with the fact that 'proto_tree_add_string_format' has
only 1 length parameter. In the world of ASN.1 [or any TLV message],
there are 2 lengths involved, one to indicate the length on the pdu
that is to be marked in the hex display and one to indicate the length
of the value that is to be used in the matching process [currently the
ethereal infrastructure does not know about TLV, only about values
handed to it by the dissector routines].
I already can see two solutins.
- Add a new set of functions, 'proto_tree_add_string_format2' etc,
that have an extra length parameter.
- Use the fact that the length will always be smaller than 65k, and
use the upper 16 bit of the current lenght parameter for this new
length parameter. [if that is 0, than it will use the same lenght
for both].
The other problem is more involved, it may touch ground rules of ethereal
design. My ASN.1 dissector has the possibility to read a new type table
using the preferences dialogue. At that point in time, field names are
derived from the spec at hand and registered using
'proto_register_field_array',
one at a time, however, in malloced memmory that is not freed.
This works OK, they become visible in the "Display Filter:Add Expression"
dialogue. However, the parser rejects the expression because nether of
the operands is a field..... Tracking this down, I have found 'proto-init()'
in epan/proto.c which assumes all registration is finished after
'register_all_plugin_handoffs()' is called.... and then builds a tree
of all field names.
But with my dissector this registraton happens when the user preferences
are read..., or later when a user wants to use another ASN.1 description.
So..., my fiels did not end up in the big tree of names.
How to solve this....?
- Call 'proto_init' in the preferences apply routine...
- Copy the whole last part of 'proto_init' to
'proto_register_field_array'...
- Make a new function that registers 1 field and populates the
'gpa_name_tree'
correctly, so that this can be removed from proto_init...
- Any other way....
I'd like to hear some opinions about these issues.
Thanks.
--
Regards,
---------------------------------------------------------------- -o)
Matthijs Melchior Maarssen /\\
mmelchior@xxxxxxxxx Netherlands _\_v
---------------------------------------------------------------- ----
