| |
The Telnet Protocol
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.
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. They are described
in detail in separate RFCs. The following
are the most important.
|
Decimal
code
|
Name
|
RFC
|
|
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
|
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,<type of operation>,<option>The
response is of the same form.Operation
is one of
| Description
|
Decimal
Code
|
Action
|
| WILL
|
251
|
Sender wants to do something.
|
| DO
|
252
|
Sender wants the other
end to do something.
|
| WONT
|
253
|
Sender doesn't want 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 sequence255(IAC),251(WILL),3The
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,<option
code number>,1,IAC,SEandIAC,SB,<option
code>,0,<value>,IAC,SE
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.
 |
|
|
|
|
|
 |
|
