This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hi all,

I'm dissecting non byte aligned fields. I use proto_tree_add_bits_item() it works pretty well but I would like to have the same output as proto_tree_add_item().

I don't want to have the output like: ..10 1010 10.. .... "value" But : value: 10 1010 10 (Like byte aligned standard output).

My problem is that this output is very difficult to read because my fields are not aligned at all (once 6 bits, once 2 bits, once 18 bits ...). Wireshark display it in lines and it is difficult to figure out what we are looking for.

Is it possible to change the output or do I need to format it manually with proto_item_set_text() and re-write the output format of proto_tree_add_item() ?

Regards.

Eric

asked 18 Feb '13, 05:29

EricST's gravatar image

EricST
1111
accept rate: 0%


Go have a look at the _format_value() variants of proto_tree_add_.

permanent link

answered 18 Feb '13, 14:05

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

Hi,

I looked for _format_value() variants but there is no variant for add_bits_item. Others are all byte aligned (offset in byte) and I would like to read several non aligned fields.

It works but it looks like:

.... ..00 = Field1: 0x00

0000 01.. = Field2: 1

.... ..00 1010 .... = Field3: 0x0a

.... 0001 1000 0110 1010 00.. = Field4: 0x0061a8

And it is not very human readable, I would prefer to hide the fact that it is not byte aligned and print as usually:

Field1: 0x00

Field2: 1

Field3: 0x0a

Field4: 0x0061a8

Do I need to get each field's value by _ret_value variant and make my own string ?

Thanks for help,

Eric

(20 Feb '13, 07:25) EricST

Hi,

Could someone give me just a track to solve my issue?

Best regards, Eric

(07 Mar '13, 05:47) EricST

Forget about add_bits_item. Go look at proto_tree_add_uint[_format_value()]. This goes something like: 1. extract the byte field from the TVB, 2. extract your bitfield from that. 3. proto_tree_add_uint() / proto_tree_add_uint_format_value() are now free of bitmasks for representation.

(07 Mar '13, 06:43) Jaap ♦

And it is not very human readable, I would prefer to hide the fact that it is not byte aligned and print as usually

N.B The output of proto_add_bits_item() is chosen so you can understand which bits makes up the field highligted in the bytes pane which I at least finds more useful than just displaying the field. I would think twice before going for a different format.

(07 Mar '13, 07:08) Anders ♦

I'm with Anders - the truth is your fields are bitfields, for all intents and purposes. It might be more confusing to someone using your dissector for the purpose of troubleshooting your protocol to see bytes that are not bytes. It might help you out too, to see them the way they really are. It usually helps me when I'm writing a dissector, anyway.

(07 Mar '13, 08:36) Hadriel

Also, if they're unaligned fields that are related and all together form a larger aligned byte field, you can always hide them in a subtree and have the top-level tree item show their aggregated aligned byte form. For example open any capture file with IP packets and look at the "Differentiated Services Field" of the IP header in Wireshark. It shows it as a subtree, with a descriptive top-level that gives the info, but if the user wants to see the details they can expand the subtree to see it as the bitfields.

(07 Mar '13, 08:36) Hadriel
showing 5 of 6 show 1 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×63
×16

question asked: 18 Feb '13, 05:29

question was seen: 3,385 times

last updated: 07 Mar '13, 08:36

p​o​w​e​r​e​d by O​S​Q​A