[Michal Labedzki <michal.labedzki@xxxxxxxxx>]

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).

> That's a lot of real estate to take up for the many users that don't use Wireshark for Bluetooth.

Please forget now about Bluetooth. Please start thinking about USB. You are user of Wireshark, but only for USB. You see a lot of "Ethernet" protocols that are useless (please skip cases where USB meets Ethernet). It is enough to remove them?

In my opinion: you can do everything, but please do not break anything (like remove some functionality).

Please forget about Bluetooth again. If protocol ZZZ use separate dissection function and there are some hf_fields used, then you make it PINO, then some user that use Enable/Disable that "protocol" will cry. It is not my role to judge if they work in right way, but in past we can do it, currently it cannot do and start crying (and start searching for new tool :().

Summary:

1. If one dissector should may ability to use fields registered for other dissector?

2. How to handle a lot of very simple dissectors? (like Bluetooth's attributes [but not all are simple!!]) [example of very simple dissector [not only Bluetooth]: Age dissector, one FT_UINT32 field :)]

New hint:
"Protocols vs dissectors"

Protocols:

tcp

udp

btatt

btavrcp

Dissectors:

tcp (protocol)

udp (protocol)

btatt (protocol)

btavrcp (protocol)

png (file format)

xml (file format?)

logcat (log format)

exported_pdu (???)

Maybe there is a need to rename "View -> Enabled protocols" to "View -> Enable/Disable dissectors" and live with an infinity number of them.

--

	Pozdrawiam / Best regards ------------------------------------------------------------------------------------------------------------- Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN