Ethereal-dev: Re: [Ethereal-dev] 2 design issues

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 21 Aug 2003 16:42:15 -0700

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.