Some of the discussion specific to Bluetooth is covered in https://code.wireshark.org/review/19482, but the short version is that there still is a desire to have Bluetooth attributes be enabled/disabled (like a protocol), but I think that functionality can be achieved with Decode As (as in "do not decode as"), with the attributes being PINOs (for the same reason as TCP TLVs - easy way to retrieve a "name" value for display). This feature is available in GTK version, but not Qt (bug 12098). I was going to wait until bug 12098 was fixed before submitting https://code.wireshark.org/review/19482, which would turn the Bluetooth attributes into PINOs and eliminate them from the Enable Protocols (and tshark -G protocols) list. -----Original Message----- From: Guy Harris <[email protected]> To: Developer support list for Wireshark <[email protected]> Sent: Thu, Jan 5, 2017 8:00 pm Subject: Re: [Wireshark-dev] Protocols vs dissectors, take 23
On Jan 1, 2017, at 11:39 PM, Michal Labedzki <[email protected]> wrote: > On 2 January 2017 at 03:13, Michael Mann <[email protected]> wrote: > >> To me, pinos don't have the same capabilities as real protocols. They don't >> have hf_ fields or heuristic dissection functions associated with them. >> ... >> The last example I have is one of the reasons for writing this email in the >> first place - Bluetooth > > Bluetooth btatt attributes have hf_fields, so them should not be PINos, > right? Bluetooth Attributes like "Age" have Age field. The issue is now clear > for me. Wireshark API do not require hf_fields to be registered when creating > protocol. There is a separated API to do that. In fact it is allowed is call > hf_field registered for one protocol in another protocol. So fields are > registered for btatt, but used but "attributes". It is historical behaviour > and can be changed (split fields). As I remember it is common behaviour, some > other dissectors have exported some dissection function. Maybe there is a > need to prohibit that? (detect at runtime like other conflicting hf_fields) > However in your case (PINOs) - there is still about XXX very simple Bluetooth > "protocols" (attributes). As long as there are hf_fields it is needed to > provide Enable/Disable any of that dissector. The goal for the Bluetooth: do > not remove any of feature - it is never good way (hide - it is much better > way) . The bulk of the Bluetooth "protocols" are "GATT Attributes": $ ./tshark -G protocols | wc -l 2216 $ ./tshark -G protocols | egrep Bluetooth | wc -l 477 $ ./tshark -G protocols | egrep Bluetooth | egrep -v 'GATT Attribute' | wc -l 50 so if you're suggesting making them *not* be protocols, that would help a *lot* here. That reduces it from ~20% to ~2%, and a quick look at the actual *protocols* registered by Bluetooth suggests that a lot of them actually deserved to be considered protocols. If you're *not* suggesting that, what needs to change in order to make them not be protocols? ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
