On Thu, May 17, 2018 at 3:41 AM, Peter Wu <pe...@lekensteyn.nl> wrote: > On Wed, May 16, 2018 at 08:32:12AM -0700, Richard Sharpe wrote: >> On Wed, May 16, 2018 at 8:01 AM, Richard Sharpe >> <realrichardsha...@gmail.com> wrote: >> > 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. >> >> I came across this in _tvb_get_bits64: >> >> /* get bits from any partial octet at the tail */ >> if(remaining_bit_length) >> { >> value <<= remaining_bit_length; >> value += (tvb_get_guint8(tvb, octet_offset) >> >> (8 - remaining_bit_length)); >> } >> } >> >> That would seem to take the top bits from the next byte but that seems >> incorrect from the point of view of many uses. > > It looks valid for me, but only for ENC_BIG_ENDIAN types. Your field is > ENC_LITTLE_ENDIAN. We have this comment here in tvb_get_bits: > > /* note that encoding has no meaning here, as the tvb is considered to > contain an octet array */ > > Perhaps you could start with a change that modifies tvb_get_bits to > respect the encoding parameter?
I found another way to do what I wanted ... however, I don't think there is any architecture that arranges its bits in a big endian fashion, but maybe that is because I have never looked. -- Regards, Richard Sharpe (何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe