telnet.txt

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

  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


BUG: Server sends DO TERM_TYPE but then never asks for the terminal type.

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 that it doesn't appear to the user that the terminal type has
  indeed been negotiated.

BUG: Server negotiates BINARY mode in one direction but uses it in both.

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.


PROBLEM: 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.

Description:
  The host is trying to resolve a host name for the IP Address assigned to
  your computer and is unable to.  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).


PROBLEM: The Telnet Server does not display a "login:" or "Username:" prompt
  and instead immediately displays the "Password:" prompt.

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 {<username>}

  or:

    SET LOGIN USERID {<username>}

  to specify your name on the host; or disable this option with:

    SET TELOPT NEW-ENVIRONMENT REFUSED


BUG: The host echos input but never negotiates WILL ECHO.

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


BUG: BSDI BSD/OS 3.1 Telnetd improperly implements WILL BINARY mode.

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 RFC-856 (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 translate 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


PROBLEM:  The host supports Telnet AUTH but you wish to login manually

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


PROBLEM:  Applications on the host are unable to open the DISPLAY

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

PROBLEM: The Telnet Server is the Microsoft Windows 2000 Telnet Service

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 only works
  if the client machine shares the same domain (or security authority) as the
  machine the service is running on.  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).
  
  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.

  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 you are using Kermit 95 on a Windows platform and wish to login as
  a user other than yourself:

     SET TELOPT AUTH REFUSE

  or

     TELNET /AUTH:none <host>

  If you are using C-Kermit:

      SET TELNET TERMINAL ANSI
      SET TELNET DELAY-SB OFF

(End of TELNET.TXT)