Kermit - A Protocol for Painless Micro and Mini File... Brian Nelson Computer Services

Kermit - A Protocol for Painless Micro and Mini File... Brian Nelson Computer Services

Kermit - A Protocol for Painless Micro and Mini File Transfer

Brian Nelson

Computer Services

University of Toledo

2801 West Bancroft

Toledo, Ohio 43606


This article will describe the Kermit file transfer protocol.

This protocol allows many (if not most) types of computer systems to effect, at minimum, error free file transfer with other systems and microcomputers over asynchronous lines.


With the widespread use of personal computers the need for file exchange between systems has become of foremost concern among users and managers alike. There are many commercial products available which meet this need, some of which may offer more advanced functions such as transparent record oriented file access. Networks that do this, such as DECnet, can be expensive, and if your computer or microcomputer is not on the network your needs won't be met. Transfer of files with removable disks can work, but generally only when the computers are of the same type, it's not very useful when the systems are removed in location.

Rarely will a larger mini or supermini be able to read a microcomputer's disk.

A more realistic approach, from both cost and convenience, is to find a way to use ordinary telecommunications and/or in-house PBX systems to connect computers and microcomputers together. If a local connection using a PBX or front end switch is not available, there is always dialup access with standard 103/212 modems. Data can be transferred with very simple methods, such as TYPING a file on one system and capturing it on the other system, but this gives no protection from noise and overrun of data. It is not very user friendly either. What is really needed is a protocol to accomplish file transfer reliably and efficiently.

The first obvious use of any program or protocol designed to accomplish file transfer is to be able to provide the ability to support file uploads and downloads from minis and superminis such as the VAX and PDP-11 to remote personal computers, such as the PC and Rainbow. It should also be widely available for many

different micros and mainframes. File transfer from micro to micro, as well as from a larger central host, should be possible.

The command interface should be easy to learn, and require no intervention from a central site operator or other user. The many

Page 2 implementations of Kermit follow these lines, and all versions allow some form of transfer in either direction. More advanced versions, such as those found on the PDP-11, DEC10/20 and VAX, offer what is known as server operation, which allow the remote

(connected) Kermit system to completely control the file exchanges from their system. Since as of this writing (October 9, 1985) there are available over 160 versions of Kermit available for numerous micro, mini and mainframe configurations, Kermit addresses this need quite well.

While the primary use of Kermit will likely be to support file transfer from microcomputer to mini/supermini and mainframe connections, there are many uses for Kermit for connections from mini to mini and so on. The author routinely use Kermit for transfering software developed for the PRO/350 on a RSTS/E 11/23+ and a VAX 11/785, as well as using the PDP and VAX for dialing out to other systems around the country (not to mention VAX to PDP directly though a front end port selector).

The Kermit protocol

The Kermit protocol is designed to operate over normal asynchronous terminal lines. All data and commands are transferred with a packet oriented protocol, basically consisting of a start of packet character (normally SOH), followed by length, control, data and checksum fields. Communication is half duplex, in that for every packet sent, the sender must wait for either an acknowledgement packet (ACK) or a negative acknowledgement packet

(NAK). Transmission is in ascii, with no requirements for the transmission of eight bit characters or control characters other than control-A for marking the start of a packet. All 'control' characters imbedded in the data are prefixed to convert them to printable characters, the same applying to eight bit characters if required by the characteristics of the line. Since there are many different implementations of Kermit, the protocol provides a mechanism by which the capabilities of two connected Kermits can be negotiated to allow for differences in the level of protocol support. Examples of protocol features that not all Kermits understand include data compression and transfer of file attributes.

The packet format is


| MARK | char(LEN) | char(SEQ) | TYPE | DATA | CHECK |

+------+-----------+-----------+------+------------+-------+ where all fields consist of ASCII characters, and the char function converts a number in the range 0-94 (10) to a printable

ASCII character by adding 32 (10). The MARK, LEN, SEQ and TYPE fields are one byte, the DATA field is variable in size, and the

CHECK field is one to three bytes in size.

The MARK (normally control A) signifies the start of a packet.

Page 3

The length field tells how long the rest of the packet is. The

