Martin Regner said:
> 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.
That's arguably a bug; matches with fewer wildcards should take preference
over matches with more wildcards, so that there's only one conversation
that matches.
> 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,.
Yes, but it's a bit more complicated to implement, given that we do
wildcard matches.
> I think that it maybe would be good to add some "priority" value that
> could be used to fine tune the order.
Yes.
> 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).
...but it gives fewer strange results, at least with the capture files I
have, than trying source port first or trying destination port first;
lower port numbers are more likely to be well-known ports or registered
ports.
The best way to handle the example you give is probably to have the
Diameter dissector reject packets that don't look like Diameter packets -
which it now does. (That's better than having it spew messages to the
standard output, which is what it used to do; the remaining "g_warning()"
calls should also be eliminated, in favor of stuff putting the "I can't
handle this part of the packet" indications into the protocol tree and
adding a new API to libethereal for reporting generic errors, along the
lines of "report_open_failure()" and "report_read_failure()", and using
that in the Diameter dissector - as well as in the "generic ASN.1"
dissector.)
> 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,
Actually, what we might want there is a way to have "Decode As..." specify
conversation dissectors, in addition to be able to specify dissectors for
specific port numbers, so that it'd
1) not be overridden by conversation dissectors (because it'd *be* the
dissector for that conversation)
and
2) apply only to that conversation
and also allow it to specify dissectors for circuits.
