Re: heur_dissector_add()

["David Aggeler" <david_aggeler () hispeed ch>]

> > 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 () wireshark org> On Behalf Of Peter Wu
Sent: Friday, March 23, 2018 12:36
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 () 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