jaiswal.vikash@xxxxxxxxx wrote:
I've developed a dissector and it has one statement as :
proto_tree_add_item(proto_tree, hf_xyz_any_field, tvb, offset, 16,
FALSE);
This statement is not getting executed , the wireshark is giving error "
malformed packet ".
But when I'm changing the length ( 16 ) to smaller value , say 2 or 4 ,
it's working well .
The corresponding hf is
{ &hf_xyz_any_field,
{ "Any Field", "xyz.any_field", FT_UINT8, BASE_DEC,
NULL, 0x0, "", HFILL }},
16 is *NOT* a valid length for that field. You've declared that field
to be a 1-byte unsigned integer, to be displayed in decimal; you can't
then say it's 16 bytes.
The fact that it lets you specify 2 or 4 bytes is a consequence of the
fact that integral values of 1 to 4 bytes are all internally stored as
4-byte quantities, so it's not impossible in the implementation to
handle it as a 4-byte quantity, although it should check for that anyway.
You obviously can't stuff a 16-byte value into a 4-byte storage
location, however, so that *is* treated as an error. The fact that the
error reported is "Malformed packet" is a bug; that might date back to a
time before we had the ability for the core of Wireshark to report a
dissector bug in a way other than crashing Wireshark.
There is currently no mechanism in Wireshark to handle decimal values
longer than 8 bytes. Your 16-byte field would have to be declared as an
FT_BYTES field, in which case it would be displayed in hexadecimal; you
would have to write your own code to handle 16-byte decimal numbers and
use proto_tree_add_bytes_format() to display it in decimal.
