Build Information:
SVN
--
+++ This bug was initially created as a clone of Bug #9360 +++
Bug 9360's complaint was that a FT_UINT16 and FT_STRING could not share the
same abbreviation:
~~~
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
[...]
It looks like that behavior is only valid for numeric types, not different
types such as strings and numbers?
~~~
But I also had experience that said that an int-type and a string did not
conflict, at least if the int-type had a value_string which allows the DF code
to try to convert the string back to an int. The comments I had in checkAPIs
also indicated the int-types were also compatible with booleans.
There's probably some more research to be done here.
You are receiving this mail because:
- You are watching all bug changes.