C-Kermit: More than a File Transfer Protocol
Jim Dennis
Recently I made some interesting discoveries. Kermit is a telnet client. It's also an rlogin client. Kermit scripts can control network as well as serial sessions - and with C-Kermit, file transfers can easily be done through those network sessions. At first I was embarrassed. My business is knowing things like this and showing them to my clients. Surely some of my fellow consultants and admins had been holding out on me. When I asked around, it seemed that everyone had heard of Kermit but hardly anyone knew about these new features. Most people seemed to think of Kermit as "the file transfer protocol to use when nothing else will work." Kermit is indeed a file transfer protocol, originally designed by Frank da Cruz and Bill Catchings in 1989 at Columbia University. Columbia University is still the home of the Kermit Project, and Frank da Cruz is the manager of Communications Software Development there. The C-Kermit package from Columbia University, however, is more. It is a full-featured communications package that is equally adept at working over network and serial connections. It is also a scripting language in the tradition of the best UNIX utilities. C-Kermit can be thought of as a communications command shell. As the Internet has become ubiquitous, and the BBS systems of the '80s have given way to the ISPs of this decade, I noticed that something as basic and simple as the old terminal connection had taken a giant step backward. The standard UNIX telnet client offers no scripting capability, no file transfers, no scrollback, and very limited logging, debugging, or line/connection control features. (Some of these features are there - in some clients - but they are buried and practically undocumented.) The fact that UNIX has traditionally used one protocol for network terminal sessions (telnet) and a different one for file transfers (ftp) is reasonable - most of the time. However it can be a real nuisance to switch between the two utilities, often having to re-login, change the ftp client to some directory, and constantly retype filenames (usually without the benefit of shell completion or even wild cards). Also many system administrators must regularly work through a maze of packet filters on systems with ftp and the various R commands disabled. Often the most convenient way to transfer a file between hosts is through the existing communications session. At the same time, modems and other serial communications devices aren't going away. As much as marketeers would like to convince us that everything will be "on the Web" by tomorrow - that we could forget those other, quaint, simple communications protocols - sys admins still use straight modem connections for quite a bit of work. In fact the first step in getting most PPP connnections configured is controlling a normal serial connection, either to a modem or through a null modem, to perform the initial configuration of routers, terminal servers, and other devices. Additionally, it should be fairly obvious that running PPP or SLIP over a connection is going to have a significant overhead during file transfers. This overhead is unecessary unless there are multiple processes that need to multiplex their access to the channel. Systems administrators need tools for network and serial communications that provide broadly overlapping features. The tools need to be available on a wide variety of different systems, and they need to offer scripting, logging, and debugging. We need to be able to integrate these tools with other utilities (e.g., to launch custom programs and open pipes to other processes). We also need tools with little learning overhead but enough depth that we won't outgrow them. We need tools that are robust enough to use when the machine and the network are practically in flames. Finally, we need tools that have a future, that will be ported to the next platform we have to support, and that will have support for the next protocol the Internet throws at us. C-Kermit possesses all of these qualities. The current version of C-Kermit (6.92) was just released at the end of last year. This version is available on more platforms than I've ever heard of and has been ported to at least six variants and versions of UNIX. C-Kermit in Heterogenous Environments and with Legacy Systems There are implementations of Kermit for everything from the IBM system 370 (MVS) platform all the way to my HP 48SX calculator (embedded in the ROMs). It's even been ported to platforms as recent as BeOS and as obscure as TSX-32. Columbia University has also released K-95 for Windows '95, NT, and OS/2. There is apparently a Mac version as well. This availability is important to the UNIX systems administrator because it allows an organization to standardize on one package and avoid unecessary retraining as new types of systems are introduced. K-95 offers the full graphical interface that Windows users demand while retaining compatibility with other implementations. Personally, I prefer the command shell approach of the UNIX versions. I suppose someone could create a TCL/Tk wrapper or front end to give UNIX C-Kermit a GUI. C-Kermit, on UNIX and UNIX-like platforms, doesn't include terminal emulation. This might seem odd at first - but it makes sense. Fundamentally, any interactive shell login to a UNIX system is a terminal. xterm is a terminal emulation. The virtual consoles of SCO, Linux, and FreeBSD are all treated as terminals. A telnet session on most systems conveys your $TERM environment setting and acts like a terminal. So C-Kermit for UNIX simply acts as a transparent, or semi-transparent shell. This allows you to use existing terminal settings and probably avoids a lot of portability issues. I mentioned that C-Kermit can be transparent or "semi-transparent" (translucent?). By default there are a couple of sequences that C-Kermit will "catch" as escapes. These sequences include the current command escape character, which defaults to "Ctrl-\" on most systems (that works like telnet's "Ctrl-]" or cu and rsh's ~). The others involve file transfers and "APC" (application program commands), which are like terminal escape sequences to set Kermit features. You can also set your own key translations (using the SET KEY command), and you can have C-Kermit provide a variety of international conversions using the SET TERMINAL CHARACTER-SET, SET FILE CHARACTER-SET, and SET TRANSFER CHARACTER-SET commands. The book Using C-Kermit has an entire chapter about international character set support. As communications, particularly Internet communications, continue to shrink our world, this support will be of increasing importance to all sys admins. The Advantages and Power of the Command Shell Approach Even if a GUI were available, I'd probably never use it. I prefer to type commands, knowing that sooner or later, I'll want to turn parts of that interactive session into a script. Not all command shells are created equal, however. C-Kermit's shell shows the considerable experience of its architects. You can abbreviate any command to the shortest nonambiguous form, and the most commonly used commands have single letter forms (c for connect, s for send, etc.). You can also type the ? key in the midst of any command to see a context sensitive completion list. This completion feature also works for filenames. Like most modern command shells, C-Kermit has a command history (recall buffer). This defaults to only 10 commands, but can be adjusted with the SET COMMAND RECALL command. The command recall and editing features are not nearly as involved as those offered by zsh, bash, or the Korn shell. There's no FCEDIT, and csh users may wish for some of their beloved "bang and caret" operators. These operators are not necessary, but it would be nice if there were an option to link with the GNU "readline" library. This would allow us to choose between vi and emacs command line editing and allow customization of C-Kermit's command prompt bindings. I would also like C-Kermit to allow me to redirect the command recall buffer to a file. I often use a shell command, such as history > new.script, to record something I've done and edit it into a script. Another feature I miss from my normal shell environment is having the {Tab} key do filename completion. A Typical C-Kermit Session When you've established a connection over C-Kermit, and you need to send a file to the remote end, you'd typically do something like:
$ kermit {start kermit on the local host}
[C-Kermit] ~$ telnet remote
{this is equivalent to SET NETWORK TYPE TCP/IP
SET HOST remote:telnet
CONNECT}
{logs in}
$ kr {ready remote to receive}
$ {Ctrl-\}c {escape to command mode}
[C-Kermit] ~$ cd ~/some/directory {use kermit commands
(local)}
[C-Kermit] ~/some/directory$ ls {find my file}
[C-Kermit] ~/some/directory$ !less some.file {view it}
[C-Kermit] ~/some/directory$ s some.file {send it}
[C-Kermit] ~/some/directory$ c {back to connect mode}
$ vi some.file {or whatever - on remote}
Note that Ctrl-\ is the default escape key to issue a command from connect mode. c is the connect mode command to change back to command mode. The escape key can be changed or disabled. Some people might prefer Ctrl-] - like telnet. I'll use Ctrl-\ throughout this discussion. This sequence shows that the cd and ls commands are available directly from within Kermit. The !less command shows a normal shell command that one might use to view the contents of a file before sending it. The kr at the beginning might be a shell alias or script on the remote system to do a kermit -r (receive). If you've ever had to suspend your telnet session, fire up an ftp, login, change directories, and type whole filenames, you'll appreciate this sort of "in session" file transfer. File/pathname completion at the remote shell prompt similar to that in bash or zsh would save even more time. As the example shows, it is quite easy to invoke local shell commands from C-Kermit's prompt. It is equally easy to define and invoke C-Kermit macros and to take in kermit scripts. C-Kermit as a Scripting Language With all the scripting languages for UNIX (e.g., Perl, Python, Tcl/Tk, elisp), you wouldn't think that anyone would dare mention another one. However C-Kermit's scripting syntax is really easier than most other languages. It is fairly similar to expect in some features, but has a very simple syntax. Listing 1 is a simple script to "beepme" (call a normal numeric pager) and send it a number. The first line is a typical UNIX "shebang" line (shell scripting specification). After that all of the lines that start with a semicolon or a hash sign are comments. There are lot of SET commands. Unlike most UNIX languages, C-Kermit is not case sensitive. The only things about C-Kermit's language that seem odd to me are: The IF statement uses prefix conditional operators, as in: IF < arg arg2. This is vaguely lisp-like and presumably prevents the need for parentheses and block delimiters. You don't need semicolons at the end of each line as you would with C. The \&@ and \v(args) and \$(HOME) represent the command arguments list, a preset variable (number of arguments), and a value from the environment ($HOME). There are a large number of \v() "preset" variables. Normal user variables can have any name. These are created with DEFINE commands and can have values assigned to them with the ASSIGN command.
#! /usr/local/bin/kermit
;; call a system
modem
dial antares
input 6 ogin:
output { jim\ }
connect
There is a more advanced script shown in Using C-Kermit that can be used to dial to an alphanumeric pager using the TAP protocol. Personally, I'm glad mine is just an old-fashioned numeric. This script just runs a "modem" macro (which at my site just does the appropriate SET DIAL METHOD, SET MODEM TYPE, SET LINE and other settings) and dials an entry from my dialing directory. It then waits for a login prompt for up to 6 seconds and automatically provides my login name if that is received. Then it connects my terminal (console, xterm or whatever) to the other system. When you install C-Kermit at your site you can create your own site-specific macros, such as the "modem" one I've shown here. These could be simple (this system only has one modem), or they could be complex. I've heard of sites that use out-dial capabilities on their terminal servers, so they act as modem pools. Overall, C-Kermit is a reasonably easy scripting language that is much easier to use than a combination of using expect to spawn and control a telnet or cu session. There may be some cases where you might run C-Kermit through an expect script - since expect/TCL is a more general purpose language. Calling system commands (including shell or Perl scripts) is trivial from within C-Kermit. It's also possible to open a pipe to external programs to read data from their output or feed data into them. C-Kermit as a telnet and rlogin Client To use kermit as a telnet client you can use a sequence of commands like: SET NET TYPE TCP, SET HOST hostname port, and CONNECT, or you can just use C-Kermit's internal telnet command. C-Kermit has numerous settings and options for controlling and debugging network connections - far too many for me to cover here. Another advantage of C-Kermit is that you can create your own network and services directories. This allows you to use short names for hosts (without having to put those names in your system's global /etc/hosts file). A services file is a combined dialing and network directory. Users of S/Key or OPIE (one-time password systems) may want to write a C-Kermit script to automate running the local client or to do a lookup on a challenge/response list. This may be appropriate if you trust the security on your local workstation but don't trust the path between it and your remote host. C-Kermit does not easily integrate with ssh (or any other encrypted telnet or rsh packages like stel or ssltelnet). After trying various tricks, I decided to simply use C-Kermit to telnet to my localhost, and use that telnet session to ssh to the remote. This takes a little extra memory and slows down the connection a little, but allows me to use C-Kermit scripts, to log the session, and to do file transfers through the encrypted link. IPv6, SKIP, and S/WAN protocols may eventually offer a better solution to these problems since the encryption and authentication will be done at the network layer. For now, this technique (opening a session to localhost and opening the application through that) should work with just about any of the encryption communications applications like ssh and ssltelnet. Dispelling the Myth about Kermit's Transfer Performance There is a persistent misconception that the Kermit transfer protocol is "slow" and "outmoded." It has a reputation for being the protocol you use when all else fails or when nothing else is available. Although I don't want to focus on file transfers for this article, that prejudice is worth addressing. The Kermit protocol is very robust. It was designed back when 300 baud modems were the rule - to work on equipment that we wouldn't use as door stops now. Unfortunately, many implementations of the protocol still default to settings that are inappropriate with today's high-speed, error-correcting modems, buffered UARTS, and reliable TCP connections. My suggestion is to add the FAST command to your .kermrc file and forget it. If you ever have a problem with a download, go to the C-Kermit command prompt and issue the ROBUST command. This debate is also made moot by C-Kermit's support for other protocols, including zmodem. So you can use whichever you prefer. C-Kermit Server Mode C-Kermit contains a feature whereby it can be configured as a "server." If you do this and use the Ctrl-\c to escape your connection, you can issue a variety of REMOTE commands to transfer files both ways, make directories, and generally manage files at each end of a connection. This isn't as pretty as using Midnight commander, but it may be useful in some cases (particularly if no "user level" ftp is available at the remote end or when working with non-UNIX systems). Frank da Cruz, co-creator of the Kermit protocol and head of the Kermit project at Columbia, tells me that the IANA has assigned a TCP port for running Kermit servers. Although this is unlikely to become as ubiquitous as http or ftp as an anonymous protocol, it might have advantages. On today's highly congested Internet backbones with chronic "router flap" and the other problems, there is an advantage to using a more robust file transfer protocol. ftp works well enough on reliable connections. However, most ftp clients and servers don't support retransmission (the REGET command). It can also be a pain to create and deploy a script that will let customers ftp a whole set of files. Will running a chroot'ed C-Kermit server in a secure configuration become a viable alternative to ftp? Only the future will tell. It will be interesting to see how Columbia configures its own server for this. C-Kermit, the Book Since UNIX users can get the package via ftp and install it with a full set of document files, it's natural to ask, "Why get the Book?" One reason is that C-Kermit is not a free or GPL product. It is part of an ongoing project at Columbia University that is supported by sales of the Using C-Kermit book by Frank da Cruz and Christine M. Gianone. Much of the material in this book covers aspects of telecommunications and networking that apply regardless of what software you use. I was particularly fascinated by the discussion of portable dialing entries and international dialing conventions. Some incredible workarounds are required in certain areas of the world. For those of us that communicate in heterogenous environments, with legacy systems, this book is perfect. It contains whole chapters and sections about transfers and connections with VMS and other systems. Conclusion C-Kermit is practically synonymous with connectivity. The addition of TCP/IP support brings a number of the features from traditional serial communications packages to our world of telnet and rlogin. C-Kermit provides a consistent way for sys admins to handle communications regardless of whether they are done via modem, null modem, or network connection. It will work on just about any imaginable UNIX system and is compatible with versions that run on most other platforms. With Columbia's continuing support and development, C-Kermit will likely be ported to new systems as they become available and that support new protocols and devices. I personally think that every professional sys admin should take a look at this book and get a copy of the package from Columbia University's Web site (http://www.columbia.edu/kermit).
About the AuthorJim Dennis jim@starshine.org is the proprietor of Starshine Technical Services http://www.starshine.org). He provides support and training to the system administrators for customers as large as the U.S. Government and as important as the individual Linux user.
|