telnet.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

TELNET FUNCTIONALITY FOR C-KERMIT 7.0 AND KERMIT 95 1.1.19

  Jeffrey Altman
  The Kermit Project
  Columbia University

Most recent update: Tue Jan  30, 2000


CONTENTS

  1. INTRODUCTION
  2. SUPPORTED TELNET OPTIONS
  3. TELNET OPTION MANAGEMENT
  4. TELNET COMMAND SUMMARY
  5. DIAGNOSING AND FIXING PROBLEMS CONNECTING TO TELNET SERVERS


1. INTRODUCTION

The Telnet protocol is one of the original protocols developed for the 
ARPAnet, the precursor to today's Internet.  Telnet has evolved since 
the early 1970s due to the extensibility provided by its "option" model.
To quote RFC854:

   "The purpose of the TELNET Protocol is to provide a fairly general,
   bi-directional, eight-bit byte oriented communications facility.  Its
   primary goal is to allow a standard method of interfacing terminal
   devices and terminal-oriented processes to each other.  It is
   envisioned that the protocol may also be used for terminal-terminal
   communication ("linking") and process-process communication
   (distributed computation)."

Not so long ago the requirements for a Telnet client were fairly minimal:
support echo management, window size notification, terminal type negotiation,
and perhaps the transmission of environment variables from the client to the
server.  Option negotiations were not time sensitive nor were they
interdependent.  Everyone was happy as long as each option specification was
followed and infinite negotiation loops were avoided.

This simplicity began to change with the introduction of telnet options 
that provide for mutual authentication, data encryption, transport layer 
security, and synchronization of remote processes.  The new options have order
and timing dependencies that require increased sophistication from both client
and server even though the original Telnet protocol specification did not 
change.

Prior to C-Kermit 7.0 and K95 1.1.18, Kermit implemented Telnet protocol by
opening a connection to the host and then transmitting the options that it
supported.  What happened next was determined by how the connection was being
used.  If the user told Kermit to:

  TELNET <host>

then, immediately after the telnet options were transmitted, the terminal
emulator started and began reading the incoming data.  The rest of the Telnet
protocol implementation was purely reactive (with minor exceptions such as
window-size changes): when a Telnet option was received it would be processed
and a response sent if necessary.

However, if the user said:

  SET HOST <host>

then, after the telnet options were transmitted, Kermit would wait for the
next command from the user.  If a CONNECT command was next the behavior would
be the same as for TELNET <host>.  However, if Kermit was executing a script
containing a series of INPUT and OUTPUT commands, the incoming telnet option
negotiations would be processed while waiting for INPUT.

This was adequate when there were no ordering or timing requirements for the
Telnet negotiations.  But with the introduction of authentication,
encryption, transport-layer security, and the Kermit option for managing the
states of the Kermit server on both the workstation and host (see iksd.txt),
it is necessary for Telnet negotiations to take place before the TELNET
command enters the terminal emulator or the SET HOST command completes and
allows any subsequent INPUT and OUTPUT commands to execute.

The timing requirements for the telnet options supported by Kermit are as
follows:

 . START_TLS (Transport Layer Security) must be negotiated or refused before
   any other option.

 . AUTH (Authentication) must be negotiated or refused before ENCRYPT.  AUTH
   must also be negotiated before the login process is initiated.

 . ENCRYPT (Encryption) must be negotiated/refused in both directions before
   it is safe to transmit any data that might be considered private, including
   Telnet options such as terminal type, location, xdisplay, or environment
   variables.  ENCRYPT may not be negotiated if START_TLS has been negotiated
   or if AUTH has not been.

 . KERMIT (Internet Kermit Service) must wait for a response to any request
   for the peer to either turn on or off the Kermit Server capabilities in
   order to facilitate automatic uploading or downloading of files or
   processing of remote commands.

 . NEW_ENV (Transmission of Environment Variables to the Host) must be 
   negotiated before the login process is initiated if the USER variable
   is to be requested from the client.

The result is that Kermit must, to the best of its ability, attempt to
process all of the above options before TELNET enters CONNECT mode or SET
HOST completes to process the next command.  Therefore it might take Kermit
longer to make a connection to a host than before.

The reality is actually far different.  Even if the CONNECT mode or first
INPUT command was executed sooner no user data could be received until the
Telnet negotiations were complete.  In addition, the timing of the initial
INPUT command used to require that the length of time it takes to process the
Telnet negotiations be factored in.  This is no longer necessary and was
inappropriate in the first place.  A login script should not have to be
modified for different connection types; the telnet negotiations should be
transparent to the script.  In C-Kermit 7.0 and Kermit 95 1.1.18 they are.


2. SUPPORTED TELNET OPTIONS

