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.