Home ]   [ Kermit 95 ]   [ C-kermit ]   [ Scripts ]   [ Current ]   [ New ]   [ FAQ ]   [ Support ]

C-Kermit - Frequently Asked Questions

Most recent update: Tue Dec 5 10:52:58 2006

The CURRENT VERSION of C-Kermit is 8.0.211 released 10 April 2004:
IN DEVELOPMENT: C-Kermit 8.0.212, open for testing:


C-Kermit is a portable communications software package offering a consistent and portable approach to serial and network communications: online sessions, file transfer, character-set translation, numeric and alphanumeric paging, and automation of all communications tasks.

C-Kermit is available for hundreds of different platforms including all varieties of UNIX (Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, Solaris, AIX, HP-UX, IRIX, QNX, and hundreds more), as well as VMS (OpenVMS), VOS, AOS/VS, and others, and works in conjunction with its companion programs on Windows, DOS, IBM Mainframes, and almost any other platform you can think of.

As a serial communications program, C-Kermit supports both direct serial and dialed connection. For dialing, it includes built-in support for dozens of modem types and a sophisticated location-independent dialer and dialing directory, allowing the same entries to be used from any country or area within a country.

On TCP/IP networks, C-Kermit can act as Telnet client, Rlogin client, or as a file-transfer and management server that can be accessed from clients elsewhere on the network. In Unix only, C-Kermit 8.0 is also an FTP client and a front-end to your computer's SSH client, and on the server side can also be installed as an SSH service -- a more powerful alternative to SFTP. C-Kermit's TCP/IP connections can include secure authentation and encryption using the Kerberos 4, Kerberos 5, SSL/TLS, and SRP security methods. On selected platforms, other networking methods such as X.25 are also supported.

C-Kermit offers online sessions with session logging, character-set translation, and other conveniences; it offers error-free, efficient, and robust file transfer with recovery and update features; auto-upload and -download; client/server and remote access features; character-set translation for Western and Eastern European languages, Cyrillic, Japanese, Greek, and Hebrew duing both terminal connection and file transfer (a unique feature of Kermit software), and in version 7.0 and later also Unicode.

All operations can be programmed for automatic unattended execution in a consistent way, regardless of platform or connection method, using the portable Kermit scripting language, which includes file and communications i/o, block structure, looping, variables, arrays, arithmetic, functions, pattern matching, and structured programming features.

C-Kermit is thoroughly documented and actively supported. The published manual is:

  Using C-Kermit

There's a newsgroup:


And an e-mail tech-support address:


And lots of other resources. Also see:

[Top] [C-Kermit Home] [Kermit Home]


C-Kermit is a product of the nonprofit Kermit Project at Columbia University. It was originally written here in 1985 and has been actively developed, maintained, and supported by us since then, with help and contributions from volunteers at other sites throughout the world.

The definitive site for C-Kermit software and information is:


Any other source is likely to be incomplete and out of date.

[Top] [C-Kermit Home] [Kermit Home]


C-Kermit 7.0 has a new license, CLICK HERE to read it.

The C-Kermit license does not fall into any convenient category. It is not commercial, not shareware, not freeware, not GPL. The terms can be summarized as follows:

  1. You may download C-Kermit without license or fee for your own use or internal use within your company or institution.

  2. You may install C-Kermit without license or fee as a service or application on a computer within your company that is accessed by customers or clients. This provision would apply, for example, to an ISP or a medical claims clearinghouse.

  3. You may include C-Kermit with a "Free UNIX" or other Open Source operating-system distribution such as GNU/Linux, FreeBSD, NetBSD, OpenBSD, etc.

  4. Except as in (3), you may not sell or otherwise furnish C-Kermit as a software product, or a component of any product, to actual or potential customers or clients without a commercial license; to see the commercial license terms, CLICK HERE.
In addition, we request that those who make more than casual use of C-Kermit purchase the published manual, Using C-Kermit. This helps them to get the most out of the software, it reduces the load on our help desk, and it helps to fund the Kermit Project.

The Kermit Project must fund itself entirely out of income, which comes from software licenses, book sales, and support contracts. The C-Kermit licensing terms are designed to be as generous and fair as possible within this framework. Simply stated: if you just want to use it, be our guest. If you want us to help you use it, please consult the manual first. If you want to make a product or commodity of it, you have to pay for it.

