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.

@Harris:
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
files?

Thank you very much,
David



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

___________________________________________________________________________
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 ]