[Ethereal-dev] Re: Order of subdissectors : suggestion of a trick

[metatech <metatech@xxxxxxxxxxxxx>]

At 00:32 16/04/2004 -0500, you wrote:
> > > 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.

I wrote a small patch (about 20 lines in 3 files) to include the following 
"trick" :
The goal is that the "tcp.port" field is only matched for the server port, 
not for the client port.  The only moment when the client and server behave 
differently is during the TCP handshake : the client sends a SYN without 
ACK, what the server never does at any moment (I think).  For such a packet 
the destination is known to be the server.  At that moment the server port 
needs to be stored in a new field of the "tcp_analysis" struct (in 
packet-tcp) that holds a state of the TCP conversation.  If the server port 
is known by this trick, the dissector_try_port() is only called for the 
server port, otherwise the normal code is executed (lowest port chosen).

I think this makes things better in most cases.

Limitations :
- does not work if the capture was started after the TCP connection was 
started.
- might break a dissector that relies on the TCP port being a known value 
for the client (does such a thing exist ?)
- a small speed overhead to retrieve the TCP conversation state on each 
packet (actually this could be defined as a preference).

I will continue to test a bit the patch and submit it for feedback.  Any 
comment at the "design" phase ?

See you,

metatech