BINARY (Binary Transmission Mode)                  [RFC  856]

When a telnet session is initiated, the connection is in Network Virtual
Terminal (NVT) mode.  NVT mode provides for special treatment of the carriage
return (CR) control character to provide for deterministic parsing of the
input stream.  Every CR that is transmitted must be followed by a line feed
(LF) control character or a NUL control character.  This enables an NVT to
distiguish between the Carriage Return function and the End of Line indicator.
This works fine for textual data.  But in transmission of random binary data
there is the possibility that the sequence CR NUL might be misinterpreted.

Binary mode removes the ambiguity by removing the requirement that 
CR be followed by either LF or NUL.  It is negotiatied separately
in each direction of data transmission.  Binary transmission mode is
not required for transferring files with Kermit protocol but it might be
required when transfering files with Xmodem, Ymodem, or Zmodem.

Binary mode is one of the most frequently misimplemented telnet options.
Many implementation will negotiate Binary mode in only one direction
but apply it in both.  Kermit provides workarounds for
these problems with its SET TELNET BUG BINARY-ME-MEANS-U-TOO and 
SET TELNET BUG BINARY-U-MEANS-ME-TOO commands.

Kermit also provides the SET TELNET BINARY-TRANSFER-MODE command to
automatically enter binary mode at the start of a file transfer
and return to NVT mode when the transfer is completed.

ECHO (Echo Mode)                                   [RFC  857] 

When a telnet session is initiated, data is not echoed by the receiver.
This means that a telnet client must echo each character locally as
it is being sent to the host.  While this reduces network traffic it 
can cause problems with terminal emulation and echoing of sensitive data.

The echo option allows the each side to specify that it intends to 
echo the data that it receives.  Normally this would be used to negotiate
that the server should echo the data it receives from the client.  While it
is possible for the client to state that it will echo the data received
from the server this makes no sense and if negotiatied could result in
an infinite loop of a single character being echoed back and forth.

As a piece of telnet trivia, the BSD 4.2 telnet client would echo 
incoming data sent by the server if the host requested it.  Kermit
will always respond WONT ECHO to a DO ECHO request when it is the client.

SUPPRESS GO AHEAD (Suppress Go Ahead commands)     [RFC  858]

When a telnet session is initiated, all data transmitted by the sender is to
be followed by a Go Ahead (GA) command sequence.  This is to enable telnet to
be used over half-duplex (two-way alternate) connections, and it gives the
telnet partner permission to transmit.  But to our knowledge, all telnet
sessions used over the Internet are full duplex connections.  The Suppress Go
Ahead (SGA) option is negotiated in both directions to suppress the
transmission of the GA commands and treat the connection as full duplex
(two-way simultaneous).

LOGOUT (Logout user from host)                     [RFC  727]

Some operating systems such as VMS support the notion of a login session
that can continue across separate telnet connections.  If a telnet 
connection is prematurely interrupted by a network failure, the user
may reconnect to a pre-existing session on their next login attempt.

The Telnet Logout option is sent by the telnet client just before the
tcp/ip socket is closed to indicate to the host that the connection is
being intentionally terminated by the user and is not being closed
due to a network error.

SEND LOCATION (Send Terminal Location)             [RFC  779]

The Send Location option provides the host with a method for requesting
the location of the telnet client.  When a location string has been
specified with the SET TELNET LOCATION command, Kermit transmits
this string to the host upon request.

TERMINAL TYPE (Negotiate Terminal Type)            [RFC 1091]

The Terminal Type option allows the client and server to 
agree to a common terminal type that they both support.  C-Kermit
reports the value of the local TERM environment variable.  Since Kermit 95
supports more than 30 terminal types, it continues to offer additional
terminal tyeps to the host until the host accepts one.

NAWS (Negotiate About Window Size)                 [RFC 1073]

The Negotiate About Windows Size (NAWS) lets the client report its current
Window size to the host.  Every time the client's window size changes, the new
size is reported to the host automatically.  It is not possible for the host
to report a window size to the client.

XDISPLOC (Report X Window Display location)        [RFC 1096]

The X Windows display option is used to report to the host the address
of the local X Windows Server.  Kermit sends the contents of the
local DISPLAY environment variable or the string specified by the
SET TELNET ENVIRONMENT DISPLAY command.  

AUTHENTICATION (Authenticate end user to host)     [Internet-Draft]

The AUTHENTICATION option is used to determine which if any authentication
method such as Kerberos 4, Kerberos 5, Secure Remote Password, etc, should
be used to authenticate the user to the host.

ENCRYPTION (Encrypt session)                       [Internet-Draft]