SEQ field is used to insure synchronization used to detect lost or duplicate packets. The SEQ number wraps around every 64 packets due to the need to encode it as a printable ascii character in the range 32 (10) to 126 (10). The TYPE field specifies whether the packet is a DATA or CONTROL packet. The DATA section is used for the actual transfer of data or informative messages from a Kermit server, this field can be up to 90 characters in length. Any character whose low seven bits fall in the range of 0 to 37 (8), ie, char and 177 (8) is less than 40 (8), will have the value 100

(8) exclusive or'ed (xor'ed) with itself and be prefixed by a shift character, '#'. Other shift characters may be use for eight bit characters if the line characteristics require such. Data compression may also occur in the data field, this is done with yet another shift code and byte count sequence. The CHECK field is a checksum, either a one character, two character or three character CRC check; the sender computes it and the receiver must compute it and compare. A checksum mismatch will result in the receiver sending a NAK packet (negative acknowledgment) which directs the sender to resend the NAK'ed packet. The packet may be following by a terminator (likely an ascii 13). This terminator is NOT part of the protocol and is sent only to tell the receiver that a 'line' is present. Not all Kermit implementations require this; all Kermits will discard data outside of a packet in any event.

Error detection and recovery is by checksum, as noted, and by packet read timeouts. If the packet should be corrupted the checksum will be incorrect, the receiver will NAK the packet. If an expected packet never arrives within the timeout period, or if the received packet is not the expected one (as determined by the

SEQ field) the packet will also be NAK'ed. There are limits as to how many times an expected packet will be NAK'ed without aborting the current operation.

Packet types

D Data

Y Acknowledgement (ACK), text may be in DATA field

N Negative Acknowledgement (NAK)

S Send initiate (Send-Init)

R Receive Initiate

B Break (EOT, end of transmission)

F File name header

Z End of file (EOF, end of current file)

E Error packet, text may be present in DATA field

G Generic SERVER command. The first character in the

data field will be a command to a server, arguments

may follow that character.

I Login, user and password follow in data field

C CWD, change working or default directory.

L Bye, Logout server

F Finish, Exit server, but do not log out

Page 4

E Erase, delete files on server system

D Directory query

U Disk space usage query

T Type a file onto local kermit

R Rename file(s) on server system

K Copy file(s) on server system

W Who's logged in, as in sho sys, sy/s, dev tt

M Send a terminal message to a user

H Help, the server responds with commands it can do

Q Server status query

P Program, run a program

J Journal

V Variable, alter a Kermit setting

C Execute host command. The host command follows in

the data field.

Note that some of the generic server commands, as well as the C packet, may not be feasible for a given environment. For instance, the REMOTE LOGIN command, which sends the generic I command to the server, can only be done under RSTS/E; the generic

U command (disk space) is meaningless under RSX unless one wants the free space on the entire volume. No Kermit server will abort on receiving a packet it can't execute, it will simply send an error packet with an informative message saying it can't process the requested function.

A typical transaction

An example of a Kermit-11 kermit telling a VMS Kermit-32 server to expect a file follows. The Kermit-11 command was SEND JUNK.TST

(0)PDP sends: ^A. S~* @-#Y3~( ,

(0)VAX sends: ^A, Yp/ @-#Y3~!

(1)PDP sends: ^A-!FJUNK.TST,-4

(1)VAX sends: ^A%!Y,\I

