Ethereal-dev: Re: [Ethereal-dev] [RFC 2nd try] specially mark protocol fields "generated" by E

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: "Olivier Biot" <ethereal@xxxxxxxxxx>
Date: Sat, 1 May 2004 18:44:25 +0200
From: metatech

| From: Ulf Lamping:
|
| >#define FI_GENERATED 0x0002 /* still need a good name for this */
|
| Instead of "generated" couldn't we say "deduced" (as in logic when
you take
| two true propositions and deduce a third) ?

Personally, I like the FT_GENERATED, but how about FT_DERIVED?

Anyway, there are many types of fields:
a. Explicitly available (can be added with proto_tree_add_item())
b. Render a summary of a bitfield (proto_item_append_XXX())
c. Stringify fields like in the WAP dissectors
d. Computed fields based on input from more than one field
e. Generated fields based on data from the packet and from outside it
f. Nameless fields that only appear in the protocol tree, but are not
filterable

there is no simple defintion. I'd say the reassembly fields are
generated, while request-response matching seems to be derived from
packet data and dissection state. TCP analysis flags are derived from
the TCP dissection, but maybe they can also be seen as generated?

Regards,

Olivier