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" and there are a few other fields of the format
_ws.expert.XXX for the various other properties of an expert message.
-----Original Message-----
From: Guy Harris <[email protected]>
To: Developer support list for Wireshark <[email protected]>
Sent: Tue, Apr 12, 2016 8:22 pm
Subject: [Wireshark-dev] So why is _ws.expert an FT_PROTOCOL field rather than
an FT_STRING field?
It's really just shown as a string, and doesn't actually refer to packet data
from a tvbuff.
This is causing at least one crash in bug 12335:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12335
and, to fix the crash I'm seeing, we'd have to change the
epan/ftypes/ftype-tvbuff.c cmp_contains() routines to check for the field not
actually having a tvbuff and treating it as a string comparison instead.
Furthermore, all the *other* routines that assume a tvbuff would *also* have to
be changed to handle a null tvbuff, to prevent similar crashes in other cases.
___________________________________________________________________________
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
___________________________________________________________________________
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
