On Apr 12, 2016, at 7:01 PM, Michael Mann <mmann78@xxxxxxxxxxxx> 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.