(2)PDP sends: ^A`"D$ set ter/vt100#M#J$ xcc :== ccl cc

#M#J$ xas :== ccl as#M#J!4S

(2)VAX sends: ^A%"Y.5!

(3)PDP sends: ^A%#Z,X"

(3)VAX sends: ^A%#Y/R9

(4)PDP sends: ^A%$B!_#

(4)VAX sends: ^A%$Y+&1

In packet zero, the Kermit's exchanged information regarding their capabilities. The PDP-11 sent an 'S' packet with the data for its maximum packet length, default time out, number of pad characters to follow a packet (none, hence the space), use a null for padding, end of line terminator (a CR + 32), the prefix character for control characters, a 'YES' to say the it can prefix eight bit

characters with the default, that it would like to use CRC block checks, that it will use a tilde for data compression, and the

'CAPAS' mask, which here says that it can process attribute packets (discussed later). Since the VAX also sends a '3' for the

Page 5 checksum type, they will both switch to CRC checks on the following packets. In packet 1, the PDP11 sends the filename the

VAX should use for the file it creates. The VAX then sends the acknowledgement. In packet three, the PDP sends the first (and only for this file) packet of data. Note that the sequence #M#J is a carriage return/line feed sequence with 100 (8) xored into each character. The '#' character informs the other Kermit that it must xor the next character with 100 (8). In packet three the

PDP11 sends an EOF packet, the VAX acks it. In packet four, the

PDP sends a break packet which tell the VAX that no more files (of a possibly wildcard group) are coming and the VAX Kermit acks the break packet. Both Kermits now switch to the single character checksum and the VMS kermit enters the server idle state.

More specific information regarding Kermit packets and state transitions can be found in the references listed at the end of the article.

Transmission of file attributes

One of the optional features of the Kermit protocol is the

ATTRIBUTE packet. The attribute packets allow a Kermit program to send to a receiving Kermit information regarding the file organization, size, cluster/retrieval size, protection and so forth. There is even a system dependant attribute packet type that can be used to transfer things like the RMS11 IFAB (the

RMS/FCS attributes). Since to date only the author's Kermit implementation, Kermit-11, can process attribute packets, the discussion is limited to the PDP-11.

One of the things that two Kermits exchange before any file transfer is an information packet, this packet tells the receiving

Kermit about itself. The last field in this packet, the CAPAS mask, tells Kermit if the other one can process attribute packets.

If two Kermit-11's are communicating, they will find that each can do so, and the sender of a file will then send over attribute packets indicating the need (or lack of) for binary transmission, based on the file organization, filetype and protection code (for

RSTS/E). If the sending Kermit-11 is running on RSTS/E, RSX11M/M+ or P/OS it will also send a copy of the RMS/FCS attributes so the received file will be identical (to FCS and/or RMS) to the copy on the sender's system. Since other implementations of Kermit may use this special system attribute packet, Kermit-11 always sends an attribute packet telling the receiver what hardware and operating system it is running on, and thus will only use such data if they are compatible. Of course, there will be times when a file may be binary and Kermit-11 can't tell so, many Kermit's have a SET FILE BINARY and SET FILE ASCII to allow the user to override defaults. Kermit-11 also has a SET FILE AUTO/NOAUTO to disable it from trying to determine a file's binary status.

The PDP-11 Kermit-11 implementation

The author's version of Kermit-11 is written in Macro-11 and can

Page 6 run on RSTS/E, RSX11M, RSX11M Plus, P/OS, RT11 and TSX+. This version of Kermit is distinct from the other three PDP-11 Kermits available; the Stevens P/OS menu driven Kermit; the University of

Toronto RT11 pascal Kermit and Bob Denny's P/OS Kermit. In

Kermit-11, the RSTS and RSX file system interface is via RMS11 version 2, while the RT11 interface attempts to emulate the RMS11 subsystem. The choice of Macro-11 for the implementation language was made for several reasons, one being the availability of the assembler on all systems and another being speed and compactness of the code.

RMS11 was used for RSTS/E and the RSX11M based systems to provide a common i/o interface to the host file system. Additionally, Bob

Denny of Alisa Systems further extended the RMS interface to support remote file access over DECNET with Kermit, allowing commands such as SEND NODENAME::[BRIAN.FUBAR]FILE.TYPE and other remote file accesses over DECNET. RMS11 version 2 also provides a very simple and powerful means of doing wildcard searching, file renames and file deletion via the $PARSE, $SEARCH, $RENAME and

$DELETE macros; it also allows the same RMS interface code to be used on all systems without change. Points against RMS basically amount to it's size, RMS is quite large even if overlayed. This is helped by using the segmented RMSRES available on RSTS/E and

RSX11M Plus. The one over negative point is that RMS11 version 2 does not function well, if at all, on the older versions of PDP-11 operating systems, specifically, one should be using RSTS/E v8 or later, RSX11M v4.1 or later, and RSX11M Plus version 2.1 or later.

All versions of Kermit-11 receive eight bit data assuming no parity is used. Where parity is a must, Kermit-11 has to use a prefixing scheme for eight bit binary data. Binary files are created as FIXED no carriage control files such as used for task images. Note that parity generation is done by software in

Kermit-11. The P/OS version of Kermit-11 runs under control of

DCL. The next release of Kermit-11, which will be 2.37, will include support for the PRO TMS (Telephone Management System) option. Each version of Kermit-11 has it's own source file to deal with the operating system, for RSX it is K11M41.MAC, for

RSTS/E they are K11E80.MAC and K1180S.MAC, and for RT11 they are called K11RT*.MAC. Apart from these specific files, all other source files are shared. The RT11 Kermit-11 can use either the version 5.x XL and XC handler for high throughput, or it can use multiple terminal service to do all its terminal i/o. This second option allows the use of any interface supported, including the

PDT150 modem port, DL/DLV11's and DZ/DZV11's. TSX+ users can connect to CL: for dialing out, the exact means is documented in the Kermit-11 users guide.

Future directions

With the advent of packet switched networks and satellite communications the Kermit protocol will likely be extended to

increase efficiency over such links. The main problem is the half duplex nature of Kermit, the packet acknowledgements can take up to several seconds in transit thus drastically reducing the throughput. There are several possibilities under discussion and

Page 7 a standard should be appearing shortly.


With the knowledge that there are Kermit implementations for most personal computers in use it becomes apparent that the Kermit standard is well worth looking in to. A list of versions running on Digital hardware follows the article.

Kermit: A File-transfer Protocol for Universities

Frank da Cruz and Bill Catchings

BYTE Magazine, June/July 1984

The Kermit Protocol Manual, version 5

Frank da Cruz April 1984

Columbia University Center for Computing Activities

Information on obtaining Kermit:

KERMIT Distribution

Columbia University Center for Computing Activities

7th Floor, Watson Laboratory

612 West 115th Street

New York, N.Y. 10025

Kermit is also usually found on the Decus symposia SIG tapes.

Kermit-11 is available from DECUS as number 11-731

Digital hardware that Kermit is currently available for:

Operating Program

Machine System Language Contributor

DEC PDP-11 MUMPS-11 MUMPS-1982 Cornell U

DEC PDP-11 RSTS/E Macro-11 U of Toledo

DEC PDP-11 RSX-11/M Macro-11 U of Toledo

DEC PDP-11 RSX-11/M+ Macro-11 U of Toledo

DEC PDP-11 RT-11 Macro-11 U of Toledo

DEC PDP-11 RT-11 OMSI Pascal U of Toronto

DEC PDP-11 TSX+ Macro-11 U of Toledo

DEC PDP-11 Unix 2xBSD C Columbia U

DEC PDP-11, ... Unix V7 C Columbia U

DEC PDP-8 OS8, RTS8 PAL-8 R. Hippe

DEC Pro-3xx P/OS Bliss, Macro Stevens I.T.

DEC Pro-3xx P/OS Macro-11 U of Toledo

DEC Pro-3xx Pro/RT Macro-11 U of Toledo

DEC Pro-3xx Venix V1 C Columbia U

DEC Pro-3xx Venix V2 C Columbia U

DEC Rainbow CPM86 ASM86 Columbia U

DEC Rainbow MS-DOS MASM Columbia U

DEC Rainbow QNX 1.x C Merrell-Dow

DEC VAX Ultrix-32 C Columbia U

DEC VAX VMS Bliss,Macro Stevens I.T.

Page 8

DEC VAX VMS C (VAX-11 C) Columbia U

DEC VAX VMS Pascal U of Toronto

DEC VAX, ... Unix 4xBSD C Columbia U

DEC VT-180 Robin CPM80 Turbo Pascal Jeff Duncan

DEC VT-180 Robin CPM80 2.2 M80,LASM ACC


DECsystem-10 TOPS-10 Bliss, Macro Stevens I.T.

DECSYSTEM-20 TOPS-20 MACRO-20 Columbia U

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF