Wireshark-dev: Re: [Wireshark-dev] Bitfield handling inproto_tree_add_uint_format()
From: "Anders Broman" <[email protected]>
Date: Mon, 19 Nov 2007 18:02:09 +0100
Hi,
The way it's working looks ok to me:
Value = 1010 1010
Proto_add_item()   1010 10.. Ox2a

x = tvb_get_guint8(tvb, 0) >> 2;
X = 0010 1010 

proto_tree_add_uint_format(tree, hf_x, tvb, 0, 1, x,
> 	"the value of X formatted in some way");
Value = 0010 10.. 0x0A as a mask is used in hf_xx
Regards
Anders

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jaap Keuter
Sent: den 19 november 2007 17:31
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Bitfield handling
inproto_tree_add_uint_format()

Hi,

 From a code point of view (epan/proto.c) I can see why this is
happening. From a API point of view this looks wrong. If I'm serving the
function the value to work with I expect it to work with that value, not
its own interpretation of it.
Let's have a look at what happens if we change this.

Thanx,
Jaap

Alexey Neyman wrote:
> Hi all,
> 
> I have the following question: in the dissector I am writing, there is

> a bitfield occupying bits [2..7] of a byte. I have defined it as
follows:
> 
> { &hf_x, { "X", "p.x", FT_UINT8, BASE_HEX, NULL, 0xfc, "", HFILL }}
> 
> Everything is okay if I add that field using proto_tree_add_item(). 
> However, the following code fails:
> 
>   x = tvb_get_guint8(tvb, 0) >> 2;
>   proto_tree_add_uint_format(tree, hf_x, tvb, 0, 1, x,
> 	"the value of X formatted in some way");
> 
> The problem is that the value assigned to the "p.x" variable for 
> packet matching is shifted 2 bits right one more time in
proto_tree_set_uint().
> Workaround is easy: for such fields, the bitmask could be specified as

> zero in header_field_info. I looked for other dissectors which might 
> have faced such issue; in fact, epan/dissectors/packet-cimd.c just 
> employs such workaround.
> 
> However, I wonder if this is a known and desired side-effect of
> proto_tree_add_uint_format() that makes its behavior different from 
> proto_tree_add_item(). The doc/README.developer does not appear to 
> mention that proto_tree_uint_format() takes not "final value" for 
> fields with a bitmask, but rather raw, "unshifted" value.
> 
> Best regards,
> Alexey Neyman.
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
> 

_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev