Telnet session negotiation in Tesira

Session options

Tesira implements a Telnet server on port 23. When the request from the control system to open a session is received, the Tesira Telnet server attempts to negotiate the session’s options, following specifications described in the Telnet standard document RFC 854 as well as document RFC 855, Telnet Option Specifications.

A standard Telnet client would be able to negotiate the session options without problem, but several third-party controllers do not implement a Telnet client by default. Instead, they implement control over TCP/IP using what’s commonly known as a ‘RAW’ connection. If the Control System does not respond to the Telnet session options negotiations, the session will not go ahead. As such, the control system will have to be programmed to negotiate the Telnet options with Tesira’s Telnet server. Many of the available options can be useful during a control session and indeed a programmer may choose to enable some of them, but if the desire is to continue using a ‘RAW’ connection, the simplest way to initiate a control session is for the control system to respond with a rejection to any option negotiation request from the server.

Negotiation

The best way to understand the Telnet options negotiation procedure is by looking at the data in Hex format therefore it will be explained using this format. Notation will be “0xFF” for Hex character FF.

The Telnet commands we are concerned with are always three bytes long. The first is the Interpret As Command (IAC) character, and it is always 0xFF. The second character is the Command and the last character is the Option being negotiated.

Commands Can be			Negotiated Options can be *
WILL	0xFB		Binary Transmission	0x00
DO	0xFD		Echo	0x01
DON’T	0xFE		Suppress Go Ahead	0x03
WON’T	0xFC		Status	0x05
			Terminal Type	0x18
* Not limited to - There are many different Telnet options in existence; a master list is maintained by IANA - http://www.iana.org/assignments/telnet-options

The control system needs to react to any incoming string that begins with 0xFF, and decide whether the option is desired or not. If the intent is to control Tesira using a ‘raw’ connection, all that’s required is to always reject the option negotiation. If Tesira sends a “WILL” Command, the control system shall respond with “DON’T”and if Tesira sends a “DO”, the response should be “WON’T”. The Option byte needs to be returned as received. In essence, the mechanism is as follows:

 

When the server sends:	0xFF	WILL	<byte X>
The control system responds with:	0xFF	DON’T	<byte X>

When the server sends:	0xFF	DO	<byte X>
The control system responds with:	0xFF	WON’T	<byte X>

For example:

When the server sends:	0xFF	0xFD	0x01	(Do Echo)
The control system responds with:	0xFF	0xFC	0x01	(Won’t Echo).

Or:

When the server sends:	0xFF	0xFB	0x03	(Will Suppress Go Ahead)
The control system responds with:	0xFF	0xFE	0x03	(Don’t Suppress Go Ahead)

Once all options are negotiated, the Tesira server will send the message “Welcome to the Tesira Text Protocol Server”, preceded and followed by 0x0D and 0x0A. The control system is now free to send TTP commands.