On Tue, Jun 03, 2003 at 10:21:04AM +0200, Lambrecht Joris wrote:
> Thus i assume Protocol decoding is linear and will not revert to a
> not-so-close-match after failing the first match ?
Protocol decoding is dependent on the way the particular dissector is
written.
The TCP dissector, for example, first checks whether the conversation
(TCP connection, in the case of TCP) has had a dissector associated with
it (by some other dissector); if so, it calls that one.
If that fails, it checks whether the lower of the source and destination
port numbers has a dissector associated with it; if so, that dissector is
called.
If that fails, it checks whether the higher of the source and
destination port numbers has a dissector associated with it; if so, that
dissector is called.
If that fails, it tries the heuristic dissectors, in whatever order they
happened to be registered; if any of them succeed, it stops.
If that fails, it just decodes the payload as data.
It is possible for a port-number-based dissector to reject a packet as
not being a packet for that protocol; the mechanism for doing that
currently isn't documented, as I'm not certain it should work the way it
currently does. That is similar to a heuristic dissector, and has
similar problems - either the check can be too strict, and reject
packets that are packets for the protocol, or too loose, and accept
packets that are *not* packets for the protocol.
> Although identifying a protocol simply by port-assignment seems
> pretty lame to me, certainly not what i would expect from a project like
> Ethereal wich counts quite a lot of contributors.
Well, fortunately, it's not what we do. See above.
The Zebra dissector doesn't currently happen to reject packets that
don't look like valid Zebra packets. It could, conceivably, reject any
packet that doesn't have a known command code, although that has the
risk that if a future extension to Zebra adds new commands, packets with
those commands won't be recognized as Zebra packets, and it might be
less obvious that the dissector needs to be updated. It also has the
risk that packets from a buggy Zebra implementation might not be
recognized as Zebra packets.
Another possibility would be to check the heuristic dissectors before
checking the port-based dissectors; as long as all the heuristic
dissectors have heuristics that are strong enough not to incorrectly
accept too many packets, that might be OK.
Determining the protocol for packets running over transport-layer
protocols is not always easy, and a perfect solution might well be
impossible.
