On Sat, Jul 14, 2001 at 08:08:31PM +0100, Andrew Barrington wrote:
> Is this bug fixed in a later version/patch or is it the fact that ethereal is
> expecting a null terminated string in the info string parameter
Probably. The code in "dissect_m3ua_info_parameter()" is doing
info_string = (char *)tvb_get_ptr(parameter_tvb, INFO_STRING_OFFSET, info_string_length);
proto_tree_add_string(parameter_tree, hf_m3ua_info_string,
parameter_tvb, INFO_STRING_OFFSET, info_string_length ,
info_string);
proto_item_set_text(parameter_item, "Info String (%s)", info_string);
but "proto_tree_add_string()", and the formatting routine used by
"proto_item_set_text()", are assuming that "info_string" is
null-terminated; however, "tvb_get_ptr()" just supplies a pointer to the
raw data in the frame, so if it's not null-terminated, it'll treat the
string as continuing until a zero byte is seen, which means it may run
into the next string.
If the string might not be null-terminated, then one way of solving this
would be to do
proto_tree_add_item(parameter_tree, hf_m3ua_info_string,
parameter_tvb, INFO_STRING_OFFSET, info_string_length,
FALSE);
proto_item_set_text(parameter_item, "Info String (%.*s)",
(int)info_string_length, info_string);
The "proto_tree_add_item()" call will work if the string is not
null-terminated in the packet, as the "hf_m3ua_info_string" protocol
item is of type FT_STRING (meaning "counted string") rather than
FT_STRINGZ (meaning "null-terminated string"), and the
"proto_item_set_text()" call will work as "%.*s" is used, with the
string length, so that only that many bytes of text are used.
