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

Guy Harris wrote:
> 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.

It may be that I'm not completely correct, or that � wasn't clear.

I mean that there could maybe be one conversation for
1.1.1.3:5555<===>x.x.x.x:yyyy
and one for 1.1.1.8:6666<=====>z.z.z.z:pppp.

A packet with 1.1.1.3:5555====>1.1.1.8:6666 would "match" both these
conversations,
but Ethereal will consider the packet to belong to just one conversation
according to some
priority scheme I guess. It was a while since I looked into the conversation
code.

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

Yes, I think it will be really complicated. I think that it will be really
really complicted to use the conversation
mechanism in a good way from SDP/H245 dissectors. There may actually both
SIP/SDP+ Megaco/SDP+H225/H245
signalling setting up the same RTP/T.38 stream.

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

In agree that it is often working well, especially for port numbers in the
range 1-1023.
But I have seen several cases where it is not working so well. It is quite
often
you get a low port number on TCP client side.
A priority scheme could be good to improve the behaviour.

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

Bad example from my part. The Diameter dissector *was* a problem earlier.

There are not so many dissectors that rejects packets currently. I think
that it
would be good to improve that in the future. As you said in the other mail
we maybe want to use another mechanism for rejecting packets, so that
we can add rejection to other disectors.

Then there is also another issue and that is that the rejection may need to
be
configurable since different users have different needs (a malformed packet
should maybe be decoded as a malformed for one user, but not for another
user).
Some dissectors have preference settings alerady.

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

Yes that would maybe be a good idea. But in some cases you could want to
have Decode As with
low priority, i.e. to decode all UDP ports in range 5000, 5002, 5004 .... as
RTP if they are not matching
a heuristic dissector.
This is probably not relevant right now, but if it would be possible to
store Decode As settings in a file, then
I think that a priority scheme would be good.

I have been thinking of some improvements to Decode As..
-store "Decode As.." parameters in file
-priority settings (e.g. high: maybe as conversation, medium: before
heuristic dissectors, low: after heuristic disectors)
-providing support e.g. for decoding rtp.payload  98 as rtpevents (similar
as already available in tethereal with -d option)
-...


Below is the preliminar notes I have made about Decode As...




Decode As.. in Ethereal
========================

* It should be possible to define Decode As... in a similar ways as from
tethereal not just for
udp.port, tcp.port
but also for
rtp.payload, and so on

The GUI needs to be updates so that you can select the right things (all
possible tables).

Table            Value           Inital    Current     Active    Priority
rtp.payload      98                        rtpevents   Yes       Medium
udp.port         32800                     rtp         Yes       Low
udp.port         32801                     rtcp        No        Low
udp.port         32802                     rtp         Yes       Low
h245.nsp.object  1.71.20.23                nstd71      Yes       Medium


* It should be possible to Save the Decode As settings to file and read from
a file.
Maybe this should be handled similar to Color Filters
(Save/Revert/Export.../Import...).


* It could be good to be able to list not just the entries related to user
defined decodes,
but also being abe to view the hardcoded entries (e.g. by checking a
checkbox or similar):

Table         Value         Protocol
tcp.port      1812          diameter
tcp.port      5190          aim


* Maybe it should be possible to specify a priority (High, Medium, Low) that
could be used to
decide if heuristic dissection shall be performed after or before that
specific protocol, and
also maybe also when deciding in what order to dissect if there is one
protcol registered for the source port
and one for the destination port.

* It would be good to have the ability to temporarily disable some entries.
One way could be to have a field Active=Yes/No so that it is easy to switch.


Decode As... in Tethereal
=========================

* It should be possible to tell tethereal to load "decode as" information
from a specific file.
  The file format should be the same as used i Ethereal.
  A new option should be used to specify what file to use, e.g. something
like the "-E" option below.
  <tethereal -r myfile.pcap -E C:/MyConf/myvoip_decode.das -V


* If no filename has been specified with the new option the default file
will be read if
  it exists. This is the same file as Ethereal will read when starting up.

* It should still be possible to use "-d" option e.g. to add or overwrite
the settings in the file.
  <tethereal -r myfile.pcap -E C:/MyConf/myvoip_decode.das -d
tcp.port,1312,t38 -d tcp.port,1314,t38,prio_high -V