TELNET PROTOCOL IN C-KERMIT 8.0 AND KERMIT 95 2.0

Author:
Jeffrey Altman
The Kermit Project
Columbia University

Most recent update:
4 June 2002

[ Kermit Home ] [ C-Kermit Home ] [ Kermit 95 Home ]

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

[ Top ] [ Contents ] [ 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 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.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 woul