["David Aggeler" <david_aggeler@xxxxxxxxxx>]

>> Explicit how? Dissectors do not always have to be registered with a table such as tcp.port.

For instance like this

static_dissector_add("tcp", dissect_dcm_static, "DICOM over TCP", "dicom_tcp", proto_dcm, tcp_port_range);
static_dissector_add("udp", dissect_dcm_static, "DICOM over UDP", "dicom_udp", proto_dcm, udp_port_range);

proto_dcm for me is just the umbrella, that can be linked to different layers.

>> Are you sure? sip_tcp and sip_udp are different heuristics dissectors, I presume that they can be disabled via the GUI as well.

Based the debugging of my own dissector, I'm quite convinced. I don't want to bash SIP. I'm just using it to illustrate my thoughts. Let's look at this:

sip_handle = register_dissector("sip", dissect_sip, proto_sip);
sip_tcp_handle = register_dissector("sip.tcp", dissect_sip_tcp, proto_sip);
...
dissector_add_uint_range_with_preference("udp.port", DEFAULT_SIP_PORT_RANGE, sip_handle);
dissector_add_uint_range_with_preference("tcp.port", DEFAULT_SIP_PORT_RANGE, sip_tcp_handle);
...
heur_dissector_add("udp", dissect_sip_heur, "SIP over UDP", "sip_udp", proto_sip, HEURISTIC_ENABLE);
heur_dissector_add("tcp", dissect_sip_tcp_heur, "SIP over TCP", "sip_tcp", proto_sip, HEURISTIC_ENABLE);
…

This results in 

[ ] SIP
    [ ] sip_tcp
    [ ] sip_udp
    [ ] sip_sctp ...

- Disabling only the parent "SIP", disables BOTH STATIC ones 'dissector_add_uint_range_with_preference' udp.port & tcp.port, but leaves the heuristic ones in place
- Disabling only sip_tcp/sip_udp disables the respective heur_dissector_add() only. The two static port remain in place.

>> So when would you like to enable all heuristics dissectors, for all protocols, but not enable the "static" dissector (as done by Enable/Disable All)?

More the other way around. I want to disable all heuristic ones but keep the static ones in place. 
Mindset wise, predictability means a lot to me. So from a performance perspective, it always going to behave equally slow/fast. if I have the static ones enables, but the heuristic ones not, I don't expect different behavior between two captures on the same equipment. Ports won't change too much, payload may quite a bit.

Regards
David

-----Original Message-----
From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Peter Wu
Sent: Friday, March 23, 2018 12:36
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] heur_dissector_add()

On Fri, Mar 23, 2018 at 09:07:58AM +0100, David Aggeler wrote:
> Hi Peter,
> 
> >> "DICOM on any TCP port" sounds more logical for a single protocol, 
> >> but there are actually protocols that run on other transports. One example is SIP which has "SIP over SCTP", "SIP over TURN", "SIP over TCP" and "SIP over UDO".
> 
> "SIP over TCP" / "SIP over UDP" are done the same ways as the DICOM is done. So it's not all bindings I agree, but many.
> Therefore let's focus on IP based protocols for a moment. To me
> 
> protocolx_over_tcp_static 		should be different to 
> protocolx_over_tcp_heuristic
> 
> A) In my understanding, the TCP static binding is done with the following line. Here I cannot specify a name.
> This is borderline questionable, because it’s a UI preference function.
> 
> 	dissector_add_uint_range_with_preference("tcp.port", 
> DICOM_DEFAULT_RANGE, dcm_handle);

Seems correct, the protocol name is taken from the handle which was returned by register_dissector or something like that.

> B) The TCP heuristic binding is done with
> 
> 	heur_dissector_add()
> 
> 
> Is my understanding of A) correct? If yes, I'd prefer it more explicit. If no, what am I missing on the static assignment? 

Explicit how? Dissectors do not always have to be registered with a table such as tcp.port. For example, the "data" dissector is looked up by dissectors using find_dissector("data") and then used directly.
That's likely why registration of dissectors is separate from linking them to something like tcp.port.

> With the currently implementation I cannot disable "SIP over TCP", but keep "SIP over UDP" on.

Are you sure? sip_tcp and sip_udp are different heuristics dissectors, I presume that they can be disabled via the GUI as well.

> Form a tree perspective, the following would make sense. And toggling the parent should toggle the children.
> 
> [ ] ProtocolX 
>       [ ] ProtocolX over TCP (static)
>       [ ] ProtocolX over TCP (heuristic)

I agree it would make more sense. For single protocols, there would just be a single item (which could be just heuristics or "static"). For protocols with multiple registrations, a tree would be visible.

Perhaps it could even append a comment to the protocol ("1 heuristics dissector hidden") in case a search query is active. Or maybe even display all subtree items since you are probably looking for a protocol rather than a specific instance.

> >> Do you think it is sufficient to append "(heuristic)" automatically in the GUI after each description?
> 
> If my understanding of A) is correct, then yes, this comes pretty close to the original idea in the 2015 discussion thread.

I guess you are referring to this "Enabling/disabling ANY heuristic dissector" discussion?
https://www.wireshark.org/lists/wireshark-dev/201507/msg00027.html

> It's not a single flag but better than nothing. Two buttons to 'Enable/Disable all heuristic at once'  would pretty much be that part. Or better 'Enable/Disable Visible'. Then with keyword, one can filter first and disable / enable that subset.

So when would you like to enable all heuristics dissectors, for all protocols, but not enable the "static" dissector (as done by Enable/Disable All)? "Enable/Disable all visible" sounds reasonable, but perhaps we can do better. Do you have a use case in mind?

Kind regards,
Peter
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe