On Thursday, August 21, 2003, at 1:23 PM, Matthijs Melchior wrote:
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].
Third solution:
- Supply to "proto_tree_add_string_format()" as the length the length
in the PDU to mark in the hex display, and supply to it as the value to
be used in the matching process the string you extracted.
"proto_tree_add_item()" uses the length argument to extract a value
from the tvbuff to attach to the protocol tree item for use in
filtering; most of the other "proto_tree_add_" routines don't.
Note, though, that for many TLV-based protocols, the T and the L are
put into the protocol tree along with the V.
The ASN.1 BER-based protocols currently don't put into the protocol
tree items for the ASN.1 overhead (type codes, lengths, etc.), but
there should perhaps be a preference item to allow the user to request
that all the ASN.1 encoding stuff be dissected.
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.
...but not in the man page, unfortunately.
Of course, if you are building from source with plugins, their fields
don't necessarily show up in the man page, either, as the plugins might
not have been installed in the directory in which the Ethereal or
Tethereal binary built from source will be looking for them. The man
page is Rather Large at this point, and it might or might not be useful
to enumerate all the fields in it.
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...
"proto_init()" does a lot more than just build the header-field symbol
table, so that's probably not a good idea.
- Copy the whole last part of 'proto_init' to
'proto_register_field_array'...
"Inheritance by cut and paste" has its problems. If you replace "copy"
with "move", it'd be better; as long as you create "gpa_name_tree"
before any fields are registered, that should work.
