On Apr 12, 2016, at 7:01 PM, Michael Mann <[email protected]> wrote:
> Because it made sense to integrate the expert info under the protocol
> architecture (and register it through proto_register_protocol("Expert Info",
> "Expert", "_ws.expert"); ). The "string version" of the field would be
> "_ws.expert.message"
No, the "string version" of "_ws.expert" wouldn't be another field, it would be
the string displayed for _ws.expert in the protocol tree. In bug 12335,
they're *NOT* looking at _ws.expert.message to see whether it contains a
particular string, they're looking at _ws.expert to see whether it contains a
particular string.
Either we have to somehow *forbid* the use of _ws.expert in filter expressions
- *without* forbidding the use of other FT_PROTOCOL fields! - or we need to
make it work without crashing.
If we decide to make it work without crashing, the "string version" of
_ws.expert would be the
Expert Info ({severity}/{group}): {message}
text, and I suggest that we:
1) rename ftype-tvbuff.c to ftype-protocol.c, so as not to suggest that
this is a "this is a tvbuff" value type (its FT_ value is FT_PROTOCOL, not
FT_TVBUFF);
2) change all the functions in there *not* to assume that there's a
non-null tvb value and to, if the tvb value is null, treat the formatted string
value as the value to compare/match/check-for-contains/etc.;
because that's what we'd have to do in order to fix this problem.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