Note that these terms are approximately the same as for MS-DOS Kermit, but entirely different from Kermit 95, which has its own set of terms.

[Top] [C-Kermit Home] [Kermit Home]


Every combination of hardware platform (e.g. Intel versus Alpha versus PowerPC versus Sparc, etc), operating system (AIX, HP-UX, Solaris, VMS, etc), and operating system version, and sometimes also networking product and version, needs its own C-Kermit program. The source code is portable but the binaries are not.

We try to provide prebuilt C-Kermit binaries for as many combinations as we can, over 600 of them; most of those we build ourselves, others are sent in by kind volunteers. We also supply source code, so you can build it yourself if you have a C compiler, header files, and libraries.

The general rule is that a binary built on a particular version of an operating system on a particular platform should continue to function on later OS versions on the same platform, but there can be no guarantees. The converse, however, is almost a certainty: that a binary can not be run under an earlier OS version than it was built on.

If you change or upgrade your operating system, you will probably need to obtain (or build) a new C-Kermit binary. The binaries are listed on the C-Kermit web page. The source code can be found there too, along with building instructions:


As time passes, platforms where we built previous C-Kermit releases might be upgraded, stop working, or otherwise become unavailable to us, in which case we can no longer make binaries for that platform. In such cases you'll need to build from source code if you have a C compiler (and please send in the resulting binary), or run a binary from an earlier C-Kermit release, or contact us and we'll see if we can find someone else to build it.

[Top] [C-Kermit Home] [Kermit Home]


C-Kermit is a product of Columbia University, which is in New York City, which is in the United States of America (USA), and therefore subject to USA laws, which forbid export of software that contains strong encryption algorithms in binary executable (ready to run) format. Thus, each user or site must download the source code, compile it with the appropriate options, and link it with the desired security libraries such as Kerberos or OpenSSL (the makefile contains ready-made targets for most platforms to do this). Sites that does not have the desired libraries and header files must obtain them from the appropriate source (not us) and install them first.

Then why (you might ask) are we able to distribute Kermit 95 (the Windows version of Kermit) with security built in, in binary form? That's because we spent the months required to obtain permission from the US Department of Commerce Bureau of Industry and Security. This time-consuming and laborious process would be required for each C-Kermit binary, of which there are hundreds. Unfortunately we don't have the resources to do that.

In many cases, all you need to do is download the current source-code package, unpack it, and give a 'make' command referencing the appropriate target, e.g. "make freebsd50+openssl", "make openbsd30+openssl", "make hpux1100o+openssl", "make linux+openssl", etc. These targets are like the regular (non-secure) targets but with certain definitions added, certain directories added to the header-file search list, some extra libraries linked in.

In case there is not a premade target in the makefile for the desired platform and security method(s), first check the latest development build (not released yet), maybe it has been added. If not, you will need to add one yourself, using similar targets as a model. For more information see the Kermit Security Reference. If you add a new target, please send it back to us for inclusion in the next release.

[Top] [C-Kermit Home] [Kermit Home]


The documentation for C-Kermit is as follows:

Using C-Kermit
A 622-page book describing C-Kermit 6.0 (December 1996) and the platform-independent aspects of the concurrent version of K95 (1.1.8) including the command language, serial and network connections, file transfer, client/server operation, character set conversion, and script writing for automation, plus sections on troubleshooting, tutorials on data communications, and tons of reference material. Until a new edition is published, this book remains the fundamental reference for the command and scripting language of C-Kermit and Kermit 95. You can also find a scripting tutorial with lots of examples HERE.

C-Kermit 7.0 Supplement
Thorough documentation of the new features of C-Kermit 7.0 (January 2000) and the platform-independent aspects of K95 1.1.17, which was the first version to include secure authentication and encryption, and in which the command language was greatly extended by the addition of "switches" (command modifiers), and which was the first version to support Unicode (the Universal Character Set), plus other changes too numerous to list here.

C-Kermit 8.0 Supplement
Thorough documentation of the new features of C-Kermit 8.0 (February 2002 - April 2004) and the platform-independent aspects of K95 2.1, principally the new FTP, SSH, and HTTP clients or interfaces, plus tons of scripting improvements.

At some point a new edition of Using C-Kermit will be issued, incorporating the new material. For additional material, see the Kermit website, especially the C-Kermit/K95 script library.

[Top] [C-Kermit Home] [Kermit Home]


The platforms where C-Kermit runs -- UNIX, VMS, VOS, AOS/VS, etc -- are not like DOS or Windows. One of the most common questions about C-Kermit (and about the platforms it runs on) is "How Do I Tell C-Kermit to Emulate a TVI955 Terminal?" (substitute your favorite terminal or Unix variety or other timesharing OS such as VMS) or "How do I map the F-keys in C-Kermit?" We'll discuss Linux, but the situation is about the same for the others.

An advantage of operating systems like Unix over DOS and Windows is that Unix is a multiuser, multitasking operating system, not a single-user system designed only for use on a PC, from the PC's own physical keyboard and screen. Unix users can come in over the console, through X, through a serial port, a Telnet connection, an Rlogin connection, an SSH connection, etc etc, and there can be any number of them at once. The price you pay for this flexibility is that applications can't access the hardware directly.

In Unix, only the console driver and/or the X server can get at the computer's keyboard and screen, and so it is not possible to write a terminal emulator for Unix in the same way it is for DOS and Windows, which, as dedicated single-user desktop personal systems, always have direct access to the keyboard and screen.

Instead, the console (physical keyboard and "raw" screen + drivers) or the xterm window give you what amounts to an actual TERMINAL. Its characteristics are what they are; you can't change them (except you can do some key mapping in X which can affect xterm). If you want TVI955 or Wyse60 emulation and your xterm or console doesn't already do that, there is no way to get it.

As noted, you can also access Unix from Telnet, Rlogin, SSH, dialin, or even a hardwired connection from another computer through the serial port, or for that matter from an actual physical terminal (VT100, Wyse, TVI, etc), or from a PC that is running an emulator for a physical terminal. Obviously, when you come into Unix this way -- i.e. from a remote computer or terminal -- Unix applications haven't a prayer of directly accessing the keyboard or screen that you are using, and so can not tell which keys have been pressed or control the appearance of your screen.

Linux users often think they can get TVI955 (or any other kind of) emulation by setting their Linux TERM environment variable accordingly. But that's backwards. It doesn't change how your console or xterm works. Instead, you must inform the remote computer, the one you are connected to from Linux, what your Linux terminal type is, and make the remote system send the right stuff for it and interpret your keystrokes appropriately. For example, when logging in to AIX from Linux, give the following command at the AIX shell prompt:

  $ setenv TERM vt100

(or "export TERM=vt100", etc, depending on your shell). Note that AIX does not normally support the "linux" terminal type, so you can't tell AIX that your terminal type is Linux. Conversely, Linux console and xterm do not support the native AIX terminal type (AIXTERM or HFT), so you can't use that either. But AIX does support vt100 (as almost all multiuser operating systems do), and VT100 happens to be a subset of both Linux console and xterm.

Here's another example in which we access a Data General AOS/VS minicomputer which normally expects you to have a Data General DASHER terminal. But really we're using a VT100 emulator or xterm. So after logging in to AOS/VS, we give the following command, which tells it we are using an "ANSI" terminal (which in this case means VT100):

  ) char/on/nas/xlt

The Linux console "emulates" The Linux Console. It is its own terminal type. Xterm -- depending on which one you have -- emulates xterm (which is a VT100 superset) or in the case of Xfree86 xterm, vt220. If you are coming into Linux remotely, then your Linux terminal type should be the kind of terminal or emulator you have locally. If you have TCP/IP access to the remote computer, and both computers support X, it might be possible to run the remote computer's X terminal with its disply directed at your local computer's X server. For example, to access VMS from Linux, you might set up VMS like this:


This way, you'll be running the VMS xterm (DECterm) "on" Linux, rather than the regular Linux xterm (it's actually running on VMS, but using your Linux screen as its display). You'll have complications with fonts and key mapping, which can be solved, but the details are beyond the scope of this document (but see this VMS newsgroup posting for hints).

In UNIX the communications function generally resides in some other program, such as kermit, cu, telnet, rlogin, ssh, etc. Thus, unlike in Windows and other single-user operating systems, the terminal emulation and communication functions are separate. In a typical scenario, you start an xterm window, and then start (say) C-Kermit in the xterm window and have it make the desired connection. C-Kermit provides the connection, xterm provides the emulation. (Ditto if you replace C-Kermit by cu, telnet, rlogin, ssh, tip, minicom, and so on.) C-Kermit also gives you file transfer, character-set translation, transparent host-directed printing, and scripting on the connection. These are "value-added" services within the terminal screen through which you are viewing C-Kermit (and through C-Kermit, the remote computer).

If you are using xterm, it is possible to change what certain keys send by using xmodmap. For example, the regular xterm probably does not support high-number function keys, like F8. So if you need to make F8 send what (say) a DEC VT220 sends, you can (a) install Xfree86 xterm, which does this already:


or (b) use xmodmap to assign the appropriate sequence to the key as described at various places in Section 3 of the Unix C-Kermit Hints and Tips page. If you are using the Linux console, some other form of key mapping might be available, but it will apply to everything, not just to your terminal sessions.

Remember: On multiuser operating systems like Unix, Kermit, cu, telnet, ssh, and friends can't even see the F-keys, arrow keys, Alt key, etc, and there is no possibility of mapping or redefining keys in these programs, let alone of "PCTERM emulation", in which raw PC up/down event scan codes are sent by the terminal emulator. This is the price we pay for the cross-platform code portability and openness of access that Unix (and VMS, etc) offer us. In Windows we can write full-function terminal emulators because we can get directly at the keyboard and screen. But Windows does not allow the other, open forms of access that UNIX does. These are the tradeoffs.

There are, by the way, (or have been) several curses-based programs (such as pcomm) that claim to emulate various terminal types on Unix by using curses to translate the escape sequences of one type of terminal to those of another. However, the curses database does not fully describe a terminal, and curses has no more direct access to the keyboard and screen than any other application, so this approach is usually adequate -- if at all -- only in the host-to-screen direction.

These days, Unix (Linux, FreeBSD, Solaris, etc) is a general-purpose multiser OS that everybody is trying to turn into a single-user PC operating system like Windows, and at the same time Windows is a single-user PC operating system that everybody is trying to turn into a general-purpose multiuser operating system like Unix. Each one is best at what it was originally designed for. If you want a platform for which high-performance, fully functional terminal emulators are available, you're better off with Windows (or even DOS). If you want a platform that is generally useful, programmable, relatively secure, and supports multiple users coming in from a variety of sources from a variety of different platforms using a variety of open, standard, non-proprietary methods, you're better off with Unix.

Of course most people want (or need) both, which results in many of us with two workstations on our desks, or booting back and forth between two OS's, or running DOS or Windows emulators under Unix so we can have a terminal emulator.

[Top] [C-Kermit Home] [Kermit Home]


In Unix, dialout programs such as cu, tip, uucp, minicom, seyon, and C-Kermit must have permission to use the dialout device AND to create a lock file. In most Unix installations, most users do not have read/write permissions for the device, nor for the lockfile directory. Therefore the dialout program must be installed with "setuid" or "setgid" privileges, as well as an appropriate owner and/or group, in order to access the needed resources. Briefly, Kermit must be installed with the same owner, group, and permissions as the cu program. For more detail, read Sections 10 and 11 of the C-Kermit Installation Instructions.

[Top] [C-Kermit Home] [Kermit Home]


On most platforms, C-Kermit can not handle files longer than 231 or 232 bytes long, because it uses the traditional file i/o APIs that use 32-bit words to represent the file size. To accommodate longer files, we would have to switch to a new and different API. Unfortunately, each platform has a different one, a nightmare to handle in portable code. The C-Kermit file code was written in the days long before files longer than 2GB were supported or even contemplated in the operating systems where C-Kermit ran.

Luckily, however, on many 64-bit platforms, the traditional APIs "just work", allowing files of any valid size to be sent -- via Kermit or FTP protocol -- provided the recipient is capable of creating long files. Examples include (but are not necessarily limited to) Linux on 64-bit architectures such as AMD X86_64 and Intel IA64, Solaris 9 and 10 on Sparc, Tru64 Unix on Alpha, and HP-UX 11i on IA64 (and maybe also on PA-RISC, I'm not sure). A great deal of testing and refinement has been done in this area for version 8.0.212, which is still in development but which can be downloaded and tested by anybody – just CLICK HERE.

THE NEXT RELEASE of C-Kermit will support large files on 64-bit platforms and also on most 32-bit Unix platforms that also support them: Linux, FreeBSD, OpenBSD, NetBSD, SCO UnixWare 7 and OpenServer 6, Mac OS X 10.4, AIX, Solaris, HP-UX, IRIX: CLICK HERE for details.

[Top] [C-Kermit Home] [Kermit Home]


If you can send text files but not binary files, the most likely explanation is that Kermit 7.0 and later "unprefix" certain control characters by default, for speed, but your connection is not transparent to one or more of these control characters. This change was made due to popular demand, so Kermit protocol transfers would work as fast as possible "out of the box" without users having to know or SET anything. The downside, of course, is that high-speed tuning doesn't work on every connection or with every possible protocol partner, which is why we didn't use it in the first place. If this happens to you, tell C-Kermit to:


and try again.

[Top] [C-Kermit Home] [Kermit Home]


Since C-Kermit is not a terminal emulator, it does not send answerback strings (of course versions of Kermit that do include terminal emulators, such as Kermit 95 for Windows, can do this). But you can achieve the same effect as follows:

  define answerback "ANSWERBACK STRING"

  define xx {
      while open connection {
	  connect /trigger:\5
	  if = "2" "\v(cx_status)" lineout \m(answerback)

Then run the "xx" macro instead of the regular "connect" command. The \v(cx_status) variable tells the reason that Kermit returned from CONNECT mode; 2 means a trigger string -- Ctrl-E (\5) in this case -- was encountered. Triggers are discussed HERE.

[Top] [C-Kermit Home] [Kermit Home]


Almost certainly it's because your script contains a CONNECT or TELNET command. These commands start an online session, connecting your keyboard to the remote, and the remote to your screen. In a script, you want C-Kermit to handle the interactions for you. Therefore, replace your CONNECT command with the appropriate series of commands:

  OUTPUT text 
  INPUT timeout text
  IF FAILURE do-something
  OUTPUT some-more-text 
  INPUT timeout some-other-text
  IF FAILURE do-something-else

OUTPUT sends the characters you would type, INPUT looks for the prompts or responses from other computer. If you want the OUTPUT text to include or end with a carriage return, you have to include as \13. The timeout tells the INPUT command how many seconds to wait for a response or prompt. The result of INPUT command should be checked by IF SUCCESS or IF FAILURE. If it failed, the appropriate action should be taken.

If you have a TELNET command in your script (which is equivalent to SET HOST followed by CONNECT), replace it by SET HOST and the appropriate series of OUTPUT / INPUT / IF FAIL commands. Scripts do not execute during CONNECT mode.


C-Kermit's script language is thoroughly documented in Chapters 17-19 of the manual and lots of sample scripts are available here.

[Top] [C-Kermit Home] [Kermit Home]


For years, people have been asking us how to use C-Kermit as their PPP dialer in Linux and other kinds of Unix. Until now, there has never been a good answer. There were some half-good answers, such as those found in Item 27 of the Kermit FAQ. The problem was that any connection opened by C-Kermit would be closed when it exited, so C-Kermit had to be kept alive (even though it wasn't doing anything) for the duration of the PPP connection.

C-Kermit 7.0 includes a new command that handles PPP dialing in a natural and straightforward way:

EXEC [ /REDIRECT ] command [ arg1 [ arg2 [ ... ] ]
Runs the given command with the arguments in such a way that the command replaces C-Kermit in memory, and C-Kermit ceases to execute. EXEC is like RUN, except instead of returning to C-Kermit when finished, the command returns to whatever process invoked Kermit.

In the normal case, no files are closed, so the EXEC'd command inherits the open files, read/write pointers, working directory, process ID, user ID (unless the command is setuid'd), group ID (unless the command is setgid'd), etc; in UNIX, the EXEC command is simply a front end for the execvp() system service.

If the /REDIRECT switch is included, then if a connection is open (SET LINE or SET HOST), it becomes the standard input and output of the EXEC'd program. This is how PPP dialing is done.

Here's an example for Linux, in which we dial a traditional terminal server that issues a login and password prompt (as opposed to, say, using PAP or CHAP authentication). We assume that the script has already set up the myuserid and mypassword variables (normally the password should be prompted for, not stored on disk).

  set modem type usr          ; Specify the kind of modem you have
  set line /dev/ttyS1         ; Specify the device it's connected to
  set speed 57600             ; and the speed
  set flow rts/cts            ; and flow control.
  set dial retries 100        ; Try the dial sequence up to 100 times.
  dial {{+1(212)555-1212}{+1(212)555-1213}{+1(212)9-555-1214}}
  if fail exit 1
  for \%i 1 16 1 {            ; Try up to 16 times to get login prompt
      input 10 Login:         ; Wait 10 sec for it to appear
      if success break        ; Got it - proceed...
      output \13              ; Send a carriage return and try again
  if ( > \%i 16 ) exit 1 NO LOGIN PROMPT
  lineout \(myuserid)         ; Send user ID
  input 30 assword:           ; Wait for Password prompt
  if fail stop 1 NO PASSWORD PROMPT
  lineout \m(mypassword)      ; Send the password.
  exec /redirect pppd         ; Replace ourselves with pppd.

Just before the EXEC command, you might also need to send a command to the terminal server that tells it to start PPP; some terminal servers always start PPP, some give you a choice of Telnet, Rlogin, PPP, SLIP, LAT, and/or other services.

Notice the advantages over the well-known "chat script":

The EXEC command is documented in Section 1.23 of the C-Kermit 7.0 Update Notes. The syntax of the DIAL command in the example is explained in Section 2.1.15; it lets you give a list of numbers to be dialed in case the first one doesn't answer; as noted, the only way to do this in earlier C-Kermit versions was with a dialing directory.

If you have trouble dialing, add the command SET DIAL DISPLAY ON before the DIAL command, so you can watch the interactions between Kermit and the modem.

The sample script is not universal, but not that hard to generalize by making it a Kerbang script (called, say, "startppp") that takes phone numbers, username, and password as command-line arguments and prompts interactively for any of these that are missing.


First, make sure an effective form of flow control is enabled, preferably RTS/CTS. The same kind of flow control must be enabled in whatever is on the other end of the serial-port cable (modem, terminal server, computer). If you are using hardware flow control, the cable must be wired properly for it. This topic is discussed at great length in Using C-Kermit.

If flow control is set up right and the cable is good, but characters are still lost, then on PC-based UNIXes (Linux, FreeBSD, NetBSD, SCO, etc), the most likely cause is an interrupt conflict. This is especially likely if:

  1. Your PC has more than 2 COM-port devices (PC architecture only allows for two).
  2. Your PC has a serial mouse or a serial infrared port.
  3. Your PC has more devices than it has unique interrupts.

The techniques for resolving interrupt conflicts are different for every operating system (Linux, NetBSD, etc etc). In general, there is a configuration file somewhere that lists COM ports, something like this:

  com0    at isa? port 0x3f8 irq 4	# DOS COM1
  com1    at isa? port 0x2f8 irq 3	# DOS COM2

The address and IRQ values in this file must agree with the values in the PC BIOS and with the ports themselves, and there must not be more than one device with the same interrupt. Unfortunately, due to the small number of available interrupts, installing new devices on a PC almost always creates a conflict.


Automatic redialing is illegal in many countries, so C-Kermit does not do it by default. If you want Kermit to redial modem calls automatically when they are busy (etc), you can tell Kermit to SET DIAL RETRIES n, where n is a number specifying how many times the DIAL command is allowed to dial a number until it answers.

Kermit also automatically enables redialing if it knows your country code (SET DIAL COUNTRY-CODE or the K_COUNTRYCODE environment variable) and if corresponds to a country where Kermit knows redialing is legal (e.g. country code 1 for the North American Numbering Plan).


Tone dialing is not available everywhere, so C-Kermit does not do it by default. If you want Kermit to use tone dialing, you must tell it to SET DIAL METHOD TONE.

Kermit also automatically uses Tone dialing if it knows your country code (SET DIAL COUNTRY-CODE or the K_COUNTRYCODE environment variable) and if corresponds to a country where Kermit knows Tone dialing is universally accepted (e.g. country code 1 for the North American Numbering Plan).

[Top] [C-Kermit Home] [Kermit Home]

C-Kermit FAQ / Columbia University / kermit@columbia.edu