Home page logo

wireshark logo Wireshark mailing list archives

Re: About hidden fields and generated fields ...
From: DbdM Tbt <spin.x2k () gmail com>
Date: Tue, 13 Aug 2013 19:21:09 +0800

Hello Pascal and Harris,
Personally I too would prefer to use 'ofx.command == "add"' so that there
is no need to write more code.
I'll just have to wait and see for the final decision.
And thank you for the information on generated fields, I will read more
based on the resources you referred.

About your suggestion on having a drop-down menu for the possible values.
Is the information on how to implement it available somewhere in the README

Thank you very much,

On Tue, Aug 13, 2013 at 3:36 PM, Guy Harris <guy () alum mit edu> wrote:

On Aug 13, 2013, at 12:06 AM, DbdM Tbt <spin.x2k () gmail com> wrote:

Good day to all.
Please bear with me as I am still learning the ins and outs of
formatting dissector output.
I have come across a discussion about hidden fields and generated fields.

I am curious about this because I have a filter requirement.

Let's say there is a field called 'command'
| field 1 |
| command |
| field n |

'command' can have 3 values.
add (1), modify (2), delete (3)

From what I have currently seen so far, the 'command' field is first
'registered' through a 'static hf_register_info' variable into

All named fields are registered that way.

So for the 'command' field it will look something like:
{ &ofx_command, { "Command", "ofx.command", FT_UINT32, BASE_DEC,
VALS(cmd_vals), NO_MASK, "Command", HFILL } }
Hence, 'ofx.command' will become the filter name.

Now I would like to create a 'convenience filter' (I don't know the
correct term) for the 3 values.

So that you can have, as a filter expression


to search for "Add" commands, rather than

        ofx.command == "Add"

(or however you choose to capitalize it in cmd_vals)?

With what I know, I will implement this by:
1. register additional 3 'static hf_register_info' entries for each
2. and use hidden fields so that wireshark will display only 1 field.
This will be so that the filter ofx.command and for example,
ofx.command.add (assuming the value is add(1)), will work simultaneously.

But based on what I have read, hidden fields are deprecated and/or
discouraged (?).

Yes - if the field is hidden, it isn't in the protocol tree, so you can't
see it through the part of the UI that shows you packet details, and you're
less likely to know that it exists; it only shows up in the drop-down menu
in filter fields and in the "Filter:" dialog box for the field.

It would be nice if, for a field that has a set of values, the drop-down
menu would show you the known values for a field, so that if you've typed,
for example

        ofx.command ==

the drop-down menu would show you a choice of


How would more experienced dissector developers go around this?

I would simply rely on being able to say

        ofx.command == "Add"

And from the discussion that I linked at the start, there is a mention
about 'generated fields'
I tried searching in google and the archives for the above keyword but
no clear information as to what are they

They are fields whose values don't directly correspond, or don't at all
correspond, to packet data.

If, for example, you have a request/response protocol in which a request
has a request type value and a request ID, and a response has a request ID
giving the ID of the corresponding request and has *no* type value, you
might want to, for a response, display the type of request to which it's a
response.  That type isn't part of the packet - you'd keep a table of
requests, giving the ID and type of the request, and look in that table to
find the request type - so, if it were put into the protocol tree of the
response, it'd be a generated field.

If you were to calculate some value based on the value of one or more
fields in a packet, and display that value in the dissection, that would
also be a calculated field.

and how they are implemented

They're implemented by calculating the value, calling proto_tree_add_XXX()
for the appropriate type value of XXX (e.g., "uint" for an unsigned
integer) with the value as an argument to put the value into the protocol
tree, and then calling PROTO_ITEM_SET_GENERATED() on the return value of

(how they look?).

They're enclosed in square brackets in the packet details display, to
indicate that they're generated.
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org

Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]