Re: Protocols vs dissectors, take 23

[Michael Mann <mmann78 () netscape net>]

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 <guy () alum mit edu>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 <michal.labedzki () tieto com> wrote:

> On 2 January 2017 at 03:13, Michael Mann <mmann78 () netscape net> 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 <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe