> Gilbert, is this a result of the issue mentioned here?
Yes, it does appear to be related.
"fill_label_boolean()" "unshifts" the value in "fi->value.numeric"
before handing it to "decode_bitfield_value()".
However, given that "proto_tree_set_boolean()" didn't shift the value in
the first place, "unshifting" shifts the relevant bits out of the way.
The value stored in the protocol tree by "proto_tree_set_boolean()"
should *not* be the raw value passed in - it should, instead, be the
value ANDed with the bitmask, so that only the bit(s) in the boolean
bitfield are included in "fi->value.numeric". (I think it unlikely that
a multi-bit bitfield would be considered "Boolean", in the sense that
the multi-bit bitfield is TRUE if any of the bits are set and FALSE if
none of them are set, as that would appear to be a waste of all but one
of those bits, but....)
We don't want to include all bits of the larger item containing a
Boolean bitfield in "value.numeric", as that would mean that if *any* of
bits in that larger item are set, a display filter will think the
bitfield is TRUE, even if the particular bit(s) of the Boolean bitfield
are clear.
So I suspect the right fix is either to make "proto_tree_set_boolean()"
do exactly what "proto_tree_set_uint()" does, or to nuke
"proto_tree_set_boolean()" and use "proto_tree_set_uint()" for Boolean
fields as well as integral fields.