Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

If you were using the program on a directly-connected terminal, you would simply use the

key or keystroke command appropriate to that terminal to interrupt or kill the process and

restart it. Instead, you are using Telnet, so you enter the appropriate keystroke, which gets

converted to the special Telnet Interrupt Process command code (byte value 244, preceded

by the Telnet Interpret As Command code, 255).

Since Telnet uses only a single stream for commands and data, that code is placed into the

TCP data stream to be sent over to the Telnet server. Since you were entering data for a

while, that Telnet Interrupt Process code will be sitting behind a bunch of regular data bytes.

Now, the remote process has stopped reading this data, which means the TCP receive

buffer on the server will start to fill up. The Interrupt Process command will thus remain

stuck in the buffer, waiting to be read. In fact, if the number of data bytes in front of the

command is high enough, the TCP buffer on the server may fill entirely, causing the server

to close the client’s TCP send window. This means the Interrupt Process command will wait

in the client’s outgoing TCP queue and never even be sent to the remote host at all!

Obviously, what we need here is some way to be able to flag the Interrupt Process

command, so that it can be sent to the remote host regardless of the number of data bytes

outstanding in front of it. If you’ve already perused the large section of this Guide devoted to

TCP, you may now be thinking that you have already read about a feature of that protocol

that seems ideally suited for this exact problem… and you’d be correct! The TCP “urgent”

function allows an important piece of data to be marked so that it is given priority over

regular data, a process sometimes called out-of-band signaling (because the signal is

“outside” the normal data stream). Telnet makes use of this feature of TCP to define what it

calls the synch function.

The Synch Function

When needed, as in the example just described, the synch function is invoked by the client

sending the special Telnet Data Mark (DM) protocol command, while instructing its TCP

layer to mark that data “urgent”. The URG bit in the TCP segment carrying this command

causes it to bypass TCP’s normal flow control mechanism so it is sent over to the remote

host. The Telnet server software, seeing the synch in the data stream, then searches

through all of the data in its buffer looking only for Telnet control commands such as

Interrupt Process, Abort Output and Are You There. These commands are then executed

immediately. The server continues to search for important commands up to the point where

the Data Mark command is seen. All intervening data is discarded; it will need to be retrans-

mitted. After the Data Mark is processed, the server returns to normal operation.

It is also possible for the server to use the synch function in communication with the user on

the client device. For example, if the user sends the Abort Output command to the server,

he or she is telling the server to discard all remaining output from the current process. The

server will stop sending that output, and can also use the synch function to clear all

outstanding data that is waiting in buffers to be sent to the client machine (since it causes

data to be discarded as mentioned above).

Key Concept: Telnet protocol commands are sent in the same stream with user

data, which means a problem with the remote host that stops the flow of data might

cause user commands to become backed up and never received by the host. Since

this may include commands issued by the user to try to fix the problem on the host, this can

be a serious problem. To alleviate this situation, Telnet includes the synch function, which

uses TCP’s urgent data transmission feature to force the receipt of essential commands

even when regular data is not being processed.

Telnet Options and Option Negotiation

The basic Telnet Network Virtual Terminal (NVT) specification solves the problem of

compatibility between different terminal and computer types by defining a common repre-

sentation for data and commands that every Telnet client and server uses. The price for this

universal representation, however, is very high: all of the advanced or special capabilities of

terminals and hosts is stripped off. The result is a language that everyone can speak, but

that is not capable of much more than basic conversation.

The creators of Telnet recognized that while it was important to define NVT as a common

base to ensure cross-device compatibility, it was also essential that some means be

provided by which clients and servers could agree to use more advanced means of commu-

nication. They defined a set of Telnet options, and a mechanism by which a Telnet client

and server can negotiate which options they want to use.

Most Telnet options are used for the purpose of improving the efficiency of how data is

transferred between devices. For example, by default the NVT assumes half-duplex

operation with each device needing to use the Go Ahead command after each trans-

mission. However, virtually all hardware now supports full-duplex communication, so

devices will usually agree to use the Suppress Go Ahead option to eliminate the need to

send this character. Similarly, it is possible for devices to negotiate the sending of 8-bit

binary data instead of the standard 7-bit ASCII of the Telnet NVT.

The process of Telnet option negotiation is described in the main Telnet standard document,

RFC 854, as well as a companion document, RFC 855 (Telnet Option Specifications

). The

options themselves are described in a separate set of Internet standards. Several of these

were published at the same time as RFCs 854 and 855; others were defined earlier as part

of previous versions of Telnet, and still others have been added over the years. There are

now several dozen different Telnet options in existence; a master list is maintained by IANA

(like all other TCP/IP parameters).

On The Web: An up-to-date listing of all Telnet options can be found on the IANA

Web site at: http://www.iana.org/assignments/telnet-options

Common Telnet Options

Each Telnet option is identified using a decimal byte code with a possible value of 0 to 254;

the value 255 is reserved to extend the option list should more than 255 options ever be

needed. Each option also has a text code string associated with it, which is often used as a

symbol in place of the code number in both protocol discussions and diagnostic output.

Table 283 lists some of the more interesting Telnet options and provides a brief description

of each.

Table 283: Common Telnet Options (Page 1 of 2)

Option

Number

Option Code Option Name Description

Defining

RFC

TRANSMIT-

BINARY

Binary

Transmission

Allows devices to send data in 8-bit binary form

instead of 7-bit ASCII.

856

1 ECHO Echo

When you press a key on a terminal, you also

expect to see the character you entered

appear on the terminal screen as output; this is

called echoing the input. Echoing is a signif-

icant issue in terminal applications because it

can be implemented in a number of different

ways. This option allows devices to negotiate

any of a variety of different echo modes.

857

SUPPRESS-

GO-AHEAD

Suppress Go

Ahead

Allows devices not operating in half-duplex

mode to no longer need to end transmissions

using the Telnet Go Ahead command.

858

5 STATUS Status

Lets a device request the status of a Telnet

option.

859

6 TIMING-MARK Timing Mark

Allows devices to negotiate the insertion of a

special timing mark into the data stream, which

is used for synchronization.

860

10 NAOCRD

Output

Carriage-

Return

Disposition

Lets the devices negotiate how carriage

returns will be handled.

652

11 NAOHTS

Output

Horizontal Tab

Stops

Allows the devices to determine what

horizontal tab stop positions will be used for

output display.

653

12 NAOHTD

Output

Horizontal Tab

Stop

Disposition

Allows the devices to negotiation how

horizontal tabs will be handled and by which

end of the connection.

654

13 NAOFFD

Output

Formfeed

Disposition

Allows the devices to negotiation how form

feed characters will be handled.

655

14 NAOVTS

Output Vertical

Tabstops

Used to determine what vertical tab stop

positions will be used for output display.

656

Key Concept: The Telnet NVT specification ensures that all devices using Telnet

can talk to each other, but accomplishes this by boiling down communication to the

simplest of representations. To allow the use of more sophisticated formats and

services, Telnet defines a number of options. If a client and server both implement a

particular option, they can enable its use through a process of negotiation.

Enabling Options Using Negotiation

The first stage in Telnet option negotiation is for the client and server to decide whether or

not they want to enable a particular option. One of the aspects of Telnet’s symmetry of

operation is that either device may choose to initiate the use of an option. The initiating

15 NAOVTD

Output Vertical

Tab

Disposition

Lets devices negotiation the disposition of

vertical tab stops.

657

16 NAOLFD

Output

Linefeed

Disposition

Allows devices to decide how line feed

characters should be handled.

658

17 EXTEND-ASCII

Extended

ASCII

Lets devices agree to use extended ASCII for

transmissions and negotiate how it will be

used.

698

TERMINAL-

TYPE

Terminal Type

Allows the client and server to negotiate the

use of a specific terminal type. If they agree,

this allows the output from the server to be

ideally customized to the needs of the

particular terminal the user is working on.

1091

31 NAWS

Negotiate

About Window

Size

Permits communication of the size of the

terminal window.

1073

TERMINAL-

SPEED

Terminal

Speed

Allows devices to report on the current terminal

speed.

1079

TOGGLE-

FLOW-

CONTROL

Remote Flow

Control

Allows flow control between the client and the

server to be enabled and disabled.

1372

34 LINEMODE Linemode

Allows the client to send data one line at a time

instead of one character at a time. This

improves performance by replacing a large

number of tiny TCP transmissions with a

smaller number of larger ones.

1184

AUTHENTI-

CATION

Authentication

Lets the client and server negotiate a method

of authentication to secure connections.

1416

Table 283: Common Telnet Options (Page 2 of 2)

Option

Number

Option Code Option Name Description

Defining

RFC

device may either specify that it wants to start using an option, or that it wants the other

device to start using it. The responding device may either agree or disagree in either case;

an option can only be enabled if both devices agree to its use.

This negotiation is performed using four Telnet protocol commands, as follows:

☯ WILL: Sent by the initiator to indicate that it wants to start using a particular option.

There are two possible replies by the responding device:

☯ DO: Sent to indicate agreement that the initiator should use the option; it is then

considered enabled.

☯ DONT: Sent to specify that the initiator must not use the option.

☯ DO: Sent by the initiator to request that the other device start using an option. That

device may respond in two ways:

☯ WILL: Sent to specify that the responding device will agree to use the option; the

option is enabled.

☯ WONT: Sent to tell the initiator that the responder will not use the option

requested.

The symmetry of Telnet, combined with the fact that both DO and WILL can be used either

to initiate a negotiation or respond to one, make Telnet’s option negotiation potentially

complicated. Since either device can initiate negotiation of an option at any time, acknowl-

edgment loops could potentially arise if both devices were to try to enable an option

simultaneously, or get into a situation where each kept responding to the other’s replies.

For this reason, the Telnet standard specifies restrictions on when the WILL and DO

commands are used. One is that a device may only send a negotiation command to request

a change in the status of an option; it cannot send DO or WILL just to confirm or reinforce

the current state of the option. Another is that a device receiving a request to start using an

option it is already using should not acknowledge it using DO or WILL.

Disabling Options

Since an option may only be activated if both devices agree to use it, either may disable the

use of an option at any time by sending either of these commands:

☯ WONT: Sent by a device to indicate that it is going to stop using an option. The other

device must respond with DONT as a confirmation.

☯ DONT: Sent by a device to indicate that it wants the other device to stop using an

option. The other device must respond with WONT.

Key Concept: Either device may choose to negotiate the use of a Telnet option. The

initiator uses the WILL command to specify that it wants to start using a particular

option; if the other device agrees, it responds with DO; otherwise, it sends DONT.

Alternately, the initiator can use the DO command to indicate that it wants the other device

to start using an option; that device responds with WILL if it agrees to do so, or WONT if it

does not. Either device may disable the use of an option at any time by sending the other a

WONT or DONT command.

Option Subnegotiation

All of the DO/DONT/WILL/WONT stuff above only serves to enable or disable an option.

Some options are only either off or on, in which case the negotiation above is sufficient. An

example would be the binary transmission option, TRANSMIT-BINARY. Others require that

after they are enabled, the client and server exchange parameters to control how the option

works. For example, the TERMINAL-TYPE option requires some way for the client to send

the server the name of the terminal.

Telnet allows the client and server to send an arbitrary amount of data related to the option

using a process called option subnegotiation. A device begins this process by sending a

special sequence of Telnet protocol commands and data. First the command SB is sent,

followed by the option number and parameters as defined by the particular option; the end

of the subnegotiation data is marked by the protocol command SE. Of course, both SB and

SE must be preceded by the Interpret As Command (IAC) command byte.

So, let’s take the terminal type option again as an example. Suppose the server supports

this option and would like the client to use it. It will send:

IAC DO TERMINAL-TYPE

Note: I am showing the text mnemonics for convenience; this would really be sent

as the three decimal bytes 255 253 24.

Assuming the client agrees, it will respond with:

IAC WILL TERMINAL-TYPE

Now the terminal type option is in effect, but the server still doesn’t know what terminal the

client is using. It can prompt the client to provide that information by sending this:

IAC SB TERMINAL-TYPE SEND IAC SE

The client, receiving this “subnegotiation” command, will respond with:

IAC SB TERMINAL-TYPE IS <some_terminal_type> IAC SE

Key Concept: The WILL and DO commands only turn on a Telnet option that a client

and server agree to use. In some cases, an option requires additional information to

be sent between the client and server device for it to function properly. This is

accomplished through a process of option subnegotiation. Either device sends the other a

set of data relevant to the option, bracketed by the SB (subnegotiation) and SE (end subne-

gotiation) Telnet protocol commands.

Berkeley Remote ("r") Commands

TCP/IP has achieved success in large part due to its universality: it has been implemented

on virtually every major computing platform. While the suite is thus not specific to any

operating system, there is no denying that its history is closely tied to a particular one—

UNIX. Most of the computers on the early Internet used UNIX, and the development of

TCP/IP has paralleled that of UNIX in a number of respects.

One of the most important organizations involved in the development of UNIX, and thus

TCP/IP indirectly, was the University of California at Berkeley. Their well-known Berkeley

Software Distribution (BSD) UNIX has been in widespread use for over 20 years. A set of

commands was developed for BSD UNIX to facilitate various remote operation functions

over a TCP/IP internetwork. Each of these programs begins with the letter “r” (for “remote”),

so they have come to be known as both the Berkeley remote commands (or utilities) and

also simply the “r” commands. Since their initial creation, they have been adopted for most

variations of UNIX, and some other operating systems as well.

In this section I provide a brief description of the Berkeley remote protocols and how they

are used. I begin with a discussion of the main protocol in this group, rlogin, and how it is

used to enable remote host access. I then describe the remote shell program, rsh, and how

it allows a command to be executed on a network host. I conclude with a brief summary of

the other members of the “r” protocol family: rcp, ruptime and rwho.

Background Information: This section will probably make much more sense to

those who have some understanding of the UNIX operating system than those who

do not. I also make some reference to Telnet in this section so you may wish to

have at least basic familiarity with that protocol.

Berkeley Remote Login (rlogin)

The “head” of the Berkeley remote protocol family is the remote login command, rlogin. As

the name clearly implies, the purpose of this program is to allow a user on a UNIX host to

remote login. While they can be used in a very similar way, however, they are quite different

in a few respects.

From a conceptual standpoint, Telnet is designed as a protocol to enable terminal/host

communication. As I mentioned in the Telnet overview topic, the protocol was not designed

specifically for the purpose of remote login. In contrast, rlogin was intended for that specific

purpose, and this is reflected in its operation.

rlogin Operation

The protocol requires rlogin server software to be running on the host that is going to allow

remote access; it is usually called rlogind (for rlogin daemon, the latter word being the

standard UNIX term for a background server process). The server listens for incoming

connection requests on TCP port 513. A user who wants to remotely log in to the server

runs the rlogin command on his or her local host, and specifies the name of the server. The

client makes a TCP connection to the server, and then sends to the server a string

containing the following information:

☯ The login name of the user on the client machine.

☯ The login name that the user wants to use on the server (which is often the same as

the user’s login name on the client, but not always.)

☯ Control information such as the type and speed of the terminal.

The server processes this information and begins the login process. It will normally prompt

the user for a password to log in to the remote host. Assuming the password is correct, the

user will be logged in to the remote host and can use it as if he or she were locally

connected.

Comparing rlogin to Telnet

From a practical standpoint, the rlogin command is much simpler than Telnet; it does not

support Telnet’s full command structure, nor capabilities such as option negotiation. It does

include a small set of commands, however. The client is able to send to the server one key

piece of information: the current size of the terminal window in use. The server is able to tell

the client to turn on or off flow control, request that the client send it the current window

size, or flush pending output that the server has sent, up to a certain point in the data

stream.

Automating rlogin

In some organizations, many different UNIX hosts are used every day and needing to type

passwords all the time when using rlogin was deemed to be somewhat of a chore. On these

systems, it is possible for administrators to set up control files that specify combinations of

host names, user names and passwords. If set up correctly, this enables an authorized user

to utilize rlogin to remotely access a host automatically, without having to enter either a

rlogin Security Concerns and slogin

As originally designed, rlogin is a classic example of a protocol from the early days of TCP/

IP: it emphasizes simplicity and usability over security. This is especially true of the

automated login process just described. The original schemes used by rlogin for authenti-

cation are considered inadequate for modern TCP/IP internetworks, especially those

connected to the Internet. Later versions of rlogin have been enhanced with more secure

authorization methods. There is also a newer program called slogin (for secure login) that

uses stronger authentication and encryption, and is intended to replace rlogin on newer

systems.

Key Concept: The Berkeley remote or “r” commands facilitate remote operations

between UNIX hosts on a TCP/IP internetwork. The base command of the family is

the remote login command, rlogin, which allows a device on one host to access and

use another as if he or she were locally connected to it. rlogin is often used as an alternative

to Telnet, but is simpler both conceptually and practically.

Berkeley Remote Shell (rsh)

The Berkeley remote login command (rlogin) allows a user to easily access a remote UNIX

host over a TCP/IP internetwork. A user would normally use rlogin when he or she needs to

a user needs to only enter one command on a remote host. With rlogin, the user would

have to log in to the host, execute the command, and then log back out again.

This isn’t exactly an earth-shattering amount of inconvenience, especially when the correct

configuration files are set up to allow automatic login. Over the course of time, however, all

the extra logging in and out can become tedious. As a convenience, a variation of rlogin

was created called remote shell (rsh), which allows a user to access a remote host and

execute a single command upon it without requiring the login and logout steps.

Note: “Shell” is the standard term used in UNIX to refer to the user interface that

accepts commands from the user and displays output on the screen.

rsh Operation

The rsh command is based on rlogin and really works in much the same way, except that it

is oriented around executing a command rather than establishing a persistent login session.

The server process on the remote host is usually called rshd (remote shell daemon) and

listens for incoming rsh requests. When one is received, the user is logged in through the

same mechanism as rlogin. The command is then run on the remote host and the user is

automatically logged out.

Automated Use of rsh by Programs

rsh is most useful when automatic login is employed, so that the program can be run

without the need for the user to enter a login name or password. In that case, it is possible

to have programs use rsh to automatically run commands on remote hosts without the need

for human intervention, which opens up a number of possibilities for UNIX users. The