["Martin Regner" <martin.regner@xxxxxxxxx>]

Lars Ruoff wrote:
> 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.
> (I'm not sure about the "parent", but thats not available on for example
the
> UDP layer anyway, see below)
>
> Is it that way?
> Now, the question i ask myself is if "user" shouldnt have the highest
> priority?
>
> For example: i wanted to force decoding of some channel to T.38 (because
it
> WAS T.38 at some point). However the channel was decoded as RTP by H.225.
> Doing a "Decode As.. T.38" will not change anything. You will have to
> disable H.225 in order to see the packets decoded as T.38.
> This is not very user-friendly at least.
>
> and in this same context:
> If you choose "try heuristic dissectors first" in UDP preferences, before
> what will the heuristics come?
>

Hi,

My previous mail was not an answer on the questions in your mail, but was
more related to the specific problem with RTP/T.38.

I think that the description below is more or less correct for UDP/TCP based
protocols.


1) If there is any conversation registered for the ip-address(es)/port(s)
combination then only that dissector  is called
============================================================================
=
It is not possible to have several protocols connected to a conversation,
currently.

There may in some cases be several conversation matching the same UDP/TCP
stream since you can
register a conversation with only one address/port. I'm not completely sure
about what dissector
will be called if a packet matches several conversations, but I'm quite sure
thantonly one will be called.

If you try to change the associated disector from RTP to T38 for a certain
conversation it may work for the Summary panel - but then when
you click on a packet it will be dissected by the dissector that is
currently associated with the conversation.
I think we later have to change the implementation so that "conversations"
are handled in a similar way
as "circuits", so that you can stop a conversation and start a new with same
ip-address/port combination,.

Then you would be able to handle the RTP/T38 problem, but I think that it
will be quite complicated.
I have started to think about it a bit, but...

If a dissector rejects a packet belonging to a conversation then the packet
will be decoded as "Data", i.e. Ethreal will not continue with
heuristic dissectors or based on port numbers. I made an experiment to
reject packets that didn't have RTP version bits set to 2,
but that didn't work without changing on some other places in th code.

2) Heuristic dissectors (but only if "Try heuristic dissectors first" is
checked in UDP preferences)
=================================================================
There is no specific order between different heuristic dissectors (except
for the order they are registered in the table).
A heuristic dissector may reject the packet and Ethereal will then continue
with the next heuristic dissector and so on.

3) According to the port-number table -  lowest port number of
source-port/dest-port
==========================================================
Here you have the "Decode As..." scenario and the scenario where a dissector
has
registered a specific port.
Only one dissector can currently be registered for a specific port number.
It is possible for the dissector to reject the packet so that Ethereal will
continue with step 4 (by using new_create_dissector_handle)

4) According to the port-number table -  highest port number of
source-port/dest-port
==========================================================
Here you have the "Decode As..." scenario and the scenario where a dissector
has
registered a specific port.
Only one dissector can currently be registered for a specific port number.
It is possible for the dissector to reject the packet so that Ethereal will
continue with step 5 (by using new_create_dissector_handle,
see e.g. dissect_aim).

5) Heuristic dissectors (if "Try heuristic dissectors first" is NOT checked
in UDP preferences)
=================================================================
There is no specific order between different heuristic dissectors.
A heuristic dissector may reject the packet and Ethereal will then continue
with the next heuristic dissector.



I think that it maybe would be good to add some "priority" value that could
be used to fine tune the order.
Some heuristic dissectors have very weak heuristics.
Some port numbers are used for several things. Lower port number has
priority over higher port number, which may
give strange results in some cases (a TCP connection from port 1812 to 5060
may be dissected as Diameter).

If we had a priority value for the dissector tables then it could maybe be
possible to specify "Decode As..." T.38
with a priority that is higher than conversations, or to specify that you
want to decode UDP port number 5000, 5002, 5004 ...
 as RTP with low priority.