Wireshark-bugs: [Wireshark-bugs] [Bug 9158] LLC: Display I/G and C/R bits in subtree/bitwise vie
Comment # 10
on bug 9158
from Peter Paluch
Hi Jeff,
First of all, thank you all for keeping this bug open for so long. Sorry for
not responding earlier.
I have finally managed to update the patch so that both the SAP value and the
GI/CR bit are properly dissected and displayed as bitfields.
I have tried to go with the BASE_CUSTOM handler but I've noticed very soon it
is not going to help me here: even with BASE_CUSTOM handler, Wireshark adds the
description from the hf_ entry before the string returned from the callback
function which is NOT the way bitfields are supposed to be dissected (their
output format is different: first the bitfield, then the equal sign, then the
decoded value).
So finally, after getting somewhat frustrated with the inability to work around
the existing behavior of proto_tree_add_... functions, I have chosen probably
the daftest approach: reuse the decode_bitfield_value() in my own function to
format the SAP value into a bitfield string, and subsequently add it into the
proto tree using the proto_tree_add_text().
It may seem that adding a text item instead of a FT_UINT8 value is not a
sensible approach because such item is not filterable. However, if filtering by
the entire DSAP/SSAP value (which is the typical way of filtering on SAPs),
this value is always added to the tree in its entirety and indexed by
"llc.dsap" and "llc.ssap" filter strings. If the GI or CR bit are to be
matched, "llc.dsap.ig" and "llc.ssap.cr" filter strings are available.
Searching for the value of the DSAP/SSAP & 0xFE which would be the value
currently added by the proto_tree_add_text() is not done and should not be
done, as IEEE stipulates: "An individual actual address value does not
necessarily have any relationship with a group address of the same actual
address value." (http://standards.ieee.org/develop/regauth/tut/llc.pdf)
Following this consideration, the choice of displaying the SAP "actual address"
using proto_tree_add_text() is hopefully acceptable.
I am attaching a patch and I am again asking for your kind review - and if
agreeable, for its inclusion into Wireshark codebase.
Thank you!
Best regards,
Peter
You are receiving this mail because:
- You are watching all bug changes.