Re: Does proto_tree_add_bits_item treat the bits in a little endian manner as well of you say ENC_LITTLE_ENDIAN

[Richard Sharpe <realrichardsharpe () gmail com>]

On Thu, May 17, 2018 at 3:41 AM, Peter Wu <peter () 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
> > <realrichardsharpe () 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-request () wireshark org?subject=unsubscribe