| 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 |
[email protected]
|
| Reporter |
[email protected]
|
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.
