Wireshark mailing list archives
Re: Correct and efficient way of displaying bit fields?
From: Guy Harris <guy () alum mit edu>
Date: Sat, 8 Oct 2011 13:12:55 -0700
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 0x00000001 #define COMMON_CAP_AUTH_SPICE 0x00000002 #define COMMON_CAP_AUTH_SASL 0x00000004 ... 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-request () wireshark org?subject=unsubscribe
Current thread:
- Correct and efficient way of displaying bit fields? Kaul (Oct 07)
- Re: Correct and efficient way of displaying bit fields? Helge Kruse (Oct 08)
- Re: Correct and efficient way of displaying bit fields? Guy Harris (Oct 08)
- Re: Correct and efficient way of displaying bit fields? Glenn Matthews (Oct 10)