Re: Protocols vs dissectors, take 23

[Michal Labedzki <michal.labedzki () tieto com>]

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

> 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

___________________________________________________________________________
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