Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] proto_tree_add_item problem

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 23 Jan 2007 09:48:55 -0800
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.