Wireshark · Ethereal-users: Re: [Ethereal-users] Possible Protocol Mismatch

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

Joris Lambrecht wrote:
>I've managed to decode the packets by selecting 'TCP Stream', this seems to
>be the same type of content as a TDS wich has been decoded without any
>problem. I must confess this is pretty confusing.

I'm not sure what you mean with TDS in this case. Do you mean "Tabular Data Stream" (MS SQL)?

The TDS/NetLib dissector is a heuristic dissector that looks on the data in the packets to see if 
it looks like a TDS/NetLib packet. The TDS dissector may also set up something called "conversations" so that packets 
coming on the same TCP connection may be dissected with the TDS/NetLib dissector.

The TDS/NetLib dissector doesn't register any port numbers at all.

>Why are packets with the same source:destination port decoded differently ?

Do you really mean that some packets with a certain source-port and dest-port combination are dissected
as Zebra and some packets with the same combination of source-port and dest-port are dissected as another
protocol (TDS?). That seems strange in this case since I think that all packets to or from port 2600 will be dissected 
by the Zebra dissector with only a few exceptions:
-if there is a "conversation" to which the packet belongs
-if the packet has already been claimed by another non-heuristic protocol dissector (this may happen
if the other port number has a lower numeric value and another protocol dissector has registered that port number).

A TDS packet sent to or from portnumber 2600 will normally be dissected by the Zebra dissector, since heuristic dissectors
will not get the chance to dissect packets that are claimed by a non-huristic dissector (based on port numbers) 
or claimed by another heuristic dissector that is called before that specific dissector.

The same TDS packet sent on another port number may be dissected by the TDS dissector, or maybe by another protcol
dissector. 

Unfortuantely you'll probably have to disable the Zebra protocol to get a TDS packet dissected as TDS if its sent to or from port number 2600 (and the packets also needs to match the heuristics implemented in the TDS dissector).

In some other cases it may be possible to use the "Tools/Decode As..." functionality, but the TDS/NetLib protocol is non in the list
of available protocols to choose between for "Decode As.." since it's a heuristic dissector only. 

In some cases there are both heuristic and non-heursitic dissectors for the same protocol. This may be good in certain scenarios.
For certain protocols it may be difficult or impossible to make a good heuristic dissector.

A non-heursitic dissector may also look on the packet content to make certain checks if the packet really looks e.g. like Zebra protocol, and if that is not the case it could indicate this in a certain way so that Ethereal can try with other dissectors.
However the Zebra dissector doesn't currently reject any packets what I could see, but there are several other non-heuristic dissectors that does this. Maybe it is possible to improve the Zebra dissector to do certain checks.

However different users may want different behaviour and how to handle this best may vary from protocol to protocol. 
For example if you are developping a Zebra program/product you may want to dissect packets on TCP port 2600 as a
Zebra protocol even if the packets are malformed, but other users may only want packets that most likely are Zebra
packets dissected by the Zebra dissector.
In some cases it could be good to add protocol preferences so that the user may control how to handle malformed
frames. 

Some protocol dissectors have preference settings for port numbers, but in most dissectors the port numbers are
hardcoded. I think it's good to have the port numbers configurable at least if the port number isn't a port number that
is almost only used for a specific protocol, e.g. well-know port numbers in the range 1-1023.

Guy Harris explained some weeks ago in what order Etheral calls different dissectors for a certain TCP packet.
Below is an extract from his mail:

<checks to see if there's a conversation to which the packet
<belongs and, if so, whether that conversation has a dissector
<associated with it - if so, that dissector is called;
<
<otherwise, checks whether there's a dissector associated with
<the numerically lower port number in the TCP header - if so,
<that dissector is called;
<
<otherwise, checks whether there's a dissector associated with
<the numerically higher port number in the TCP header - if so,
<that dissector is called;
<
<otherwise, checks the heuristic dissectors for TCP - if one is
<found, and it doesn't reject the packet, it's called.
<
<The heuristic dissectors are checked in whatever order they happen to
<appear in the table; this order is best thought of as random order
<(i.e., no heuristic dissector should rely on being before, or after,
<some other heuristic dissector).
<
<For dissectors, other than the TCP dissector, that have heuristic
<dissector tables, the exact sequence of checks might be different (*is*
<different, for at least some dissectors); the above sequence is just
<what the TCP dissector happens to do now, not what other dissectors do
<(or even what the TCP dissector will continue to do in the future - the
<above sequence might change, although I can't anticipate such a change
<right now).