[Guy Harris <guy@xxxxxxxxxx>]

> But unfortunatly the RFB protocol (which VNC uses, you can the        
> complete description of this protocol at                              
> :www.uk.research.att.com/vnc/rfbproto.pdf) doesn't use neither        
> "\r\n.\r\n" nor ".\r\n".                                              
> (not even in octal). But maybe is it because it sends only shorts     
> messages...
>   So I'll read further more smpt protocol tonight to see how I could
> situate, into practice,
> one packet with regard to an other one.

>From a quick look at

	http://www.uk.research.att.com/vnc/rfbproto.pdf

RFB isn't a text-based line-oriented protocol, so the SMTP protocol
specification (RFC 821) and the SMTP dissector won't help you.

Not all protocols running atop TCP are the same; reading a dissector of
one TCP-based protocol won't necessarily help you at all when trying to
write a dissector for a different protocol.

*Some* of it might help, as it appears that the initial handshaking
messages don't contain any message type field; instead it appears that
the first few messages are sent in a particular order, i.e.:

	the server sends a ProtocolVersion message, which is always 12
	bytes long;

	the client sends a ProtocolVersion message;

	the server then sends an Authentication message, which contains
	4 bytes of authentication scheme followed by a variable amount
	of data - the amount of data depends on the authentication
	scheme value;

	the client then sends a ClientInitialisation message, which
	contains 1 byte of "shared-flag" (a Boolean);

	the server then sends a ServerInitialisation message, which has
	some fixed-length fields, the last of which is the length of the
	remaining variable-length field.

To dissect that part, you would, unfortunately, need to know when a
connection is created.  Currently, Ethereal's connection-oriented
dissectors don't supply that information to dissectors running atop
them; they probably should.

If that information were supplied, the dissector would keep state
information for the current conversation (in the same way the SMTP
dissector does).

If the TCP dissector indicated that a new connection (as opposed to a
connection that already existed at the time when you started capturing
traffic) had appeared, you'd set the state to something such as
"EXPECTING_PROTOCOL_VERSION".  In that state, the dissector would check
for data beginning with "RFB ".  If it saw that coming from the server
to the client, it would be the server ProtocolVersion message, and would
change the state to "EXPECTING_CLIENT_PROTOCOL_VERSION"; if it saw it
coming from the client to the server, it presumably means the
server-to-client message wasn't seen, and would then enter the
EXPECTING_AUTHENTICATION state.

In the EXPECTING_CLIENT_PROTOCOL_VERSION state, if the dissector saw a
ProtocolVersion message from the client to the server, it'd enter the
EXPECTING_AUTHENTICATION state.

In the EXPECTING_AUTHENTICATION state, the next server-to-client message
would be dissected as an Authentication message, and the dissector would
enter the EXPECTING_CLIENT_INITIALISATION message.

In the EXPECTING_CLIENT_INITIALISATION state, the next client-to-server
message would be dissected as a ClientInitialisation message, and the
disector would enter the EXPECTING_SERVER_INITIALISATION state.

In the EXPECTING_SERVER_INITIALISATION state, the next server-to-client
message would be dissected as a ServerInitialisation message, and the
dissector would enter the INITIALISED state.

All subsequent messages, it appears, being with a 1-byte message type;
the length of the rest of the message depends on the message type, and
there might also be length fields in the message specifying the length
of other items in the message.

So, in the INITIALISED state, the dissector would look for the message
type, and dissect the message based on that.

Note, however, that this state information will work *ONLY* on the first
sequential pass through a capture.  Once the capture file has been read
in, the user could click on a ServerInitialisation message, and then
click on the first ProtocolVersion message, and then click on some
regular message in the middle of the capture, and then click on the
ClientInitialisation message....

Therefore, you would have to associate with the frames containing each
of the initial handshaking message some per-frame data indicating the
type of the message in that frame, and use *that* to decide how to
dissect that frame.