[Guy Harris <guy@xxxxxxxxxxxx>]

On Aug 13, 2013, at 12:06 AM, DbdM Tbt <spin.x2k@xxxxxxxxx> 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.
> http://www.wireshark.org/lists/wireshark-dev/201110/msg00257.html
> 
> 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 proto_register_field_array()

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.
> ofx.command.add
> ofx.command.modify
> ofx.command.delete

So that you can have, as a filter expression

	ofx.command.add

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 filter.
> 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

	"Add"
	"Modify"
	"Delete"

> 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 proto_tree_add_XXX().

> (how they look?).

They're enclosed in square brackets in the packet details display, to indicate that they're generated.