The ENCRYPTION option is used in conjunction with the AUTHENTICATE option
to encrypt all the data transmitted during the session.  The ENCRYPTION
option must be negotiated separately in each direction.

NEW ENVIRONMENT (Report Environment to host)       [RFC 1572]

The NEW ENVIRONMENT option is used by the client to reply to requests 
from the server for either all or specified environment variables such
as DISPLAY, USERNAME, ACCOUNT, JOB, PRINTER, and SYSTEMTYPE.  When the
NEW ENVIRONMENT option is used to transmit the username, many telnet 
servers skip their login or username prompt and go directly to the 
password prompt.

START TLS (Transmit Telnet over TLS)               [Internet-Draft]

The START TLS option is used by the client and server to determine whether the
telnet session should be restarted after first establishing a TLSv1 session.
TLS provides strong encryption and optionally authenticates the client and the
server using X.509 certificates.  START_TLS can be used with the AUTHENTICATE
option.  When negotiatied START_TLS replaces the ENCRYPTION option.

KERMIT (Synchronize Kermit File Transfers)         [Internet-Draft]

The Kermit option (invented by the Kermit Project) is designed to 
allow a Kermit file-transfer client and a Kermit server to synchronize
their operations.  This allows a change in "mode" of the server to
automatically switch the client into the complementary mode, and vice
versa.

FORWARD X (Transmit X Windows data over Telnet)    [Internet-Draft]

The FORWARD X option (invented by the Kermit Project) allows the
telnet server to redirect all output from X Windows clients and 
transmit it across to telnet connection.  The telnet client then
forwards the data to the local X Windows server.  When the telnet
connection is encrypted, both the telnet data and X Windows session data
are protected.

3. TELNET OPTION MANAGEMENT

One of the benefits of processing all the Telnet options during the SET HOST
and TELNET commands is that it is now possible to configure policy 
requirements for a valid connection.  This capability is necessary when the
connection must be secure (authenticated and encrypted) or else fail.  
Policies are specified with the new command:

  SET TELOPT [ <switch> ] <option> <local-mode>
  SET TELOPT [ <switch> ] <option> <remote-mode>
  SET TELOPT [ <switch> ] <option> <local-mode> <remote-mode>

Which of the SET TELOPT command forms is used is dependent on the telnet 
option.  Some options, such as authentication, terminal type and window size, 
are negotiated in one direction and others, such as binary, encryption and 
kermit are negotiated separately in each direction.  For each option, the
mode can be:

ACCEPTED
  Kermit does not offer the option but if the peer requests it
  Kermit agrees to use it.

REFUSED
  Kermit does not offer the option and if the peer requests it
  Kermit refuses to use it.

REQUESTED
  Kermit requests the option but agrees not to use it if the peer
  refuses it.

REQUIRED
  Kermit requests the option and terminates the connection if
  the peer refuses it.

The optional <switch> can be:

/CLIENT
  Specifies that the command is being used to set the configuration for when 
  Kermit is the Telnet client.  This is the default when Kermit is not acting
  as an Internet Kermit Service.

/SERVER
  Specifies that the command is being used to set the configuration
  for when Kermit is the Telnet server.  Kermit is a telnet server when it
  is accepting incoming connections with SET HOST * or when it is acting as
  an Internet Kermit Service.  This is the default when Kermit is acting as 
  an Internet Kermit Service.

The options that can be configured and their default settings, as viewed by
SHOW TELOPT, are:

       Telnet Option  Me (client)   U (client)  Me (server)   U (server)

              BINARY     ACCEPTED     ACCEPTED     ACCEPTED     ACCEPTED
                             WONT         WONT
                ECHO      REFUSED     ACCEPTED    REQUESTED      REFUSED
                             WONT         WONT
   SUPPRESS-GO-AHEAD     ACCEPTED     ACCEPTED    REQUESTED    REQUESTED
                             WONT         WONT
       SEND-LOCATION    REQUESTED      REFUSED      REFUSED      REFUSED
                             WONT         WONT
       TERMINAL-TYPE    REQUESTED      REFUSED      REFUSED    REQUESTED
                             WONT         WONT
                NAWS    REQUESTED      REFUSED      REFUSED    REQUESTED
                             WONT         WONT
            XDISPLOC      REFUSED      REFUSED      REFUSED      REFUSED
                             WONT         WONT
      AUTHENTICATION    REQUESTED      REFUSED      REFUSED    REQUESTED
                             WONT         WONT
          ENCRYPTION    REQUESTED    REQUESTED    REQUESTED    REQUESTED
                             WONT         WONT
     NEW-ENVIRONMENT    REQUESTED      REFUSED      REFUSED    REQUESTED
                             WONT         WONT
           start-tls     ACCEPTED      REFUSED      REFUSED    REQUESTED