Wireshark · Wireshark-dev: [Wireshark-dev] Does proto_tree_add_bits_item treat the bits in a little endian manner as well of yo

[Richard Sharpe <realrichardsharpe@xxxxxxxxx>]

Hi folks,

I am seeing something weird with proto_tree_add_bits_item, although it
could be my misunderstanding as well.

Attached are two screen shots showing the dissected field and the byte view.

The code:
--------
static void
dissect_a_control_bsr(proto_tree *tree, tvbuff_t *tvb, int offset,
  guint32 bits _U_, guint32 start_bit)
{
  start_bit += offset * 8;
  proto_tree_add_bits_item(tree, hf_ieee80211_he_bsr_aci_bitmap, tvb,
                        start_bit, 4, ENC_LITTLE_ENDIAN);
  proto_tree_add_bits_item(tree, hf_ieee80211_he_bsr_delta_tid, tvb,
                        start_bit + 4, 2, ENC_LITTLE_ENDIAN);
  proto_tree_add_bits_item(tree, hf_ieee80211_he_bsr_aci_high, tvb,
                        start_bit + 6, 2, ENC_LITTLE_ENDIAN);
  proto_tree_add_bits_item(tree, hf_ieee80211_he_bsr_scaling_factor, tvb,
                        start_bit + 8, 2, ENC_LITTLE_ENDIAN);
--------------

is dealing with a field that contains 0x8f 0xb0 0x00 0x08.

The first (always counting from the RHE) six bits (0b001111 from 0x8f)
are the HTC+ control bits (2 bits) and the Aggregate control field
bits (4 bits). These are being dissected correctly as HTC+ = 0x3 and
A-Control as 0x3 as well.

The next four bits are the ACI Bitmap, and they should be 0b0010 but
they are displaying as 0b1110 as if the bottom two bits of the 0xb
from 0xb0 were being grabbed rather than the bottom two bits of 0x0,

I hope this is making sense. I guess I need to look more closely at
the code in decode_bits_in_field.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

Attachment: proto-tree-add-bits-1.JPG
Description: JPEG image

Attachment: proto-tree-add-bits-2.JPG
Description: JPEG image