Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 9360] New: Duplicate header field abbreviation breaks filter (example: irc.res

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	9360
Summary	Duplicate header field abbreviation breaks filter (example: irc.response.command)
Classification	Unclassified
Product	Wireshark
Version	1.10.2
Hardware	All
OS	All
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Common utilities (libwsutil)
Assignee	bugzilla-admin@wireshark.org
Reporter	lekensteyn@gmail.com

Build Information:

--
The irc.response.command field is both a 16-bit integer and string. This breaks
the filtering engine:

$ dftest 'irc.response.command_parameter and not irc.response.command ==
"PONG"'
Filter: "irc.response.command_parameter and not irc.response.command == "PONG""
dftest: "PONG" cannot be converted to Unsigned integer, 2 bytes.

tshark lists only one field, of type string:
$ tshark -G fields | grep -F irc.response.command -w
F       Command irc.response.command    FT_STRING       irc             0x0    
Response command

The documentation doc/README.dissector allows two abbreviation for the same
type, but apparently this does not work:
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---

It is OK to have header fields with a different format be registered with 
the same abbreviation. For instance, the following is valid:

    static hf_register_info hf[] = {

        { &hf_field_8bit, /* 8-bit version of proto.field */
        { "Field (8 bit)", "proto.field", FT_UINT8, BASE_DEC, NULL,
            0x00, "Field represents FOO", HFILL }},

        { &hf_field_32bit, /* 32-bit version of proto.field */
        { "Field (32 bit)", "proto.field", FT_UINT32, BASE_DEC, NULL,
            0x00, "Field represents FOO", HFILL }}
    };   

This way a filter _expression_ can match a header field, irrespective of the
representation of it in the specific protocol context. This is interesting
for protocols with variable-width header fields.

---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---

It looks like that behavior is only valid for numeric types, not different
types such as strings and numbers?

---

      You are receiving this mail because:

• You are watching all bug changes.