C-Kermit 7.0 Case Study #12

[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]

Article: 11026 of comp.protocols.kermit.misc
From: [email protected] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Case Study #12: C-Kermit's Telnet Client
Date: 20 Jan 2000 23:23:13 GMT
Organization: Columbia University

These days it seems that blessings are always mixed. Everything's a tradeoff. The evolution of the Telnet protocol is no exception. Primarily to accommodate modern demands for security, the original simple protocol set forth in RFC854 (1983) is no longer sufficient. C-Kermit 7.0 includes a fully modern Telnet implementation, complete with tradeoffs.

On the plus side, the C-Kermit Telnet client can handle authentication securely using any of several different authentication methods; it can verify the identity of the host you are connecting to, and it can also encrypt your session and (more about all this in future installments).

On the minus side, initial connection can take a bit longer than before because there's more to negotiate, and because of the time taken by reverse Domain Name Service (DNS) lookups, which client and/or server might initiate. Sometimes connections can take a lot longer. The most common causes of long delays are:

The reverse DNS lookup done by the target host. If the computer you are Telnetting from is not registered in DNS, the host might wait a minute or two before deciding it's not going to get an answer to its DNS lookup. The same thing happens no matter what Telnet client you use. The only remedy is to ensure your computer is registered in DNS.
The reverse DNS lookup done by C-Kermit itself. As above but in the other direction. C-Kermit's lookup not only checks the host's identity but identifies which host you have actually reached in case the address you gave was that of a host pool. But if this service prevents you from making the connection at all, or makes the process intolerably slow, you can suppress it with SET TCP REVERSE-LOOKUP OFF; the tradeoff is that you might not know which host you actually reached.
The Telnet server is not replying to messages that require a reply. This tends to occur mainly with older Telnet servers, but also can happen with new ones that are improperly coded. In this case, Kermit eventually times out after several minutes and tells you what went wrong so you can fix or work around the problem. Or you can (at your own risk) include the new /NOWAIT switch in your TELNET or SET HOST command:
```
     C-Kermit> telnet /nowait oldmini.xyzcorp.com
```
The risk is that client and server might have conflicting ideas about certain parameters that are supposed to agree, which can result in fractured sessions (or worse if you are trying to make a secure connection; more about this in a future posting).

These hints should get you past any new difficulties you might have experienced when upgrading to C-Kermit 7.0 from prior versions. Of course there is much more to tell. C-Kermit's Telnet protocol interpreter has been entirely redesigned and recoded to handle most modern options and to give you total and detailed control over negotiation policies and actions for each option. It also offers expanded debugging capabilities for troubleshooting. The full story can be found in in the document Telnet Protocol in C-Kermit 7.0 and Kermit 95 1.1.19.

Before leaving the topic of Telnet, let's recall some of the advantages of C-Kermit over the regular System Telnet client on Unix, VMS, etc:

It is more configurable than System Telnet.
It can transfer files over the Telnet connection.
It can log the Telnet session.
It can translate character sets.
It can be scripted.
It can also be used for other kinds of connections.

And so on. Given the advantages, why not use C-Kermit as your only Telnet client? One answer might be "because the command-line syntax is different." For example, maybe you have a Web browser whose "helper" for Telnet links is hardwired to be System Telnet, with a command line like:

  telnet host [ port ]

No worries! C-Kermit 7.0 has a new feature called "command line personalities", one of which is "telnet". Watch this (Unix example):

  $ whereis telnet
  /usr/bin/telnet
  $ cd /usr/bin
  $ mv telnet systemtelnet
  $ ln -s /usr/local/bin/kermit telnet

(The same effect is achieved if you leave System Telnet alone, but place the telnet -> kermit link ahead of System Telnet in the PATH.)

Now C-Kermit *is* Telnet and it responds to the regular Telnet command line:

  telnet host [ port ]

as System Telnet would. And, like System Telnet, if you invoke it this way, it exits automatically when the connection is closed. But unlike Telnet, you can still use it to transfer files, execute scripts, and all the rest. For more information about command-line personalities, see Section 9.1 of ckermit2.txt.

Finally, a word about scripting Telnet connections. If the Telnet server supports the Telnet protocol feature that lets the client supply your user ID automatically, you might find that a login: (Username:, etc) prompt is not issued; the server goes straight to the Password prompt. Alternatively, (and even more confusingly) it might print the login or username prompt, but then fill in your username for you and then print the Password prompt. In case your script was not expecting such behavior, you can prevent C-Kermit from sending your user ID to the server by including the following command in your script:

  set login userid

before the SET HOST command that makes the connection (you'll also need to do this if your user ID on the target is not the same as your local one). Then your old script should work as before.

You can also recode any Telnet script to adapt automatically to the presence or absence of a login: (Username:) prompt using MINPUT rather than INPUT. For a sample C-Kermit 7.0 Telnet "Kerbang script", see the autotelnet script in the C-Kermit scripts library.

- Frank

[ Top ] [ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]

C-Kermit 7.0 / Columbia University / [email protected] / 20 Jan 2000