Telnet - What is the Network Virtual Terminal?
The Telnet protocol is often thought of as simply providing a facility for remote logins to computer via the Internet. This was its original purpose although it can be used for many other purposes.
It is best understood in the context of a user with a simple terminal using the local telnet program (known as the client program) to run a login session on a remote computer where his communications needs are handled by a telnet server program. It should be emphasised that the telnet server can pass on the data it has received from the client to many other types of process including a remote login server. It is described in RFC854 and was first published in 1983.
The Network Virtual Terminal
Communication is established using the TCP/IP protocols and communication is based on a set of facilities known as a Network Virtual Terminal (NVT). At the user or client end the telnet client program is responsible for mapping incoming NVT codes to the actual codes needed to operate the user's display device and is also responsible for mapping user generated keyboard sequences into NVT sequences.
The NVT uses 7 bit codes for characters, the display device, referred to as a printer in the RFC, is only required to display the "standard" printing ASCII characters represented by 7 bit codes and to recognise and process certain control codes. The 7 bit characters are transmitted as 8 bit bytes with most significant bit set to zero. An end-of-line is transmitted as the character sequence CR (carriage return) followed by LF (line feed). If it is desired to transmit an actual carriage return this is transmitted as a carriage return followed by a NUL (all bits zero) character.
NVT ASCII is used by many other Internet protocols.
The following control codes are required to be understood by the Network Virtual Terminal.
| Name | code | Decimal Value | Function |
|---|---|---|---|
| NULL | NUL | 0 | No operation |
| Line Feed | LF | 10 | Moves the printer to the next print line, keeping the same horizontal position. |
| Carriage Return | CR | 13 | Moves the printer to the left margin of the current line. |
The following further control codes are optional but should have the indicated defined effect on the display.
| Name | code | Decimal Value | Function |
|---|---|---|---|
| BELL | BEL | 7 | Produces an audible or visible signal (which does NOT move the print head. |
| Back Space | BS | 8 | Moves the print head one character position towards the left margin. [On a printing devices this mechanism was commonly used to form composite characters by printing two basic characters on top of each other.] |
| Horizontal Tab | HT | 9 | Moves the printer to the next horizontal tab stop. It remains unspecified how either party determines or establishes where such tab stops are located. |
| Vertical Tab | VT | 11 | Moves the printer to the next vertical tab stop. It remains unspecified how either party determines or establishes where such tab stops are located. |
| Form Feed | FF | 12 | Moves the printer to the top of the next page, keeping the same horizontal position. [On visual displays this commonly clears the screen and moves the cursor to the top left corner.] |
The NVT keyboard is specified as being capable of generating all 128 ASCII codes by using keys, key combinations or key sequences.
Commands
The telnet protocol also specifies various commands that control the method and various details of the interaction between the client and server. These commands are incorporated within the data stream. The commands are distinguished by the use of various characters with the most significant bit set. Commands are always introduced by a character with the decimal code 255 known as an Interpret as command (IAC) character. The complete set of special characters is
| Name | Decimal Code | Meaning |
|---|---|---|
| SE | 240 | End of subnegotiation parameters. |
| NOP | 241 | No operation |
| DM | 242 | Data mark. Indicates the position of a Synch event within the data stream. This should always be accompanied by a TCP urgent notification. |
| BRK | 243 | Break. Indicates that the "break" or "attention" key was hit. |
| IP | 244 | Suspend, interrupt or abort the process to which the NVT is connected. |
| AO | 245 | Abort output. Allows the current process to run to completion but do not send its output to the user. |
| AYT | 246 | Are you there. Send back to the NVT some visible evidence that the AYT was received. |
| EC | 247 | Erase character. The receiver should delete the last preceding undeleted character from the data stream. |
| EL | 248 | Erase line. Delete characters from the data stream back to but not including the previous CRLF. |
| GA | 249 | Go ahead. Used, under certain circumstances, to tell the other end that it can transmit. |
| SB | 250 | Subnegotiation of the indicated option follows. |
| WILL | 251 | Indicates the desire to begin performing, or confirmation that you are now performing, the indicated option. |
| WONT | 252 | Indicates the refusal to perform, or continue performing, the indicated option. |
| DO | 253 | Indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option. |
| DONT | 254 | Indicates the demand that the other party stop performing, or confirmation that you are no longer expecting the other party to perform, the indicated option. |
| IAC | 255 | Interpret as command |
There are a variety of options that can be negotiated between a telnet client and server using commands at any stage during the connection.
Common Telnet options:
| Decimal code | Option Name | RFC |
|---|---|---|
| 0 | Transmit Binary | 856 |
| 1 | Echo | 857 |
| 3 | Suppress Go Ahead | 858 |
| 5 | Status | 859 |
| 6 | Timing Mark | 860 |
| 24 | Terminal Type | 1091 |
| 31 | Window Size | 1073 |
| 32 | Terminal Speed | 1079 |
| 33 | Remote Flow Control | 1372 |
| 34 | Linemode | 1184 |
| 36 | Environment Variables | 1408 |
All Telnet options:
| Decimal Code | Option Name | RFC |
|---|---|---|
| 0 | Transmit Binary | 856 |
| 1 | Echo | 857 |
| 2 | Reconnection | |
| 3 | Suppress Go Ahead | 858 |
| 4 | Approx Message Size Negotiation. | |
| 5 | Status | 859 |
| 6 | Timing Mark | 860 |
| 7 | Remote Controlled Trans and Echo | 563, 726 |
| 8 | Output Line Width | |
| 9 | Output Page Size | |
| 10 | Negotiate About Output Carriage-Return Disposition | 652 |
| 11 | Negotiate About Output Horizontal Tabstops | 653 |
| 12 | NAOHTD, Negotiate About Output Horizontal Tab Disposition | 654 |
| 13 | Negotiate About Output Formfeed Disposition | 655 |
| 14 | Negotiate About Vertical Tabstops | 656 |
| 15 | Negotiate About Output Vertcial Tab Disposition | 657 |
| 16 | Negotiate About Output Linefeed Disposition | 658 |
| 17 | Extended ASCII. | 698 |
| 18 | Logout. | 727 |
| 19 | Byte Macro | 735 |
| 20 | Data Entry Terminal | 732,1043 |
| 21 | SUPDUP | 734, 736 |
| 22 | SUPDUP Output | 749 |
| 23 | Send Location | 779 |
| 24 | Terminal Type | 1091 |
| 25 | End of Record | 885 |
| 26 | TACACS User Identification | 927 |
| 27 | Output Marking | 933 |
| 28 | TTYLOC, Terminal Location Number. | 946 |
| 29 | Telnet 3270 Regime | 1041 |
| 30 | X.3 PAD. | 1053 |
| 31 | NAWS, Negotiate About Window Size. | 1073 |
| 32 | Terminal Speed | 1079 |
| 33 | Remote Flow Control | 1372 |
| 34 | Linemode | 1184 |
| 35 | X Display Location. | 1096 |
| 36 | Environment | 1408 |
| 37 | Authentication | 1416, 2941, 2942, 2943,2951 |
| 38 | Encryption Option | 2946 |
| 39 | New Environment | 1572 |
| 40 | TN3270E | 2355 |
| 41 | XAUTH | |
| 42 | CHARSET | 2066 |
| 43 | RSP, Telnet Remote Serial Port | |
| 44 | Com Port Control | 2217 |
| 45 | Telnet Suppress Local Echo | |
| 46 | Telnet Start TLS | |
| 47 | KERMIT | 2840 |
| 48 | SEND-URL | |
| 49 | FORWARD_X | |
| 50 - 137 | ||
| 138 | TELOPT PRAGMA LOGON | |
| 139 | TELOPT SSPI LOGON | |
| 140 | TELOPT PRAGMA HEARTBEAT | |
| 141 - 254 | ||
| 255 | Extended-Options-List | RFC 861 |
Options are agreed by a process of negotiation which results in the client and server having a common view of various extra capabilities that affect the interchange and the operation of applications.
Either end of a telnet dialogue can enable or disable an option either locally or remotely. The initiator sends a 3 byte command of the form
IAC,,
The response is of the same form.
Operation is one of
| Description | Decimal Code | Action |
| WILL | 251 | Sender wants to do something. |
| WONT | 252 | Sender doesn't want to do something. |
| DO | 253 | Sender wants the other end to do something. |
| DONT | 254 | Sender wants the other not to do something. |
Associated with each of the these there are various possible responses
| Sender Sent | Receiver Responds | Implication |
| WILL | DO | The sender would like to use a certain facility if the receiver can handle it. Option is now in effect |
| WILL | DONT | Receiver says it cannot support the option. Option is not in effect. |
| DO | WILL | The sender says it can handle traffic from the sender if the sender wishes to use a certain option. Option is now in effect. |
| DO | WONT | Receiver says it cannot support the option. Option is not in effect. |
| WONT | DONT | Option disabled. DONT is only valid response. |
| DONT | WONT | Option disabled. WONT is only valid response. |
For example if the sender wants the other end to suppress go-ahead it would send the byte sequence
255(IAC),251(WILL),3
The final byte of the three byte sequence identifies the required action.
For some of the negotiable options values need to be communicated once support of the option has been agreed. This is done using sub-option negotiation. Values are communicated via an exchange of value query commands and responses in the following form.
IAC,SB,
and
IAC,SB,
For example if the client wishes to identify the terminal type to the server the following exchange might take place
Client 255(IAC),251(WILL),24 Server 255(IAC),253(DO),24 Server 255(IAC),250(SB),24,1,255(IAC),240(SE) Client 255(IAC),250(SB),24,0,'V','T','2','2','0',255(IAC),240(SE)
The first exchange establishes that terminal type (option number 24) will be handled, the server then enquires of the client what value it wishes to associate with the terminal type. The sequence SB,24,1 implies sub-option negotiation for option type 24, value required (1). The IAC,SE sequence indicates the end of this request. The repsonse IAC,SB,24,0,'V'... implies sub-option negotiation for option type 24, value supplied (0), the IAC,SE sequence indicates the end of the response (and the supplied value).
The encoding of the value is specific to the option but a sequence of characters, as shown above, is common.
Telnet Negotiable Options
Many of those listed are self-evident, but some call for more comments.
- Suppress Go Ahead
The original telnet implementation defaulted to "half duplex" operation. This means that data traffic could only go in one direction at a time and specific action is required to indicate the end of traffic in one direction and that traffic may now start in the other direction. [This similar to the use of "roger" and "over" by amateur and CB radio operators.] The specific action is the inclusion of a GA character in the data stream.
Modern links normally allow bi-directional operation and the "suppress go ahead" option is enabled.
- echo
The echo option is enabled, usually by the server, to indicate that the server will echo every character it receives. A combination of "suppress go ahead" and "echo" is called character at a time mode meaning that each character is separately transmitted and echoed.
There is an understanding known as kludge line mode which means that if either "suppress go ahead" or "echo" is enabled but not both then telnet operates in line at a time mode meaning that complete lines are assembled at each end and transmitted in one "go".
- linemode
This option replaces and supersedes the line mode kludge.
- remote flow control
This option controls where the special flow control effects of Ctrl-S/Ctrl-Q are implemented.
Telnet control functions
The telnet protocol includes a number of control functions. These are initiated in response to conditions detected by the client (usually certain special keys or key combinations) or server. The detected condition causes a special character to be incorporated in the data stream.
- Interrupt Process
This is used by the client to cause the suspension or termination of the server process. Typically the user types Ctrl-C on the keyboard. An IP (244) character is included in the data stream.
- Abort Output
This is used to suppress the transmission of remote process output. An AO (238) character is included in the data stream.
- Are You There
This is used to trigger a visible response from the other end to confirm the operation of the link and the remote process. An AYT (246) character is incorporated in the data stream.
- Erase character
Sent to the display to tell it to delete the immediately preceding character from the display. An EC (247) character is incorporated in the data stream.
- Erase line
Causes the deletion of the current line of input. An EL (248) character is incorporated in the data stream.
- Data Mark
Some control functions such as AO and IP require immediate action and this may cause difficulties if data is held in buffers awaiting input requests from a (possibly misbehaving) remote process. To overcome this problem a DM (242) character is sent in a TCP Urgent segment, this tells the receiver to examine the data stream for "interesting" characters such as IP, AO and AYT. This is known as the telnet synch mechanism.
A DM not in a TCP Urgent segment has no effect.
For more information, see the Telnet Protocol Revisited
For the server to find out if a client supports the telnet
protocol at all, one good approach is to a simple, commonly
used telnet command to the client. If the client reacts
conform to the protocol (or sends telnet commands itself), the
server can continue to negotiate further options. If the client
does not react, the server can safely refrain from further
negotiations.
The following list is a more or less comprehensive overview of
the telnet related RFCs (available for example on
http://www.faqs.org/rfcs):
RFC Titel rel. Code
495 TELNET Protocol Specification
513 Comments on the new TELNET specifications
559 Comments on the new TELNET Protocol and its Implem
595 Some Thoughts in Defense of the TELNET Go-Ahead
596 Second Thoughts on Telnet Go-Ahead
652 Telnet Output Carriage-Return Disposition Option NAOCRD 10
653 Telnet Output Horizontal Tabstops Option NAOHTS 11
654 Telnet Output Horizontal Tab Disposition Option NAOHTD 12
655 Telnet Output Formfeed Disposition Option NAOFFD 13
656 Telnet Output Vertical Tabstops Option NAOVTS 14
657 Telnet Output Vertical Tab Disposition Option NAOVTD 15
658 Telnet Output Linefeed Disposition NAOLFD 16
698 Telnet Extended Ascii Option X-ASCII 17
727 Telnet Logout Option LOGOUT 18
728 A Minor Pitfall in the Telnet Protocol
735 Revised TELNET Byte Macro Option BM 19
749 Telnet SUPDUP-OUTPUT Option SUPDUP 22
764 Telnet Protocol Specification
779 Telnet SEND-LOCATION Option SENDLOC 23
818 The Remote User Telnet Service
854 Telnet Protocol Specification
855 Telnet Option Specifications
856 Telnet Binary Transmission BINARY 0
857 Telnet Echo Option ECHO 1
858 Telnet Suppress Go Ahead Option SGA 3
859 Telnet Status Option STATUS 5
860 Telnet Timing Mark Option TM 6
861 Telnet Extended Options - List Option EXOPL 255
884 Telnet Terminal Type Option TTYPE 24
885 Telnet End of Record Option EOR 25
930 Telnet Terminal Type Option TTYPE 24
933 Output Marking Telnet Option OUTMRK 27
946 Telnet Terminal Location Number Option TTYLOC 28
1043 Telnet Data Entry Terminal Option DODIIS Implement DET 20
1053 Telnet X.3 PAD Option X.3-PAD 30
1073 Telnet Window Size Option NAWS 31
1079 Telnet Terminal Speed Option TSPEED 32
1080 Telnet Remote Flow Control Option FLOWCTRL 33
1091 Telnet Terminal-Type Option TTYPE 24
1096 Telnet X Display Location Option XDISPLOC 35
1116 Telnet Linemode Option LINEMODE 34
1143 The Q Method of Implementing TELNET Option Negotia
1184 Telnet Linemode Option LINEMODE 34
1372 Telnet Remote Flow Control Option FLOWCTRL 33
1408 Telnet Environment Option ENVIRON 36
1571 Telnet Environment Option Interoperability Issues
1572 Telnet Environment Option NEWENV 39
2066 Telnet Charset Option CHARSET 42
2217 Telnet Com Port Control Option COMPORT 44
2877 5250 Telnet Enhancements
All negotiations start with the special character IAC which is
defined in /usr/include/arpa/telnet.h (or in
src/driver/telnet.h for 3.2(.1)) and has the decimal value of
255. Negotiations are based on different telnetoptions (their
values are defined in telnet.h too). Before a negotiation can
start the client and the server have to agree that they
support the option.
This works in the following way:
If a client wants to send something to the server it has to
send 'IAC WILL option' (For terminaltype negotiation this would
be the 3 bytes 255,251,24; again, check telnet.h) to confirm
that it is able to do that. If the server is supporting that
option and wants to receive something it sends 'IAC DO option'
(255,253,option)
If one side is receiving an 'IAC WILL option' and has not yet
sent with DO or DONT it has to respond with either 'IAC DO
option' if it will support this negotiation or 'IAC DONT
option' if it won't.
If one side is receiving an 'IAC DO option' and has not yet
sent a WILL or WONT it has to reply with either 'IAC WILL
option' if it supports the option or 'IAC WONT option' if not.
A small example: Lets assume we want to negotiating
terminaltype. (TELOPT_TTYPE with value 24). client is the
telnet executable on the playerside, the server is the
gamedriver.
client server
IAC WILL TTYPE
IAC DO TTYPE
Or:
IAC DO TTYPE
IAC WILL TTYPE
After this we are ready to transfer the terminaltype from the
client to the server as explained below.
Now we are ready to start the real negotiations. I explain the
3 options I have currently implemented.
First TerminalType aka TTYPE aka 24 aka TELOPT_TTYPE assuming
the client and the server have exchanged WILL/DO.
The server is now free to send 'IAC SB TELOPT_TTYPE
TELQUAL_SEND IAC SE' which will be replied with 'IAC SB
TELOPT_TTYPE TELQUAL_IS terminaltype IAC SE' where
terminaltype is a non-zero terminated string (it's terminated
by the IAC) (For values look up telnet.h) AND switch the
client's terminalemulation to 'terminaltype'. terminaltype is
case-insensitive. terminal-type may be UNKNOWN. The server may
repeat the SEND request and the client will respond with the
next preferred terminaltype. If this is the same as the
previous received, it marks the end of the list of
terminaltypes. The next SEND request will start the
terminaltypes from the beginning.
Example: (we have exchanged WILL/DO already)
client server
IAC SB TTYPE SEND IAC SE
IAC SB TTYPE IS VT200 IAC SE
IAC SB TTYPE SEND IAC SE
IAC SB TTYPE IS VT100 IAC SE
IAC SB TTYPE SEND IAC SE
IAC SB TTYPE IS VT52 IAC SE
IAC SB TTYPE SEND IAC SE
IAC SB TTYPE IS VT52 IAC SE
/* this marks that we have all terminaltypes. We decide to use the
* vt200 mode so we have to skip to VT200
*/
IAC SB TTYPE SEND IAC SE
IAC SB TTYPE IS VT200 IAC SE
Next important option is NAWS (31) or WindowSizeNegotiation.
This one is a bit easier than terminaltype. After having
received a IAC DO NAWS from the server, the client will reply
with IAC WILL NAWS and immediately after that send IAC SB NAWS
columns_high columns_low lines_high lines_low IAC SE where
xx_low refers to the lowbyte of xx and xx_high refers to the
highbyte of xx. This will be automagically resent at every
windowresize (when the client gets a SIGWINCH for example) or
at your request with 'IAC SB NAWS SEND IAC SE'.
Example: (WILL/DO exchanged)
client server
IAC SB NAWS 0 80 0 24 IAC SE /* the standard vt100 windowsize */
/* no reply */
And, a bit less important but most complex, the LINEMODE (34)
option. It was implemented it due to the fact, that
some weird DOS telnets would not work otherwise. Implemented
are only the absolute basic feature, which is the actual
switching the telnet to linemode. After exchanging WILL/DO the
server sends a modechange request to the client using IAC SB
LINEMODE LM_MODE MODE_EDIT IAC SE, which should turn on local
commandline-editing for the client. If a client supports
LINEMODE it HAS to support this modechange. The client will
reply with IAC SB LINEMODE LM_MODE MODE_EDIT|MODE_ACK IAC SE
(x|y is bitwise or). Thats it for linemode. (You will perhaps
receive other IAC SB LINEMODEs with other LM_xxx ... you may
ignore them. (At least IRIX 5.x sends IAC SB LINEMODE LM_SLC
.... IAC SE which declares the local characterset.)).
Example: (WILL/DO negotiated)
client server
IAC SB LINEMODE LM_MODE
MODE_EDIT IAC SE
IAC SB LINEMODE LM_MODE
MODE_EDIT|MODE_ACK IAC SE
Further details on linemode can be found in RFC 1184.