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