Olivier Biot wrote:
From: Ulf Lamping
| Hi List!
|
| It's sometimes confusing to distinguish between protocol fields
derived
| from the capture data and fields that are generated by Ethereal
while
| dissecting "from knowledge" (e.g. from context information).
|
| Example:
|
| In the DCE-RPC dissecting are some protocol fields generated by
| knowlegde from context, like a hint to the response in a request
packet,
| looking like.
|
| Response in frame: 10
|
| This means that the response PDU to the current one is in packet 10.
| This protocol field has no data representation inside the packet.
|
| From the DCE/RPC desegmenting, I got the idea to put some brackets
| (what's the correct english name for this brackets?) around the
Ethereal
| generated info, so this will look like:
|
| [Response in frame]: 1
Snip
It is a good idea to provide such a distinction between information
within the protocol packet and generated information.
Some other options:
a. Prepend or append an asterisk to the field name
b. Render the field differently (e.g., italics in Ethereal)
Once we have agreed on some output format we may first want to edit
the reassembly code as that will impact *all* dissectors that use
reassembly at once.
Hmmm, I only thought of simply renaming the output format string in the
hf_register_info fields, e.g. "Response in frame" -> "[Response in
frame]".
It might be even a better idea to provide this info into the
hf_register_info by adding it in a "machine friendly" format, like
or'ing a flag into the FT_xy fields.
As this will be definitely the better technical solution, it would
require changes at least in the packet tree rendering and I don't have
much knowledge if this can easily be done.
So the hf_register_info entry could look, like: FT_FRAMENUM |
FT_GENERATED, or we could provide another set of field registration
functions, like: proto_tree_add_uint_generated()
This would make it possible to do various formatting of the output later.
Anyone an idea of how much effort that would be?
Regards, ULFL
