["Guy Harris" <gharris@xxxxxxxxx>]

Lars Ruoff said:
> This question is with regard to priorities of the various sub-dissection
> mechanisms:
> For clarity, let me define the different sub-dissection mechanism as: -
> "parent": subdissection based on info or preferences in the parent
> (lower level) protocol. (for example IP -> UDP)
> - "user": as choosen by the user in Decode As...
> - "session": dissection based on session protocols, such as for example
> RTP conversations initiated by H.225 etc.
>   (is this handled with "conversations"?)
> - "heuristic".
>
> As i see it, the order in which these subdissections are tried out is:
> parent, session, user, heuristic.

Those mechanisms don't really exist in that fashion in the code.

The handoff mechanisms that exist are:

    explicitly calling a specific dissector ("call_dissector()");

    handoff based on, typically, a field in the packet
("dissector_try_port()", "dissector_try_string()");

    handoff to the dissector for the conversation
("try_conversation_dissector()");

    handoff to a heuristic dissector, if it matches
("dissector_try_heuristic()").

IP->UDP is handoff based on a field in the packet, i.e. it's done with
"dissector_try_port()".  ("port" in that name is historical.  We should
perhaps rename it to "dissector_try_uint()", to match
"dissector_try_string()".)  Most of the cases you're referring to as
"parent" are probably either explicit calls to a specific dissector (where
protocol X always hands off to protocol Y if it hands off to anything at
all, for example) or handoff based on a field in the packet.

"Dissect As" is handoff based on a field in the packet - the user
explicitly says "this value for this field - this Ethernet type, this IP
protocol number, or this TCP or UDP port number -  should be dissected
with this dissector" - so it's the same thing as "parent".

> (I'm not sure about the "parent", but thats not available on for example
> the UDP layer anyway, see below)

As per the above, "parent" is what's done for the UDP port number.

The order in which stuff is done depends on the dissector.  For the UDP
dissector, it's done in "decode_udp_ports()", which, in order:

    tries the conversation dissector first ("try_conversation_dissector()");

    tries heuristic dissectors if the "try heuristic sub-dissectors first"
preference - the long description for which is "Try to decode a packet
using an heuristic sub-dissector before using a sub-dissector
registered to a specific port" - is set;

    tries a lookup based on the numerically lower of the source and
destination port numbers, if that's not 0;

    tries a lookup based on the numerically higher of the source and
destination port numbers, if that's not 0;

    tries heuristic dissector if the "try heuristic sub-dissectors first"
preference is not set.

> Now, the question i ask myself is if "user" shouldnt have the highest
> priority?

Perhaps it should - but, as "user" is just implemented as a
protocol-field-based dissection, that's unimplementable, as it's
indistinguishable from a dissector-specified (at registration time)
association of field value and protocol.

> For example: i wanted to force decoding of some channel to T.38 (because
> it WAS T.38 at some point).

If I remember correctly, that's a special case, as a particular
conversation *changes* its protocol over time.

> If you choose "try heuristic dissectors first" in UDP preferences,
> before what will the heuristics come?

See above.