Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Protocols vs dissectors, take 23

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 5 Jan 2017 17:00:36 -0800
On Jan 1, 2017, at 11:39 PM, Michal Labedzki <michal.labedzki@xxxxxxxxx> wrote:

> On 2 January 2017 at 03:13, Michael Mann <mmann78@xxxxxxxxxxxx> 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?