TELNET PROTOCOL IN C-KERMIT 8.0 AND KERMIT 95 2.00

   Author:
          Jeffrey Altman
          The Kermit Project
          Columbia University
          
   Most recent update:
          3 December 2001
          
  CONTENTS
  
    1. [1]INTRODUCTION
    2. [2]SUPPORTED TELNET OPTIONS
    3. [3]TELNET OPTION MANAGEMENT
    4. [4]TELNET COMMAND SUMMARY
    5. [5]DIAGNOSING AND FIXING PROBLEMS CONNECTING TO TELNET SERVERS
     _________________________________________________________________
   
  1. INTRODUCTION
  
   [ [6]Top ] [ [7]Contents ] [ [8]Next ]
   
   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 [9]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 [10]C-Kermit 7.0 and [11]K95 1.1.19, 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 initial telnet options were transmitted,
   the terminal emulator started and began processing 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 as
   required.
   
   However, if the user said:
   
  SET HOST host

   then, after the initial 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 [12]Kermit server on both the
   workstation and host 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.
     * FORWARD_X (Forward X Windows Systems data with X authorization)
       must only be used on encrypted connections.
     * KERMIT (RFC2839/2840 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.
   
   [ [13]C-Kermit ] [ [14]Kermit 95 ] [ [15]Kermit Home ]
    ________________________________________________________________________
  
  2. SUPPORTED TELNET OPTIONS
  
   [ [16]Top ] [ [17]Contents ] [ [18]Next ] [ [19]Previous ]
   
   AUTHENTICATION (Authenticate end user to host) [[20]RFC2941]
          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.
          
   BINARY (Binary Transmission Mode) [[21]RFC856]
          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.
          
   COM-PORT-CONTROL (Remote Serial Port device control) [[22]RFC2217]
          This option is designed for use with reverse terminal servers
          and other network services that share serial line devices such
          as modems across the network. A long term issue has been the
          need for the network administrator to pre-configure the modem
          and serial line parameters to meet the requirements of the
          client applications. Client applications are able to adjust the
          modem configuration by issuing modem specific command
          sequences. Many options require the modem and serial line
          device to be adjusted simultaneously. Two examples are the use
          of dynamic speed matching and flow control protocols. When the
          com-port control option is negotiated the telnet client is able
          to treat the remote serial line device as if it were locally
          attached. This allows Kermit's SHOW COMMUNICATIONS, SET FLOW,
          SET SPEED, SET PARITY, SET STOP-BITS, SET MODEM SPEED-MATCHING
          and WAIT commands to remotely control or respond to changes in
          the modem or serial line properties.
          
   ECHO (Echo Mode) [[23]RFC857]
          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.
          
   ENCRYPTION (Encrypt session) [[24]RFC2946]
          The ENCRYPTION option is used in conjunction with the
          AUTHENTICATE option to encrypt all the data transmitted during
          the session if START_TLS is not negotiated. The ENCRYPTION
          option must be negotiated separately in each direction.
          
   FORWARD X (Forward X Windows Systems data with X authorization)
          [Internet-Draft]
          The FORWARD X option (developed by the Kermit Project) allows
          the telnet server to redirect all output from X Windows clients
          and transmit it across an encrypted telnet connection. The
          telnet client then forwards the data to the local X Windows
          server. Connections from the X Windows client to the Telnet
          Server are authorized using the strongest X authorization
          method supported by both X Windows client and the Telnet
          Server. Unauthorized connections are rejected.
          
   KERMIT (Synchronize Kermit File Transfers) [[25]RFC2840]
          The Kermit option (developed 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.
          
   LOGOUT (Logout user from host) [[26]RFC727]
          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.
          
   NAWS (Negotiate About Window Size) [[27]RFC1073]
          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.
          
   NEW ENVIRONMENT (Report Environment to host) [[28]RFC1572]
          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.
          
   SEND LOCATION (Send Terminal Location) [[29]RFC779]
          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.
          
   START TLS (Transmit Telnet over TLS) [[30]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 or Kerberos 5 credentials.
          START_TLS can be used with the AUTHENTICATE option. TLS
          connections may implement data compression. When negotiatied
          START_TLS replaces the ENCRYPTION option.
          
   SUPPRESS GO AHEAD (Suppress Go Ahead commands) [[31]RFC858]
          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).
          
   TERMINAL TYPE (Negotiate Terminal Type) [[32]RFC1091]
          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 types to the host until the host
          decides which one to use.
          
   XDISPLOC (Report X Window Display location) [[33]RFC1096]
          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.
          XDISPLOC is not used if FORWARDX is negotiated.
          
   [ [34]C-Kermit ] [ [35]Kermit 95 ] [ [36]Kermit Home ]
    ________________________________________________________________________
  
  3. TELNET OPTION MANAGEMENT
  
   [ [37]Top ] [ [38]Contents ] [ [39]Next ] [ [40]Previous ]
   
   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 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
)

   000 BINARY                ACCEPTED     ACCEPTED     ACCEPTED     ACCEPTED
                                 WONT         DONT
   001 ECHO                   REFUSED     ACCEPTED    REQUESTED      REFUSED
                                 WONT         DONT
   003 SUPPRESS-GO-AHEAD     ACCEPTED     ACCEPTED    REQUESTED    REQUESTED
                                 WONT         DONT
   023 SEND-LOCATION        REQUESTED      REFUSED      REFUSED      REFUSED
                                 WONT         DONT
   024 TERMINAL-TYPE        REQUESTED      REFUSED      REFUSED    REQUESTED
                                 WONT         DONT
   031 NAWS                 REQUESTED      REFUSED      REFUSED    REQUESTED
                                 WONT         DONT
   035 XDISPLOC               REFUSED      REFUSED      REFUSED      REFUSED
                                 WONT         DONT
   037 AUTHENTICATION       REQUESTED      REFUSED      REFUSED    REQUESTED
                                 WONT         DONT
   038 ENCRYPTION           REQUESTED    REQUESTED    REQUESTED    REQUESTED
                                 WONT         DONT
   039 NEW-ENVIRONMENT      REQUESTED      REFUSED      REFUSED    REQUESTED
                                 WONT         DONT
   044 COM-PORT-CONTROL     REQUESTED      REFUSED      REFUSED      REFUSED
                                 WONT         DONT
   046 START-TLS             ACCEPTED      REFUSED      REFUSED    REQUESTED
                                 WONT         DONT
   047 KERMIT               REQUESTED    REQUESTED    REQUESTED    REQUESTED
                                 WONT         DONT
   049 FORWARD-X              REFUSED     ACCEPTED      REFUSED      REFUSED
                                 WONT         DONT
                                                                         

   The second line listed for each option shows the currently negotiated
   state of the option for the current connection.
   
   The SET TELOPT command should be used instead of the older commands:
   
  SET TELNET AUTHENTICATION {ACCEPTED, REFUSED, REQUESTED, REQUIRED }
  SET TELNET BINARY-MODE    {ACCEPTED, REFUSED, REQUESTED, REQUIRED }
  SET TELNET ENCRYPTION     {ACCEPTED, REFUSED, REQUESTED, REQUIRED }
  SET TELNET ENVIRONMENT    {ON, OFF }
  SET TELNET NAWS           {ACCEPTED, REFUSED, REQUESTED, REQUIRED }
  SET TELNET XDISPLAY-LOC   {ACCEPTED, REFUSED, REQUESTED, REQUIRED }

   which are now considered obsolete (but still supported).
   
   [ [41]C-Kermit ] [ [42]Kermit 95 ] [ [43]Kermit Home ]
    ________________________________________________________________________
  
  4. TELNET COMMAND SUMMARY [ [44]Top ] [ [45]Contents ] [ [46]Next ] [
  [47]Previous ]
  
   The Telnet protocol is used by Kermit when establishing the vast
   majority of its connections with the SET HOST or TELNET commands. The
   format of the SET HOST command is SET HOST [ switches ]
   hostname-or-address [ service ] [ protocol-switch ] Telnet protocol is
   used when the protocol-switch is one of the following:
   
   /TELNET
          Send initial Telnet negotiations even if this is not a Telnet
          port.
          
   /NO-TELNET-INIT
          Use Telnet protocol, but do not initiate any telnet
          negotiations unless the server sends a telnet first. For use
          with non-Telnet servers which expect the client to use Telnet
          NVT mode.
          
   /SSL-TELNET
          Perform SSL negotiations and if successful start Telnet
          negotiations.
          
   /TLS-TELNET
          Perform TLS negotiations and if successful start Telnet
          negotiations.
          
   TELNET /AUTH:type /ENCRYPT:type /USERID:name /PASSWORD:string host
          port
          The TELNET command is a shortcut for making interactive
          connections. It is the equivalent of specifying:
          
  SET TELOPT AUTH ...
  SET TELNET AUTH TYPE ...
  SET TELOPT ENCRYPT ...
  SET TELNET ENCRYPT TYPE ...
  SET LOGIN USERID ...
  SET LOGIN PASSWORD ...
  SET HOST /CONNECT host port /TELNET

        /AUTH:type
                Is equivalent to SET TELNET AUTH TYPE type and SET TELOPT
                AUTH REQUIRED with the following exceptions. If the type
                is AUTO, then SET TELOPT AUTH REQUESTED is executed and
                if the type is NONE, then SET TELOPT AUTH REFUSED is
                executed. If START_TLS is negotiated, REQUIRED becomes
                REQUESTED.
                
        /ENCRYPT:type
                Is equivalent to SET TELNET ENCRYPT TYPE type and SET
                TELOPT ENCRYPT REQUIRED REQUIRED with the following
                exceptions. If the type is AUTO then SET TELOPT AUTH
                REQUESTED REQUESTED is executed and if the type is NONE
                then SET TELOPT ENCRYPT REFUSED REFUSED is executed. If
                START_TLS is negotiated, REQUIRED becomes REFUSED.
                
        /USERID:[name]
                This switch is equivalent to SET LOGIN USERID name or SET
                TELNET ENVIRONMENT USER name. If a string is given, it
                sent to host during Telnet negotiations; if this switch
                is given but the string is omitted, no user ID is sent to
                the host. If this switch is not given, your current
                USERID value, \v(userid), is sent. When a userid is sent
                to the host it is a request to login as the specified
                user.
                
        /PASSWORD:[string]
                This switch is equivalent to SET LOGIN PASSWORD. If a
                string is given, it is treated as the password to be used
                (if required) by any Telnet Authentication protocol
                (Kerberos Ticket retrieval, Secure Remote Password, or
                X.509 certificate private key decryption.) If no password
                switch is specified a prompt is issued to request the
                password if one is required for the negotiated
                authentication method.
                
   For TCP/IP TELNET connections, which are in NVT (ASCII) mode by
   default:
   
   SET LOGIN USERID name
          If a name is given, it sent to host during Telnet negotiations;
          if this switch is given but the string is omitted, no user ID
          is sent to the host. If this command is not given, your current
          USERID value, \v(userid), is sent. When a userid is sent to the
          host it is a request to login as the specified user.
          
   SET LOGIN PASSWORD password
          If a is given, it is treated as the password to be used (if
          required) by any Telnet Authentication protocol (Kerberos
          Ticket retrieval, Secure Remote Password (SRP), or X.509
          certificate private key decryption.) If no password is
          specified a prompt is issued to request the password if one is
          required for the negotiated authentication method.
          
   SET TELNET AUTHENTICATION TYPE -
          {AUTOMATIC, KERBEROS_IV, KERBEROS_V, NTLM, SSL, SRP, NONE } [ {
          ... } ... ]
          AUTOMATIC allows the host to choose the preferred type of
          authentication. Other values allow a specific authentication
          method to be used. AUTOMATIC is the default. Available options
          can vary depending on configuration; type SET TELNET
          AUTHENTICATION TYPE ? for a list.
          
          When the type is AUTOMATIC and Kermit is accepting incoming
          connections the supported authentication methods will be
          offered in the following order:
          
         1. NTLM (windows only)
         2. Kerberos 5
         3. Kerberos 4
         4. Secure Remote Password
         5. SSL
            This is the equivalent of the command:

  SET TELNET AUTH TYPE NTLM KRB5 KRB4 SRP SSL
        SET TELNET AUTHENTICATION FORWARDING { ON, OFF }
            Set this to ON to forward Kerberos V ticket-granting-tickets
            to the host after authentication is complete. OFF by default.
        SET TELNET AUTHENTICATION ENCRYPT-FLAG { ANY, NONE, TELOPT }
            Use this command to specify which AUTH telopt encryption
            flags may be accepted in client mode or offered in server
            mode. The default is ANY.
        SET TELNET AUTHENTICATION HOW-FLAG { ANY, ONE-WAY, MUTUAL }
            Use this command to specify which AUTH telopt how flags may
            be accepted in client mode or offered in server mode. The
            default is ANY.
        SET TELNET BINARY-TRANSFER-MODE { ON, OFF }
            Set this command to ON if you want to force Kermit to
            negotiate Telnet Binary in both directions when performing
            file transfers. Default is OFF. Alias SET TELNET
            BINARY-XFER-MODE.
        SET TELNET BUG BINARY-ME-MEANS-U-TOO { ON, OFF }
            Set this to ON to try to overcome TELNET binary-mode
            misnegotiations by C-Kermit's TELNET partner.
        SET TELNET BUG BINARY-U-MEANS-ME-TOO { ON, OFF }
            Set this to ON to try to overcome TELNET binary-mode
            misnegotiations by C-Kermit's TELNET partner.
        SET TELNET BUG INFINITE-LOOP-CHECK { ON, OFF }
            Set this to ON to prevent Kermit from responding to a telnet
            negotiation sequence that enters an infinite loop. The
            default is OFF because this should never occur.
        SET TELNET BUG SB-IMPLIES-WILL-DO { ON, OFF }
            Set this to ON to allow Kermit to respond to telnet
            sub-negotiations if the peer forgets to respond to WILL with
            DO or to DO with WILL before sending a SB (subnegotiation).
        SET TELNET DEBUG ON
            Displays all TELNET negotiations in full detail.
        SET TELNET DELAY-SB { ON, OFF }
            When ON, telnet subnegotiation responses are delayed until
            after all authentication and encryption options are either
            successfully negotiated or refused. This ensures that private
            data is protected. When OFF, telnet subnegotiation responses
            are sent immediately. The default is ON.
        SET TELNET ECHO { LOCAL, REMOTE }
            C-Kermit's initial echoing state for TELNET connections,
            LOCAL by default. After the connection is made, TELNET
            negotiations determine the echoing.
        SET TELNET ENCRYPTION TYPE { AUTOMATIC, CAST128_CFB64,
            CAST128_OFB64,CAST5_40_CFB64, CAST5_40_OFB64, DES_CFB64,
            DES_OFB64, DES3_CFB64, DES3_OFB64, NONE }
            AUTOMATIC allows the host to choose the preferred type of
            encryption. Other values allow a specific encryption method
            to be specified. AUTOMATIC is the default. The list of
            options will vary depending on the encryption types selected
            at compilation time. When the type is AUTOMATIC and Kermit is
            accepting incoming connections the supported encryption
            methods will be offered in the following order:

  DES3_CFB64
  CAST128_CFB64
  DES_CFB64
  CAST5_40_CFB64
  DES3_OFB64
  CAST128_OFB64
  DES_OFB64
  CAST5_40_OFB64
        SET TELNET ENVIRONMENT [ USERVAR ] { variable-name [ value ] }
            This feature lets Kermit send the values of certain
            environment variables to the other computer if it asks for
            them. The variable-name can be any of the "well-known"
            variables "USER", "JOB", "ACCT", "PRINTER", "SYSTEMTYPE", or
            "DISPLAY". The default values are taken from your
            environment; use this command to change or remove them. If
            USERVAR is specified you can include any non-standard
            environment variables.
            The most commonly used variables and their default values
            are:
            
              USER:
                      Telnet servers that request this value will use it
                      as the name of the account to be accessed and will
                      therefore not prompt you for a username. If a
                      password is required to access the specified user's
                      account only the password prompt will be issued.
                      The default value is the name of the user on the
                      local machine. This value may also be set with the
                      command SET LOGIN USER name.
                      
              DISPLAY:
                      This variable is used to specify the location of
                      the X Windows Server to be used by X Windows client
                      applications executed on the remote host. This
                      value is used by three telnet options: ENVIRONMENT,
                      XDISPLOC, and FORWARD-X. The default value is
                      retrieved from the value of the DISPLAY environment
                      variable in the local environment.
                      
              PRINTER:
                      This variable is used to specify the location of
                      the LPR printer to be used for printing files on
                      the host. This variable is not set by default.
                      
              SYSTEM:
                      This variable is used to specify the operating
                      system type of the local machine. The default value
                      is determined by Kermit. Typical values are "UNIX",
                      "VMS", "WIN32", and "OS2".
                      
            See [48]RFC1572 for further details.
        SET TELNET LOCATION [ text ]
            Location string to send to the Telnet server if it asks. By
            default this is picked up from the LOCATION environment
            variable. Give this command with no text to disable this
            feature. This string is sent either by using the SNDLOC
            option or as USERVAR "LOCATION" within the NEW-ENV option.
        SET TELNET NEWLINE-MODE { NVT, BINARY-MODE } { OFF, ON, RAW }
            Determines how carriage returns are handled on TELNET
            connections. There are separate settings for NVT (ASCII) mode
            and binary mode. ON (default for NVT mode) means CRLF
            represents CR. OFF means CR followed by NUL represents CR.
            RAW (default for BINARY mode) means CR stands for itself.
        SET TELNET PROMPT-FOR-USERID prompt
            Specifies a custom prompt to be used when prompting for a
            userid. Kermit will prompt for a userid if "set login userid
            {}" has been issued prior to a telnet authentication
            negotiation for an authentication type that requires the
            transmission of a name. (e.g. Secure Remote Password).
        SET TELNET REMOTE-ECHO { ON, OFF }
            Applies only to incoming connections created with: "set host
            * port /telnet". This command determines whether Kermit will
            actually echo characters received from the remote when it has
            negotiated to do so. The default is ON. Remote echoing may be
            turned off when it is necessary to read a password with the
            INPUT command.
        SET TELNET SFU-COMPATIBILITY-MODE { ON, OFF }
            Turns on the SFUTLNTVER and SFUTLNTMODE environment variables
            for use on connections to Microsoft's Services for Unix and
            Windows 2000 Telnet Servers.
        SET TELNET TERMINAL-TYPE name
            The terminal type to send to the remote TELNET host. If none
            is given, your current SET TERMINAL TYPE value is sent, e.g.
            VT220.
        SET TELNET TRANSFER-MODE { ON, OFF }
            When ON (OFF by default) and BINARY negotiations are not
            REFUSED Kermit will attempt to negotiate BINARY mode in each
            direction before the start of each file transfer. After the
            transfer is complete BINARY mode will be restored to the
            pre-transfer state.
        SET TELNET WAIT-FOR-NEGOTIATIONS { ON, OFF }
            Each Telnet option must be fully negotiated either On or Off
            before the session can continue. This is especially true with
            options that require subnegotiations such as Authentication,
            Encryption, and Kermit; for proper support of these options
            Kermit must wait for the negotiations to complete. Of course,
            Kermit has no way of knowing whether a reply is delayed or
            not coming at all, and so will wait forever before continuing
            the session. If you know that Kermit's Telnet partner will
            not be sending the required replies, you should instruct
            Kermit to REFUSE specific options with the SET TELOPT
            command. If you do not know which command the host is not
            responding to set this option of OFF.
            [ [49]C-Kermit ] [ [50]Kermit 95 ] [ [51]Kermit Home ]
    ________________________________________________________________________
  
  5. DIAGNOSING AND FIXING PROBLEMS CONNECTING TO TELNET SERVERS
            [ [52]Top ] [ [53]Contents ] [ [54]Previous ]
            SECTION CONTENTS

  5.1.  [55]BUG: Telnet Server does not respond to telnet options.
  5.2.  [56]BUG: Server sends a subnegotiation without negotiating the option
  5.3.  [57]BUG: Server sends DO TERM_TYPE but then never asks for the terminal
 type.
  5.4.  [58]BUG: Server negotiates BINARY mode in one direction but uses it in
both.
  5.5.  [59]PROBLEM: Long login times
  5.6.  [60]PROBLEM: The Telnet Server skips "login:" prompt
  5.7.  [61]BUG: The host echos input but never negotiates WILL ECHO
  5.8.  [62]BUG: BSDI BSD/OS 3.1 Telnetd improperly implements WILL BINARY mode
  5.9.  [63]PROBLEM: The host supports Telnet AUTH but you wish to login manual
ly
  5.10. [64]PROBLEM:  Applications on the host are unable to open the X Windows
 DISPLAY
  5.11. [65]PROBLEM: The Telnet Server is the Microsoft Windows 2000 Telnet Ser
vice
  5.12. [66]PROBLEM: The Telnet Server is Seattle Lab's SLNet Telnet Server for
 NT
            After we replaced the Telnet engine and added support for the
            new functionality we found many Telnet servers that do not
            adhere to the Telnet protocol as described in the IETF RFCs.
            Here are some of the most common bugs and the workarounds
            that Kermit provides the user to avoid them.
            [ [67]C-Kermit ] [ [68]Kermit 95 ] [ [69]Kermit Home ]
      ______________________________________________________________________
    
    5.1 BUG: Telnet Server does not respond to telnet options.
            [ [70]Top ] [ [71]Contents ] [ [72]Section Contents ] [
            [73]Next ]
            
              Description:
                      The telnet protocol requires that all initial
                      requests for action (WILL or DO) must be responded
                      to either in the affirmative (DO or WILL) or in the
                      negative (DONT or WONT). A negative response is
                      required for all unrecognized options. A failure to
                      respond to a Telnet option may result in the peer
                      waiting forever.
                      
                      This behavior is known to exist in the following
                      telnet servers:
                      
                    # AOS/VS II Release 2.20.00.39
                    # IBM OS/2 Warp 4.0 (all versions not configured with
                      authentication modules)
                      
              Symptom:
                      Kermit connects to the host, waits two minutes, and
                      then reports a telnet protocol error followed by
                      the list of outstanding negotiations. Kermit has
                      sent a Telnet option such as WILL AUTH and is
                      waiting for the required response which never
                      comes. In C-Kermit you will see "Negotiations...."
                      with many dots. In K95 you will see the "spinner"
                      twirl.
                      
                      Example:
                      
  DNS Lookup...  Trying xxx.xxx.xxx.xxx...  Reverse DNS Lookup... (OK)
  Negotiations... ?Telnet Protocol Timeout
  ?Telnet waiting for response to WILL TERMINAL-TYPE
  ?Telnet waiting for response to WILL NAWS
  ?Telnet waiting for response to WILL AUTHENTICATION
  ?Telnet waiting for response to WILL NEW-ENVIRONMENT

  **** AOS/VS II  Release 2.20.00.39 / Press NEW-LINE to begin logging on ****

  Too slow - input timed out

              Workaround:
                      For each of the telnet options listed as missing a
                      response issue a
                      
  SET TELOPT option REFUSED [ REFUSED ]

                      command. For instance:
                      
  SET TELOPT TERMINAL-TYPE REFUSED
  SET TELOPT NAWS REFUSED
  SET TELOPT AUTHENTICATION REFUSED
  SET TELOPT NEW-ENVIRONMENT REFUSED

            [ [74]C-Kermit ] [ [75]Kermit 95 ] [ [76]Kermit Home ]
      ______________________________________________________________________
    
    5.2 BUG: Server sends a subnegotiation without negotiating the option
            [ [77]Top ] [ [78]Contents ] [ [79]Section Contents ] [
            [80]Next ] [ [81]Previous ]
            
              Description:
                      The telnet protocol requires that subnegotiations
                      not be sent until the peers have agreed to WILL or
                      DO the specified option. All subnegotiations
                      received in a WONT or DONT state are to be ignored.
                      
              Symptom:
                      There are two possibilities. In the first, the host
                      sends a subnegotiation such as
                      
  IAC SB TERM_TYPE SEND IAC SE

                      without Kermit attempting to use the telnet option.
                      
  IAC WILL TERM_TYPE
  IAC DO TERM_TYPE

                      In this case the subnegotiation request will be
                      ignored and the subnegotiation response
                      
  IAC SB TERM_TYPE IS type IAC SE

                      will not be sent. How this affects the sender of
                      the illegal subnegotation is unknown.
                      
                      In the second scenario, Kermit sends
                      
  IAC WILL TERM_TYPE

                      But the host sends the subnegotiation without
                      responding to the request with:
                      
  IAC DO TERM_TYPE

                      This scenario degenerates into the previous bug.
                      (See "Telnet Server does not respond to telnet
                      options it does not recognize.")
                      
              Workaround:
                      For the first scenario, there is nothing that can
                      be done. Kermit is already ignoring the
                      subnegotiations and there is nothing that Kermit
                      can do to force the host to adhere to the protocol.
                      If you have a support contract with the maker of
                      the Telnet Server, file a report.
                      
                      For the second scenario, Kermit implements a
                      workaround which is on by default:
                      
 SET TELNET BUG SB-IMPLIES-WILL-DO ON

                      This causes Kermit to treat:
                      
  IAC SB TERM_TYPE SEND IAC SE

                      as if it were:
                      
  IAC WILL TERM_TYPE
  IAC SB TERM_TYPE SEND IAC SE
            [ [82]C-Kermit ] [ [83]Kermit 95 ] [ [84]Kermit Home ]
      ______________________________________________________________________
    
    5.3 BUG: Server sends DO TERM_TYPE but then never asks for the terminal
    type.
            [ [85]Top ] [ [86]Contents ] [ [87]Section Contents ] [
            [88]Next ] [ [89]Previous ]
            
              Description:
                      Although it is not required by the Telnet
                      Terminal-Type RFC, it makes sense that if a server
                      asks the client to negotiate the terminal type,
                      that it will actually go through with the
                      negotiation.
                      
              Symptom:
                      Kermit reports that Terminal Type negotiation is in
                      use but the terminal type is not configured
                      properly on the host.
                      
              Workaround:
                      There isn't much that can be done other than to
                      instruct Kermit to:
                      
  SET TELOPT TERMINAL-TYPE REFUSE

                      so it doesn't appear to the user that the terminal
                      type has indeed been negotiated.
                      
            [ [90]C-Kermit ] [ [91]Kermit 95 ] [ [92]Kermit Home ]
      ______________________________________________________________________
    
    5.4 BUG: Server negotiates BINARY mode in one direction but uses it in
    both.
            [ [93]Top ] [ [94]Contents ] [ [95]Section Contents ] [
            [96]Next ] [ [97]Previous ]
            
              Description:
                      When either the client or the server says it WILL
                      BINARY and the peer accepts, it is an indication
                      that CR is to be sent without a following NUL or LF
                      by the sender of WILL BINARY. A misunderstanding
                      about the meaning of this negotiation can prevent
                      files from being transfered as the packet lengths
                      and checksums will not match.
                      
              Symptom:
                      File transfers fail, reporting checksum or packet
                      length errors.
                      
              Workaround:
                      Use SET TERMINAL DEBUG ON to determine which
                      direction the host is negotiating BINARY mode in.
                      
                      Then use either:
                      
  SET TELNET BUG BINARY-ME-MEANS-U-TOO ON

              or:
                      
  SET TELNET BUG BINARY-U-MEANS-ME-TOO ON

                      to instruct Kermit to follow the broken behavior.
                      
            [ [98]C-Kermit ] [ [99]Kermit 95 ] [ [100]Kermit Home ]
      ______________________________________________________________________
    
    5.5 PROBLEM: Long login times
            [ [101]Top ] [ [102]Contents ] [ [103]Section Contents ] [
            [104]Next ] [ [105]Previous ]
            
              Description:
                      A connection is made to the Telnet Server but then
                      it takes 30 to 60 seconds for a login prompt, or
                      disconnects without displaying a prompt.
                      
              Symptom:
                      The host is trying to resolve a host name for the
                      IP Address assigned to your computer and is unable
                      to.
                      
              Workaround
                      Check with your network administrator or ISP to
                      make sure that the IP address you are using has a
                      valid DNS entry for reverse lookups (IP address to
                      name).
                      
            [ [106]C-Kermit ] [ [107]Kermit 95 ] [ [108]Kermit Home ]
      ______________________________________________________________________
    
    5.6 PROBLEM: The Telnet Server does not display a "login:" prompt
            [ [109]Top ] [ [110]Contents ] [ [111]Section Contents ] [
            [112]Next ] [ [113]Previous ]
            
              Description:
                      The server you are connecting to supports the
                      Telnet environment option and has been given your
                      username on the workstation during the telnet
                      option negotiations.
                      
              Workaround:
                      If your username on the workstation is not the same
                      as the username on the host, or if you are using a
                      script that requires a username or login prompt,
                      use the command:
                      
  SET TELNET ENVIRONMENT USER {}

              or:
                      
  SET LOGIN USERID {}

                      to specify your name on the host; or disable this
                      option with:
                      
  SET TELOPT NEW-ENVIRONMENT REFUSED
            [ [114]C-Kermit ] [ [115]Kermit 95 ] [ [116]Kermit Home ]
      ______________________________________________________________________
    
    5.7 BUG: The host echos input but never negotiates WILL ECHO
            [ [117]Top ] [ [118]Contents ] [ [119]Section Contents ] [
            [120]Next ] [ [121]Previous ]
            
              Description:
                      The Telnet protocol requires that all Telnet
                      options be in a state of I DONT and you WONT until
                      otherwise negotiated. That means that unless a host
                      says WILL ECHO it should not echo data; the client
                      should echo it locally.
                      
              Symptom:
                      Failure to follow the protocol definition can
                      result in no echoing or double echoing. This kind
                      of confusion has been seen with two well-known
                      sites:
                      
                    # The USA Library of Congress
                    # Dow Jones News Retrieval
                      
              Workaround:
                      SET TELNET ECHO REMOTE
                      SET TELOPT ECHO REFUSE
                      
            [ [122]C-Kermit ] [ [123]Kermit 95 ] [ [124]Kermit Home ]
      ______________________________________________________________________
    
    5.8 BUG: BSDI BSD/OS 3.1 Telnetd improperly implements WILL BINARY mode
            [ [125]Top ] [ [126]Contents ] [ [127]Section Contents ] [
            [128]Next ] [ [129]Previous ]
            
              Description:
                      The BSDI telnetd when it negotiaties WILL BINARY
                      (host to client) binary mode refuses to transmit CR
                      control characters. The man page for telnetd
                      states, "Binary mode has no common interpretation
                      except between similar operating systems (Unix in
                      this case)." The implementors clearly have misread
                      [130]RFC856 (TELNET BINARY TRANSMISSION) which
                      clearly states that the only affect that BINARY
                      mode has on the channel is to disable NVT (network
                      virtual terminal) handling of CR (CR no longer must
                      be followed by NUL if it is not followed by LF) and
                      that the 8th data bit must not be stripped.
                      
              Symptom:
                      By refusing to transmit CR control characters and
                      instead translating them to LF the BSDI telnetd
                      causes end of lines to be misinterpreted by the
                      terminal and for file transfers to become corrupted
                      if the host is allowed to negotiate WILL BINARY.
                      
              Workaround:
                      SET TELOPT BINARY ACCEPT REFUSE
                      
            [ [131]C-Kermit ] [ [132]Kermit 95 ] [ [133]Kermit Home ]
      ______________________________________________________________________
    
    5.9 PROBLEM: The host supports Telnet AUTH but you wish to login manually
            [ [134]Top ] [ [135]Contents ] [ [136]Section Contents ] [
            [137]Next ] [ [138]Previous ]
            
              Description:
                      You are using Kermit to connect to a host that
                      supports Telnet Authentication except you need to
                      login manually for one of the following reasons:
                      
                    # You do not have credentials that match the
                      supported Telnet AUTH type. For example, the host
                      supports Kerberos 5 but you do not have a principal
                      defined in the Kerberos realm even though you have
                      a valid account on the host.
                    # You wish to login to an Internet Kermit Service
                      anonymously.
                      
              Workaround:
                      SET TELOPT AUTH REFUSE
                      
                      To login anonymously, set the userid to anonymous.
                      This will force Kermit to refuse to authenticate.
                      
            [ [139]C-Kermit ] [ [140]Kermit 95 ] [ [141]Kermit Home ]
      ______________________________________________________________________
    
    5.10 PROBLEM: Applications on the host are unable to open the X Windows
    DISPLAY
            [ [142]Top ] [ [143]Contents ] [ [144]Section Contents ] [
            [145]Next ] [ [146]Previous ]
            
              Description:
                      Some applications such as the editor 'emacs' are
                      dual mode. They execute either in terminal mode or
                      as an X Windows client. If the application
                      terminates with an error that it is unable to open
                      the DISPLAY it could be for one of the following
                      reasons:
                      
                    # A DISPLAY environment variable is defined in the
                      shell's script that is executed at login and it
                      points to an invalid value;
                    # There is a DISPLAY environment variable defined on
                      the local machine which has been forwarded to the
                      host by Kermit and the specified DISPLAY is
                      unreachable.
                    # A SET TELNET ENVIRONMENT DISPLAY command was issued
                      prior to connecting to the host and the specified
                      DISPLAY value is invalid.
                      
              Workaround:
                      If you wish to use the application as an X Windows
                      client you must have a working X Windows Server
                      running on your local machine and specify a valid
                      DISPLAY string for your server. This can either be
                      specified on the host via:
                      
  export DISPLAY=host:display[.screen]

                      or by specifying the display in Kermit with the
                      command
                      
   SET TELNET ENVIRONMENT DISPLAY [host:]display[.screen]

                      If your telnet server supports any of the following
                      telnet options:
                      
                    # X-Display Location
                    # Environment Variables
                    # X-Windows Forwarding
                      
                      then Kermit will transmit the DISPLAY value to the
                      host during the initial telnet negotiations.
                      
                      If you wish to use the application in terminal mode
                      you can prevent Kermit from transmitting the local
                      DISPLAY value to the host by issuing the following
                      commands:
                      
  SET TELOPT XDISPLOC REFUSE
  SET TELOPT FORWARD-X REFUSE
  SET TELNET ENVIRONMENT DISPLAY
            [ [147]C-Kermit ] [ [148]Kermit 95 ] [ [149]Kermit Home ]
      ______________________________________________________________________
    
    5.11 PROBLEM: The Telnet Server is the Microsoft Windows 2000 Telnet
    Service
            [ [150]Top ] [ [151]Contents ] [ [152]Section Contents ] [
            [153]Next ] [ [154]Previous ]
            
              Description:
                      The Microsoft Windows 2000 (and NT Services for
                      Unix) Telnet Service is a bit of a challenge to
                      work with due to limitations that are imposed by
                      the Windows platform and the choices made by the
                      developers. The Telnet Service supports three
                      terminal emulations (ANSI, VT100, and VTNT) and two
                      types of end user login (Telnet AUTH NTLM and
                      plaintext domain\username/password.) Depending on
                      the choices that are made will determine the levels
                      of functionality that can be obtained for the
                      service.
                      
              Terminal types:
                      ANSI and VT100 are considered to be the same
                      terminal type by Microsoft even though they have
                      some very significant differences. The Microsoft
                      ANSI is closest to the Kermit 95 "ANSI-BBS" which
                      should be used in preference to VT100 when
                      communicating with this service. The VTNT terminal
                      type is Microsoft specific (and undocumented.)
                      Kermit 95 implements a reverse engineered
                      implementation. VTNT uses raw Win32 data structures
                      to implement transmission of screen snapshots from
                      the service to the client; and keystroke events
                      from the client to the service. VTNT is the
                      preferred terminal type to use with the Microsoft
                      Telnet service provided that you do not need access
                      to Kermit 95 keyboard verbs or any form of
                      scripting. If Keyboard verbs or scripting are
                      required ANSI or VT100 must be used.
                      
                      When using ANSI or VT100 the Backspace key must
                      send BS and not DEL.
                      
                      ANSI and VT100 do not support color whereas VTNT
                      does.
                      
                      VTNT supports Unicode characters. ANSI and VT100
                      only support the local ANSI code page. You must
                      configure the Kermit local and remote character
                      sets to properly convert between ANSI code pages.
                      
              End user login:
                      The Microsoft provides two forms of end user login.
                      The first is via the use of "login:" and
                      "password:" prompts. The username is either the
                      name of a user with a local account; or a
                      domain\name which specifies a user with an account
                      in the provided domain. Since the login is
                      performed over an unencrypted channel the password
                      is easily stolen by monitoring the local network
                      traffic.
                      
                      The second method is a proprietary (and
                      undocumented) Telnet authentication method based
                      upon the NT Lan Manager (NTLM) protocol. This
                      protocol has also been reverse engineered and
                      implemented in Kermit 95. NTLM does not produce a
                      shared secret that can be used for encrypting the
                      connection. NTLM can only be implemented on Windows
                      9x, NT, or Windows 2000 so connections from other
                      operating systems must use plaintext logins.
                      
                      If NTLM is used, the user can only log into the
                      service with the identity they are logged into the
                      local workstation. If another username is desired
                      NTLM must be disabled on the client (SET TELOPT
                      AUTH REFUSE). [K95 1.1.20 only]
                      
                      Other quirks:
                      
                    # The Microsoft Telnet Service implements Telnet NAWS
                      (Negotiate About Window Size) but only listens to
                      it when the connection is initially established.
                      This has two side effects when used with Kermit.
                      First, the Telnet Service may completely ignore the
                      screen size reported by Kermit if it is not sent
                      immediately after the Telnet Service agrees to use
                      NAWS. Second, the Telnet Service will not recognize
                      changes to the screen size after the connection is
                      established.
                    # The Microsoft Telnet Service does not create a
                      proper environment for the end user. The user's
                      profile, home directory and environment variables
                      are not loaded onto the system. Applications that
                      require this information may fail to execute or
                      otherwise run incorrectly.
                    # The Microsoft Telnet Service only allows a single
                      telnet session to be running at any one time.
                    # The Microsoft Telnet Service provides no mechansim
                      for performing file transfers.
                    # The Microsoft Telnet Service performs its job by
                      taking snapshots of the console's active virtual
                      window. This means that it is possible for data to
                      be lost due to scrolling or other screen updates
                      between snapshots. This can play havoc with scripts
                      and prevents Kermit from being able to store data
                      into its scrollback buffers.
                    # If the NTLM authentication feature is disabled in
                      the registry, the Telnet Server will not respond to
                      authentication requests causing the bug entitled
                      Telnet Server does not respond to telnet options.
                      
              Recommendations:
                      If using Kermit 95 and scripts are not required:
                      
  SET TERMINAL TYPE VTNT
  SET TELNET DELAY-SB OFF
  SET KEY \264 \8

                      If scripts are required:
                      
  SET TERMINAL TYPE ANSI
  SET TELNET DELAY-SB OFF
  SET KEY \264 \8

                      If the Telnet Server has NTLM authentication
                      disabled use the command:
                      
  SET TELOPT AUTH REFUSE

              or:
                      
  TELNET /AUTH:none host

                      If you are using C-Kermit:
                      
  SET TELNET TERMINAL ANSI
  SET TELNET DELAY-SB OFF
            [ [155]C-Kermit ] [ [156]Kermit 95 ] [ [157]Kermit Home ]
      ______________________________________________________________________
    
    5.12 PROBLEM: The Telnet Server is Seattle Lab's SLNet Telnet Server for NT
            [ [158]Top ] [ [159]Contents ] [ [160]Section Contents ] [
            [161]Previous ]
            Version 2.5 of the SLNet Telnet Server violates serveral IETF
            RFCs which hamper the interoperability of SLNet with
            conforming Telnet client implementations.
            
              Problem 1:
                      The SLNet Telnet Server negotiates a Telnet AUTH
                      TYPE (99) which has not been requested from nor
                      registered with [162]IANA. All telnet option and
                      sub-option values MUST be approved and issued by
                      IANA in order to facilitate interoperability among
                      products distributed by developers from all over
                      the world.
                      
                      When Kermit refuses to perform authentication using
                      the unknown method, the SLNet Telnet Server does
                      not respond to the refusal:
                      
  TELNET SENT WILL AUTHENTICATION
  TELNET RCVD DO AUTHENTICATION
  TELNET RCVD SB AUTHENTICATION SEND UNKNOWN=99 CLIENT_TO_SERVER|MUTUAL=2 IAC S
E
  TELNET SENT SB AUTHENTICATION IS NULL NULL IAC SE
  TELNET SENT WONT AUTHENTICATION

              Problem 2:
                      As per [163]RFC 855, Telnet requires a default WONT
                      or DONT response for any telnet option that is not
                      supported or recognized. The SLNet Telnet server
                      does not respond in either an affirmative or
                      negative manner to
                      

  IAC WILL NEW-ENVIRONMENT

              The Telnet Server also does not respond to
                      
  IAC WILL ENCRYPTION
  IAC DO ENCRYPTION
  IAC WILL KERMIT
  IAC DO KERMIT
  IAC DO FORWARD_X
  IAC WILL COM-PORT-CONTROL

              when initiated by the telnet client.
                      
              Problem 3:
                      The SLNet Telnet responds to a request to perform
                      Window Size negotiations with the wrong negative
                      response.
                      
  TELNET SENT WILL NAWS
  TELNET RCVD WONT NAWS

                      The proper response is:
                      
  TELNET RCVD DONT NAWS

              Problem 4:
                      The SLNet Telnet Server does not keep track of the
                      state of Telnet Options and transmits requests for
                      Telnet Option state changes that have already been
                      agreed to. In particular, the SLNet server
                      retransmits
                      
  TELNET SENT DO BINARY
  TELNET SENT WILL ECHO
  TELNET SENT WILL BINARY

                      after these negotiations were already agreed to. As
                      per [164]RFC 855, a telnet option state command
                      (WILL, WONT, DO, DONT) MUST NOT be sent unless it
                      results in a change of state. [165]RFC 1143 "The Q
                      Method of Implementing Telnet Option Negotiation"
                      provides extensive hints on how to properly
                      construct a telnet state machine to adhere to the
                      rules of the Telnet protocol.
                      
              Workaround:
                      To enable Kermit to establish a connection to this
                      very broken server Kermit must be told to:
                      
  SET TELOPT AUTHENTICATION REFUSE
  SET TELOPT KERMIT REFUSE REFUSE
  SET TELOPT NEW-ENVIRONMENT REFUSE
  SET TELOPT NAWS REFUSE
  SET TELOPT FORWARD-X REFUSE
  SET TELOPT COM-PORT-CONTROL REFUSE
            [ [166]C-Kermit ] [ [167]Kermit 95 ] [ [168]Kermit Home ]
              ________________________________________________________
            
            
    C-Kermit 8.0 Telnet / Columbia University / kermit@columbia.edu / 12
    November 2001

References

   1. http://www.columbia.edu/kermit/telnet80.html#intro
   2. http://www.columbia.edu/kermit/telnet80.html#options
   3. http://www.columbia.edu/kermit/telnet80.html#managing
   4. http://www.columbia.edu/kermit/telnet80.html#summary
   5. http://www.columbia.edu/kermit/telnet80.html#problems
   6. http://www.columbia.edu/kermit/telnet80.html#top
   7. http://www.columbia.edu/kermit/telnet80.html#contents
   8. http://www.columbia.edu/kermit/telnet80.html#options
   9. ftp://ftp.isi.edu/in-notes/rfc854.txt
  10. http://www.columbia.edu/kermit/ckermit.htm
  11. http://www.columbia.edu/kermit/k95next.html
  12. http://www.columbia.edu/kermit/cuiksd.html
  13. http://www.columbia.edu/kermit/ckermit.html
  14. http://www.columbia.edu/kermit/k95.html
  15. http://www.columbia.edu/kermit/index.html
  16. http://www.columbia.edu/kermit/telnet80.html#top
  17. http://www.columbia.edu/kermit/telnet80.html#contents
  18. http://www.columbia.edu/kermit/telnet80.html#managing
  19. http://www.columbia.edu/kermit/telnet80.html#intro
  20. ftp://ftp.isi.edu/in-notes/rfc2941.txt
  21. ftp://ftp.isi.edu/in-notes/rfc856.txt
  22. ftp://ftp.isi.edu/in-notes/rfc2217.txt
  23. ftp://ftp.isi.edu/in-notes/rfc857.txt
  24. ftp://ftp.isi.edu/in-notes/rfc2946.txt
  25. ftp://ftp.isi.edu/in-notes/rfc2840.txt
  26. ftp://ftp.isi.edu/in-notes/rfc727.txt
  27. ftp://ftp.isi.edu/in-notes/rfc1073.txt
  28. ftp://ftp.isi.edu/in-notes/rfc1572.txt
  29. ftp://ftp.isi.edu/in-notes/rfc779.txt
  30. http://search.ietf.org/internet-drafts/draft-ietf-tn3270e-telnet-tls-05.txt
  31. ftp://ftp.isi.edu/in-notes/rfc858.txt
  32. ftp://ftp.isi.edu/in-notes/rfc1091.txt
  33. ftp://ftp.isi.edu/in-notes/rfc1096.txt
  34. http://www.columbia.edu/kermit/ckermit.html
  35. http://www.columbia.edu/kermit/k95.html
  36. http://www.columbia.edu/kermit/index.html
  37. http://www.columbia.edu/kermit/telnet80.html#top
  38. http://www.columbia.edu/kermit/telnet80.html#contents
  39. http://www.columbia.edu/kermit/telnet80.html#summary
  40. http://www.columbia.edu/kermit/telnet80.html#options
  41. http://www.columbia.edu/kermit/ckermit.html
  42. http://www.columbia.edu/kermit/k95.html
  43. http://www.columbia.edu/kermit/index.html
  44. http://www.columbia.edu/kermit/telnet80.html#top
  45. http://www.columbia.edu/kermit/telnet80.html#contents
  46. http://www.columbia.edu/kermit/telnet80.html#problems
  47. http://www.columbia.edu/kermit/telnet80.html#managing
  48. ftp://ftp.isi.edu/in-notes/rfc1572.txt
  49. http://www.columbia.edu/kermit/ckermit.html
  50. http://www.columbia.edu/kermit/k95.html
  51. http://www.columbia.edu/kermit/index.html
  52. http://www.columbia.edu/kermit/telnet80.html#top
  53. http://www.columbia.edu/kermit/telnet80.html#contents
  54. http://www.columbia.edu/kermit/telnet80.html#summary
  55. http://www.columbia.edu/kermit/telnet80.html#x1
  56. http://www.columbia.edu/kermit/telnet80.html#x2
  57. http://www.columbia.edu/kermit/telnet80.html#x3
  58. http://www.columbia.edu/kermit/telnet80.html#x4
  59. http://www.columbia.edu/kermit/telnet80.html#x5
  60. http://www.columbia.edu/kermit/telnet80.html#x6
  61. http://www.columbia.edu/kermit/telnet80.html#x7
  62. http://www.columbia.edu/kermit/telnet80.html#x8
  63. http://www.columbia.edu/kermit/telnet80.html#x9
  64. http://www.columbia.edu/kermit/telnet80.html#x10
  65. http://www.columbia.edu/kermit/telnet80.html#x11
  66. http://www.columbia.edu/kermit/telnet80.html#x12
  67. http://www.columbia.edu/kermit/ckermit.html
  68. http://www.columbia.edu/kermit/k95.html
  69. http://www.columbia.edu/kermit/index.html
  70. http://www.columbia.edu/kermit/telnet80.html#top
  71. http://www.columbia.edu/kermit/telnet80.html#contents
  72. http://www.columbia.edu/kermit/telnet80.html#x5
  73. http://www.columbia.edu/kermit/telnet80.html#x5.2
  74. http://www.columbia.edu/kermit/ckermit.html
  75. http://www.columbia.edu/kermit/k95.html
  76. http://www.columbia.edu/kermit/index.html
  77. http://www.columbia.edu/kermit/telnet80.html#top
  78. http://www.columbia.edu/kermit/telnet80.html#contents
  79. http://www.columbia.edu/kermit/telnet80.html#x5
  80. http://www.columbia.edu/kermit/telnet80.html#x5.3
  81. http://www.columbia.edu/kermit/telnet80.html#x5.1
  82. http://www.columbia.edu/kermit/ckermit.html
  83. http://www.columbia.edu/kermit/k95.html
  84. http://www.columbia.edu/kermit/index.html
  85. http://www.columbia.edu/kermit/telnet80.html#top
  86. http://www.columbia.edu/kermit/telnet80.html#contents
  87. http://www.columbia.edu/kermit/telnet80.html#x5
  88. http://www.columbia.edu/kermit/telnet80.html#x5.4
  89. http://www.columbia.edu/kermit/telnet80.html#x5.2
  90. http://www.columbia.edu/kermit/ckermit.html
  91. http://www.columbia.edu/kermit/k95.html
  92. http://www.columbia.edu/kermit/index.html
  93. http://www.columbia.edu/kermit/telnet80.html#top
  94. http://www.columbia.edu/kermit/telnet80.html#contents
  95. http://www.columbia.edu/kermit/telnet80.html#x5
  96. http://www.columbia.edu/kermit/telnet80.html#x5.5
  97. http://www.columbia.edu/kermit/telnet80.html#x5.3
  98. http://www.columbia.edu/kermit/ckermit.html
  99. http://www.columbia.edu/kermit/k95.html
 100. http://www.columbia.edu/kermit/index.html
 101. http://www.columbia.edu/kermit/telnet80.html#top
 102. http://www.columbia.edu/kermit/telnet80.html#contents
 103. http://www.columbia.edu/kermit/telnet80.html#x5
 104. http://www.columbia.edu/kermit/telnet80.html#x5.6
 105. http://www.columbia.edu/kermit/telnet80.html#x5.4
 106. http://www.columbia.edu/kermit/ckermit.html
 107. http://www.columbia.edu/kermit/k95.html
 108. http://www.columbia.edu/kermit/index.html
 109. http://www.columbia.edu/kermit/telnet80.html#top
 110. http://www.columbia.edu/kermit/telnet80.html#contents
 111. http://www.columbia.edu/kermit/telnet80.html#x5
 112. http://www.columbia.edu/kermit/telnet80.html#x5.7
 113. http://www.columbia.edu/kermit/telnet80.html#x5.5
 114. http://www.columbia.edu/kermit/ckermit.html
 115. http://www.columbia.edu/kermit/k95.html
 116. http://www.columbia.edu/kermit/index.html
 117. http://www.columbia.edu/kermit/telnet80.html#top
 118. http://www.columbia.edu/kermit/telnet80.html#contents
 119. http://www.columbia.edu/kermit/telnet80.html#x5
 120. http://www.columbia.edu/kermit/telnet80.html#x5.8
 121. http://www.columbia.edu/kermit/telnet80.html#x5.6
 122. http://www.columbia.edu/kermit/ckermit.html
 123. http://www.columbia.edu/kermit/k95.html
 124. http://www.columbia.edu/kermit/index.html
 125. http://www.columbia.edu/kermit/telnet80.html#top
 126. http://www.columbia.edu/kermit/telnet80.html#contents
 127. http://www.columbia.edu/kermit/telnet80.html#x5
 128. http://www.columbia.edu/kermit/telnet80.html#x5.9
 129. http://www.columbia.edu/kermit/telnet80.html#x5.7
 130. ftp://ftp.isi.edu/in-notes/rfc856.txt
 131. http://www.columbia.edu/kermit/ckermit.html
 132. http://www.columbia.edu/kermit/k95.html
 133. http://www.columbia.edu/kermit/index.html
 134. http://www.columbia.edu/kermit/telnet80.html#top
 135. http://www.columbia.edu/kermit/telnet80.html#contents
 136. http://www.columbia.edu/kermit/telnet80.html#x5
 137. http://www.columbia.edu/kermit/telnet80.html#x5.10
 138. http://www.columbia.edu/kermit/telnet80.html#x5.8
 139. http://www.columbia.edu/kermit/ckermit.html
 140. http://www.columbia.edu/kermit/k95.html
 141. http://www.columbia.edu/kermit/index.html
 142. http://www.columbia.edu/kermit/telnet80.html#top
 143. http://www.columbia.edu/kermit/telnet80.html#contents
 144. http://www.columbia.edu/kermit/telnet80.html#x5
 145. http://www.columbia.edu/kermit/telnet80.html#x5.11
 146. http://www.columbia.edu/kermit/telnet80.html#x5.9
 147. http://www.columbia.edu/kermit/ckermit.html
 148. http://www.columbia.edu/kermit/k95.html
 149. http://www.columbia.edu/kermit/index.html
 150. http://www.columbia.edu/kermit/telnet80.html#top
 151. http://www.columbia.edu/kermit/telnet80.html#contents
 152. http://www.columbia.edu/kermit/telnet80.html#x5
 153. http://www.columbia.edu/kermit/telnet80.html#x5.12
 154. http://www.columbia.edu/kermit/telnet80.html#x5.10
 155. http://www.columbia.edu/kermit/ckermit.html
 156. http://www.columbia.edu/kermit/k95.html
 157. http://www.columbia.edu/kermit/index.html
 158. http://www.columbia.edu/kermit/telnet80.html#top
 159. http://www.columbia.edu/kermit/telnet80.html#contents
 160. http://www.columbia.edu/kermit/telnet80.html#x5
 161. http://www.columbia.edu/kermit/telnet80.html#x5.10
 162. http://www.iana.org/
 163. ftp://ftp.isi.edu/in-notes/rfc855.txt
 164. ftp://ftp.isi.edu/in-notes/rfc855.txt
 165. ftp://ftp.isi.edu/in-notes/rfc1143.txt
 166. http://www.columbia.edu/kermit/ckermit.html
 167. http://www.columbia.edu/kermit/k95.html
 168. http://www.columbia.edu/kermit/index.html