Comment # 9
on bug 9158
from Peter Paluch
(In reply to comment #8)
Jeff, I also apologize for my delay - the same overload here.
Thank you for your suggestion. Well, I tried something along the lines of the
following:
dsap = tvb_get_guint8(tvb, 0);
dsap_value = dsap & SAP_MASK;
proto_tree_add_uint_format_value(field_tree, hf_llc_dsap_value,
tvb, 0, 1, dsap_value, "%s (0x%02x)",
val_to_str_const(dsap_value, sap_vals, "Unknown"), dsap_value);
This hack works quite nicely, the DSAP value is nicely dissected and displayed
in the bitmask subtree without needing to >>1 shift the values in the sap_vals.
The problem is that the hf_llc_dsap_value is still defined as FT_UINT8 with the
bitmask of 0xFE, so for filtering operations, Wireshark will still store the
DSAP value shifted by one bit to the right. DSAP values by themselves are not
shifted, just their least significant bit expresses individual or group
destination (for SSAP, the same bit expresses whether the frame carries a
command or a response).
So unless there is a way of preventing the proto_tree_add_... functions from
shifting the added value if the mask is non-zero, I will probably need to
define a BASE_CUSTOM handler for this. Shouldn't be that complicated, though.
Best regards,
Peter
You are receiving this mail because:
- You are watching all bug changes.
