Wireshark-dev: Re: [Wireshark-dev] dissecting bits versus bytes

From: Brian Oleksa <oleksab@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 06 May 2011 22:50:18 -0400
Anders

Yes.... I was able to figure this out.

<4 bits> <1 bit> <2 bits> <1 bit>
        0xf         0x1     0x3        0x1
but then you have to shift the results:
        0xf0       0x8     0x6        0x1
to make room for the other fields.

BUT...I ran into a little snag.

I figured out that I must read 4 bits from the "end" of the byte (which will give me 0010). This means I need to take bits 5-8 to construct the version field...and use
bit 4 for x...and then use bit 3 and 2 for y and then bit 1 for z.

So this means I not only need to keep an index to the actual byte I am on, but the individual bit index as well.

How would I do this within the wireshark code..?

Thanks,
Brian







On 5/6/2011 11:23 AM, Anders Broman wrote:


-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Brian Oleksa
Sent: den 6 maj 2011 16:57
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] dissecting bits versus bytes

Anders

Thanks for the reply.

I was able to dissect the first 4 bits to get the version:

Here is the output:

       {&hf_myproto_version,
               { "Version", "myproto.version", FT_UINT8, BASE_DEC, NULL, 0xf0,
                   NULL, HFILL}},

OUTPUT =    0110 .... = Version: 6

But the next 4 bits are as follows:

x = 1 bit
y = 2 bits
z = 1 bit

       {&hf_myproto_x,
               { "Version", "myproto.x", FT_UINT8, BASE_DEC, NULL, 0x??,
                   NULL, HFILL}},


       {&hf_myproto_y,
               { "Version", "myproto.y", FT_UINT8, BASE_DEC, NULL, 0x??,
                   NULL, HFILL}},


       {&hf_myproto_z,
               { "Version", "myproto.z", FT_UINT8, BASE_DEC, NULL, 0x??,
                   NULL, HFILL}},



I am not sure what I would use to capture 1 or 2 bits...??    (0x????)

Thanks,
Brian


If the first 4 bits are masked with 0xfo which is B'1111 0000
Which bit do you think will be the next one? (Hint 0000 1...)
As an extercise translate that to hex and put it as bitmask :-) ( 0000 1000)
Regards
Anders



On 5/6/2011 9:51 AM, Anders Broman wrote:

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Brian Oleksa
Sent: den 6 maj 2011 15:22
To: Developer support list for Wireshark
Subject: [Wireshark-dev] dissecting bits versus bytes


I am used to getting a spec sheet of a packet that needs to be dissected and most of the time each part of the packet is in bytes.

For example: The first byte in the packet is the version number. So this is what I would do.

        proto_tree_add_item(myproto_sub_tree, hf_myproto_version, tvb, offset, 1, FALSE);
               offset += 1;

       {&hf_myproto_version,
               { "Version", "myproto.version", FT_UINT8, BASE_DEC, NULL, 0x0,
                   NULL, HFILL}},

But now I was ordered to dissect a packet that the max size is in bits.

Since a byte is bigger than a bit.....how would you dissect this..??

version   (max field size = 4 bits)..??

Thanks,
Brian
Hi,
If the spec looks like
        Bit1    Bit4   Bit8
Ocet1 | Verion | Foo |

E.g The fields fill up a byte and always align the protocol is still octet oriented and you should do:

        proto_tree_add_item(myproto_sub_tree, hf_myproto_version, tvb, offset, 1, FALSE);      	proto_tree_add_item(myproto_sub_tree, hf_myproto_foo, tvb, offset, 1, FALSE);
               offset += 1;

       {&hf_myproto_version,
               { "Version", "myproto.version", FT_UINT8, BASE_DEC, NULL, 0xf0,
                   NULL, HFILL}},

       {&hf_myproto_foo,
               { "Foo, "myproto.foo", FT_UINT8, BASE_DEC, NULL, 0x0f,
                   NULL, HFILL}},

Note the bitmasks (0xf0&   0x0f) which decides which part of the octet belongs to this field.
Offset is increased once the whole octet is handled, there is numerous examples in the code base.
Regards
Anders


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe