Re: [Wireshark-dev] Correct and efficient way of displaying bit fields?
On Oct 7, 2011, at 5:22 PM, Kaul wrote: I'm struggling for some time now with displaying bitfields, I'm sure there must be something I'm overlooking, or it's just a bit difficult to do in Wireshark. I have a 32bit, little endian field, which I'd like to parse the bits (as set/not set): Example: 05 00 00 00 1 0 0 0 Feature A - set 0 0 0 0 ... Feature B - not set 0 0 1 0 ... Feature C - Set 1. Do I really have to create a hf_xxx for each? And use something like proto_tree_add_bits_item() ? I was hoping to do it in a single proto_tree_add_xxx() and pass it a single HF that would hold a VALS(...) which will describe all the attributes. Take a look at proto_tree_add_bitmask(). You still have to create each hf_xxx since each bit (or group of bits) is a different parameter, but then a single call to proto_tree_add_bitmask will set up the subtree for the whole bitfield. Glenn ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Correct and efficient way of displaying bit fields?
Am 07.10.2011 23:22, schrieb Kaul: I'm struggling for some time now with displaying bitfields, I'm sure there must be something I'm overlooking, or it's just a bit difficult to do in Wireshark. I have a 32bit, little endian field, which I'd like to parse the bits (as set/not set): Example: 05 00 00 00 1 0 0 0 Feature A - set 0 0 0 0 ... Feature B - not set 0 0 1 0 ... Feature C - Set 1. Do I really have to create a hf_xxx for each? And use something like proto_tree_add_bits_item() ? I was hoping to do it in a single proto_tree_add_xxx() and pass it a single HF that would hold a VALS(...) which will describe all the attributes. When you add all these hf_info records you provide information that will be displayed quite well. Additionally all these fields can be used in a display filter expression. That's worth to add all the info. When I have such one-bit fields I put them in an array and use a loop over this field and call proto_tree_add_boolean for each iteration. This saves code lines. But when the field size varies, you will need individual code lines. Helge ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Correct and efficient way of displaying bit fields?
On Oct 7, 2011, at 2:22 PM, Kaul wrote:
I'm struggling for some time now with displaying bitfields, I'm sure there
must be something I'm overlooking, or it's just a bit difficult to do in
Wireshark.
I have a 32bit, little endian field, which I'd like to parse the bits (as
set/not set):
Example:
05 00 00 00
1 0 0 0 Feature A - set
0 0 0 0 ... Feature B - not set
0 0 1 0 ... Feature C - Set
That's 0xA, not 0x5; presumably, with the uppermost bit shown on the left and
the lowermost bit shown on the right - the convention I've seen almost
universally used - it'd be
0 0 0 1 Feature A - set
0 0 0 0 ... Feature B - not set
0 1 0 0 ... Feature C - Set
1. Do I really have to create a hf_xxx for each? And use something like
proto_tree_add_bits_item() ? I was hoping to do it in a single
proto_tree_add_xxx() and pass it a single HF that would hold a VALS(...)
which will describe all the attributes.
Assuming the field is 4 bits, you could create a single item for those four
bits, with 16 values. In that case, that particular example would as something
such as
Feature set: 0x5 (feature A present, feature B not present, feature C
present, feature D not present)
Is that what you want?
There is nothing in Wireshark that lets you show each flag as a single Boolean
item with one field - you have (at least) four Booleans, hence you would need
(at least) four fields.
2. How do I take into consideration the endianess?
By not using bit offsets.
Best I could do so far, it works but it's ugly and not maintainable, is:
#define COMMON_CAP_AUTH_SELECT 0x0001
#define COMMON_CAP_AUTH_SPICE 0x0002
#define COMMON_CAP_AUTH_SASL0x0004
...
proto_tree_add_item(tree, hf_common_cap_auth_select, tvb, offset, 4,
ENC_LITTLE_ENDIAN);
proto_tree_add_item(tree, hf_common_cap_auth_spice, tvb, offset, 4,
ENC_LITTLE_ENDIAN);
proto_tree_add_item(tree, hf_common_cap_auth_sasl, tvb, offset, 4,
ENC_LITTLE_ENDIAN);
...
{ hf_common_cap_auth_select,
{ Auth Selection, spice.common_cap_auth_select,
FT_BOOLEAN, 32, TFS(tfs_set_notset), COMMON_CAP_AUTH_SELECT,
NULL, HFILL }
},
{ hf_common_cap_auth_spice,
{ Auth Spice, spice.common_cap_auth_spice,
FT_BOOLEAN, 32, TFS(tfs_set_notset), COMMON_CAP_AUTH_SPICE,
NULL, HFILL }
},
{ hf_common_cap_auth_sasl,
{ Auth SASL, spice.common_cap_auth_sasl,
FT_BOOLEAN, 32, TFS(tfs_set_notset), COMMON_CAP_AUTH_SASL,
NULL, HFILL }
},
If I look at how it's done in packet-tcp.c, then it's again quite a bit of
manual labour, this time with proto_tree_add_boolean() - per each single bit!
Well, yeah, each bit is a single Boolean field, each of which a user might want
to check for in a filter expression, so of *course* there will be one call per
bit, to put an item for that bit into the protocol tree!
And as for manual labor, well, the whole dissector was constructed with a lot
of manual labor; the best way to get rid of the manual labor is to have a
packet description language such as, for example, the wsgd language:
http://wsgd.free.fr
and have something read that and generate code (or tables processed by an
interpreter, or whatever). Worrying only about fields that happen to take only
one bit is worrying about a very minor concern.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Correct and efficient way of displaying bit fields?
I'm struggling for some time now with displaying bitfields, I'm sure there
must be something I'm overlooking, or it's just a bit difficult to do in
Wireshark.
I have a 32bit, little endian field, which I'd like to parse the bits (as
set/not set):
Example:
05 00 00 00
1 0 0 0 Feature A - set
0 0 0 0 ... Feature B - not set
0 0 1 0 ... Feature C - Set
1. Do I really have to create a hf_xxx for each? And use something like
proto_tree_add_bits_item() ? I was hoping to do it in a single
proto_tree_add_xxx() and pass it a single HF that would hold a VALS(...)
which will describe all the attributes.
2. How do I take into consideration the endianess?
Best I could do so far, it works but it's ugly and not maintainable, is:
proto_tree_add_bits_item(tree, hf_common_cap_auth_select, tvb, (offset * 8)
+ 7, 1, ENC_NA);
proto_tree_add_bits_item(tree, hf_common_cap_auth_spice, tvb, (offset * 8) +
6, 1, ENC_NA);
proto_tree_add_bits_item(tree, hf_common_cap_auth_sasl, tvb, (offset * 8) +
5, 4, ENC_NA);
...
{ hf_common_cap_auth_select,
{ Auth Selection, spice.common_cap_auth_select,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
{ hf_common_cap_auth_spice,
{ Auth Spice, spice.common_cap_auth_spice,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
{ hf_common_cap_auth_sasl,
{ Auth SASL, spice.common_cap_auth_sasl,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
If I look at how it's done in packet-tcp.c, then it's again quite a bit of
manual labour, this time with proto_tree_add_boolean() - per each single
bit!
Is there a better way?
TIA,
Y.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
