The Kermit Project   |   Now hosted by Panix.com
New York City USA   •   kermit@kermitproject.org
…since 1981

C-Kermit - Frequently Asked Questions

Most recent update: Mon Oct 24 08:16:55 2022

As of C-Kermit 10.0 Beta.06, 5 October 2020


WHAT IS C-KERMIT?

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 authentication 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:

  comp.protocols.kermit.misc

And an e-mail tech-support address (through 30 June 2011 only).

  support@kermitproject.org

And lots of other resources. Also see:

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

WHERE DOES C-KERMIT COME FROM?

C-Kermit is a product of the nonprofit Kermit Project, formerly of Columbia University. It was originally written there in 1985 and was actively developed, maintained, and supported by us, with help and contributions from volunteers at other sites throughout the world, until 2011, when Columbia University canceled the Kermit Project. Now it is hosted at the new independent Open Source Kermit Project website, but there is no longer a full-time development and support staff. So development is slow, and support is on a best-effort basis.

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

  http://www.kermitproject.org/ckermit.html

Any other source is likely to be either incomplete and out of date, or "forked" from the definitive version without the author's knowledge.

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

HOW IS C-KERMIT LICENSED?

C-Kermit 9.0 has a certified Open Source license: the Revised 3-Clause BSD License. Earlier versions had a somewhat more restrictive license.

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

DO I HAVE THE RIGHT VERSION OF C-KERMIT?

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, and also C compiler and version and libraries, needs its own C-Kermit program. The source code is portable but the binaries are not.

At Columbia University, we tried to provide prebuilt C-Kermit binaries for as many combinations as we could, over 1600 of them; most of those we built ourselves, others were sent in by kind volunteers (this comprehensive library of Kermit software binaries remains available at Columbia, but has not been duplicated here due to lack of resources at the new site). 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. Columbia University has available a collection of more than 1600 Unix C-Kermit binaries, built up until September 30, 2011, that you can access HERE. The source code can be found here:

  http://www.kermitproject.org/ckermit.html

along with building instructions.

In recent years, less and less importance is placed on stability and backwards compatibility. New OS or library releases have an increasing tendency to break applications. Now with automatic patching, you might not even know that your OS or libraries have changed, but then suddenly one morning you find that C-Kermit and other applications have stopped working – failure load a library, segmentation fault (core dump), etc. This form of software rot was virtually unknown in the Old Days, now it is the rule. Perfectly good applications have to be rebuilt or updated constantly. If left unattended, they "rot" to the point of uselessness.

C-Kermit itself is quite stable. In most cases it does not need to be changed to keep up with the changing infrastructure; just relinked or, in the worse case, recompiled and relinked. So keep your source code handy, you'll probably need it again and again. But in any case, you can always pick it up again from here

Meanwhile 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.

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

HOW CAN I GET A SECURITY-ENABLED VERSION OF C-KERMIT?

Briefly: The security-related features and commands are NOT in the publicly distributed C-Kermit binaries. You can't use the prebuilt binaries to make secure connections. If you try to give them a command like SET AUTH, Kermit will say "?No keywords match - auth". To get a version of C-Kermit that has security features, you must download the source code and build it yourself.

C-Kermit was 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 without a license. Thus, each user or site that needs C-Kermit's security features 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.

Note that a C-Kermit binary with SSL built on one machine will not run on another machine that has a different version of OpenSSL. This is explained in Section 4.2.3 of the Kermit Security Reference. It can also happen on the same machine if you change the OpenSSL version without rebuilding C-Kermit.

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

WHAT IS THE DOCUMENTATION FOR C-KERMIT?

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.

C-Kermit 9.0 Supplement
The new features of C-Kermit 9.0, mainly support for large files and a new Open Source license.

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]

WHY IS THERE NO TERMINAL EMULATOR IN C-KERMIT?

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:

  $ SET DISPLAY/NODE=mylinuxhost/TRANS=TCPIP/CREATE
  $ CREATE/TERM/DETA

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:

  http://dickey.his.com/xterm/xterm.html

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.

(September 2015)... I have been told that Minicom supports some degree of key mapping, e.g. assignment of macros to F-keys. Looking into this is on my list but so are many other things. There is some discussion here of key mapping in Minicom that might serve as a starting point. The discussion indicates that it is based on ncurses/termap (I think this must be a typo and schould be “ncurses/termcap”). Looking at Richard Stallman's Termcap Manual I see that it provides access to key codes that stand for keyboard arrow keys, editing keys, numeric keypad keys, and even Meta (presumably Alt) key combinations, so perhaps some limited form of key mapping is possible in versions of Unix that use GNU termcap, but probably not to the degree that we have in, say, Kermit 95, where all different combinations of keys with one or more modifiers (Ctrl, Shift, and/or Alt) are distinguishable. C-Kermit already links with the ncurses (or curses) and termcap libraries, so adding termcap-based key mapping is possible but great care must be taken to preserve portability. For example a glance at “man termcap” in NetBSD 6.1 doesn't include anything at all to do with key codes or key mapping.

These days, Unix (Linux, FreeBSD, Solaris, etc) is a general-purpose multiuser 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 Microsoft has spent (now) decades 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 decent terminal emulator.

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

WHAT DOES "WRITE ACCESS TO LOCKFILE DENIED" MEAN?

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, or the dialout devices and lockfile directory must allow group read/write permission to the user. For more detail, read Sections 10 and 11 of the C-Kermit Installation Instructions.

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

CAN C-KERMIT TRANSFER LONG FILES?

On most platforms, C-Kermit 8.0 and earlier 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. 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 9.0, which is still in development but which can be downloaded and tested by anybody – just CLICK HERE.

C-Kermit 9.0 supports large files not only on 64-bit platforms but also also on most relatively modern 32-bit Unix platforms that also support them: Linux, FreeBSD, OpenBSD, NetBSD, SCO UnixWare 7 and OpenServer 6, Mac OS X, AIX, Solaris, HP-UX, IRIX: CLICK HERE for details. The Windows version of C-Kermit will support large files if any Windows programmers show up to complete the conversion of Kermit 95 to Open Source.

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

WHY CAN'T I SEND BINARY FILES?

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:

SET PREFIXING ALL

and try again.

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

HOW DO I MAKE C-KERMIT SEND AN ANSWERBACK STRING?

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]

WHY DOESN'T MY SCRIPT WORK?

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.

HINTS:

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]

HOW CAN I USE C-KERMIT AS MY PPP DIALER?

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.

C-KERMIT LOSES CHARACTERS ON SERIAL-PORT CONNECTIONS!

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.

WHY DOESN'T C-KERMIT REDIAL AUTOMATICALLY?

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).

WHY DOESN'T C-KERMIT USE TONE DIALING AUTOMATICALLY?

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]


The Kermit Project hosted by Panix.com / kermit@kermitproject.org