This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How to reference field for display filters?

0

I have a double field (hf_value) and a string field (hf_name); how do I force a bond such that the value depends on the name? I would like to get that in display filters should be used for example:

myProto.field.name == "example" && myProto.field.value == 1

In each package of my protocol may appear a NOT predetermined number of fields, with different names (read from an external file) and with different values​​. In this situation, if I have the same name fields but different content:

Package # 1
Field1 = 10
Field2 = 20

Package # 2 Field1 = 0 Field2 = 10

and apply the following filter:

myProto.field.name == "Field1" && myProto.field.value > 0

I select these two packages, but I would reasonably select only the first.

I registered in the fields hf_register_info like this:

{&hf_myProtocol_field_name, {"Field Name",
"myProto.field.name", FT_STRING, BASE_NONE,
NULL, 0x0,
NULL, HFILL}},
{&hf_myProtocol_campo_value, {"Field Value",
"myProto.field.value", FT_DOUBLE, BASE_NONE,
NULL, 0x0,
NULL, HFILL}

Thank you in advance!

asked 15 May ‘14, 01:33

Junzo's gravatar image

Junzo
11348
accept rate: 100%

edited 19 May ‘14, 08:38

Maybe I need to specify such a reference during the initialization of the structure hf_register_info statement instead of the standard “hfill” but I do not understand how to assign the bonds.

(15 May ‘14, 05:36) Junzo

any ideas?

(19 May ‘14, 01:05) Junzo

Unfortunately I, and possibly others due to the lack of comments or answers, don’t understand what you’re asking.

What do you mean by “force a bond”? Each hf_x item is a separate field set by the dissector. One field may dictate the presence, form or range of values in another field according to the protocol specification, but again that is controlled by the dissector not the Wireshark framework.

Are you saying that if the “nome” field has a specific string, then the value “field” should be set to an explicit value (that is not actually present in the data)? If so the “value” field should be set as required by the dissector and the macro PROTO_ITEM_SET_GENERATED used on the field to indicate it is synthesized.

(19 May ‘14, 02:26) grahamb ♦

Now it is easier to understand the situation?

(19 May ‘14, 03:12) Junzo


One Answer:

0

With the help of your more detailed example I can now see your requirement.

The only thing that comes to mind is to create a generated field that is a string comprised of both field name and value, e.g. "FieldName:Value" using a separator, e.g. the ":", that doesn't appear in the field names. This field can then be used as a filter by combining the values, e.g. proto.campo.fieldnameandvalue == "Field1:10".

answered 19 May '14, 03:13

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

This solution, however, does not allow me to use the operands ">, <, !=, Etc... "

(19 May '14, 03:29) Junzo

I would like a subfield of "field" that contains the value. Can I do that?

(19 May '14, 06:27) Junzo

Wireshark fields are singled valued entities, that don't have sub values, or associated values.

(19 May '14, 07:02) grahamb ♦

So I can not in any way doing what I want to do?

(19 May '14, 07:08) Junzo
1

You can have a look a the diameter dissector which builds hf entries from the AVP xml files and do something similar for your protocol.

(19 May '14, 07:17) Anders ♦

I have read the dissect_diameter_avp function, but I don't understand how this benefit for me. It must be said that I do not have a lot of convenience with the development of plugins for wireshark.

(19 May '14, 07:45) Junzo

Well it's not easy to try to help you as you are not describing what you are trying to do in much detail... What does your file contain and what is the content of the packets sent? The actual text "field 1 = 10" or a TAG and a VALUE or a TAG LENGHT VALUE type field or does your file specify that the first xx bytes are field 1 then next YYY bytes are field 2 and so on.

(19 May '14, 07:59) Anders ♦

What @Anders is describing is dynamically adding hf entries according to a configuration file.

I'm unsure if this is still a one-time initialization though and if Wireshark has to be restarted if the config file is changed.

(19 May '14, 08:06) grahamb ♦

@Anders

// according to the address of the packet
// the name and number fields
// that describe the package
// is searched for in an external file
ti = proto_tree_add_string_format(myProto_field_tree, hf_myProto_field_name, tvb, MYPROTO_DATA_OFFSET, length, fieldName, "%s", fieldName);
PROTO_ITEM_SET_GENERATED(ti);
myProto_singleField_tree = proto_item_add_subtree(ti, ett_myProto_singleField);
// I saved the value of each field
// in a structure "msg"
proto_tree_add_double_format(myProto_singleField_tree, hf_myProto_field_value, tvb, MYPROTO_DATA_OFFSET + offset, length, msg->field[i].value, "Field Value: %g", msg->field[i].value);
I want to get that for every "field" (hf_myProto_field_name) is associated
with a single value (hf_myProto_field_value), so as to be able to filter packets as in the previous example.
To make it even clearer ideas, if I knew the number (and possibly the name) of the fields, the problem did not arise, since I had only to declare different "values" (hf_myProto_value1, hf_myProto_value2, ...) and each of they would be paid one and only one field "field", but since this is not possible, I would still find a way to resolve the situation.
@grahamb
How do I add dynamically hf entries?
(19 May '14, 08:31) Junzo
1

As per the comment from @Anders, in packet-diameter.c, the hf entries are registered by the function real_proto_register_diameter() and that builds the hf array from some static entries and entries constructed by reading from an xml file at dissector registration time.

(19 May '14, 09:03) grahamb ♦

There is a "guide" that explains the process by which dynamically allocate arrays fields of hf? Unfortunately I am a beginner and it is not easy for me to understand how this is done in the dissector "packet-diameter". Thanks @grahamb and @Anders for the answers you have given me so far.

(20 May '14, 07:59) Junzo

No guide I know of. I'll agree that packet-diameter is quite complex.

This question is now starting to get a little too complex for Ask Wireshark, you might be better off taking it to the dev mailing list.

(20 May '14, 08:06) grahamb ♦

Waiting for answers from the developers, I would continue to asks you. My case is much simpler than that of the "packet-diameter", because the fields "value" are all kind of FT_DOUBLE, so I think it is unnecessary to hash table; the only thing that will change will be the string used in the filter (FIELDABBREV) which should, at this point, I have a different name for each field "field". I already have my function that parses the external file by creating a structure "msg" field contains the name of the "field" and the corresponding "value". I guess at this point that the field "field" becomes superfluous, since all the information will be contained in the "value", to which I will assign FIELDABBREV as a string type:

myProto.field.nameField

At this point, the only question to me is, the array hf (build_dict.hf) is initialized in the function "real_proto_register_diameter()", but built in "dictionary_load()"? If so, how exactly? I hope to have been clear. Thank you for your kindness .

(22 May '14, 01:14) Junzo

Or, perhaps, it would be enough for me just what he does in the "basic_avp_reginfo()"?

(22 May '14, 01:30) Junzo

And yet, as you can apply a filter on the desired field if the FIELDABBREV initializes it to NULL?

hf_register_info hf[] = { { &(a->hf_value),
                  { NULL, NULL/FIELDABBREV/, ft, base, NULL, 0x0,
                  a->vendor->code ?
                  wmem_strdup_printf(wmem_epan_scope(), "vendor=%d code=%d", a->vendor->code, a->code)
                  : wmem_strdup_printf(wmem_epan_scope(), "code=%d", a->code),
                  HFILL }}
    };
(22 May '14, 02:06) Junzo

Oh, I may have found it! Perhaps the "regInfo()" function is what it does for me.. tell me if I'm wrong.

(22 May '14, 02:10) Junzo

I also noticed that every time that if you wanted to change the xml file, I should restart wireshark to reconstruct the appropriate arrays of hf field, right?

(22 May '14, 03:20) Junzo

That's what I was referring to in my comment above:

I'm unsure if this is still a one-time initialization though and if Wireshark has to be restarted if the config file is changed.

I believe a dissector can only initialise the hf entries once, whether they are hard-coded or built dynamically from an external source such as a file.

(22 May '14, 03:47) grahamb ♦
showing 5 of 18 show 13 more comments