|
The Kermit Project |
Now hosted by
Panix.com
New York City USA •
kermit@kermitproject.org
| ||||||||
|
Most recent update: Mon Oct 24 08:16:55 2022
As of C-Kermit 10.0 Beta.06, 5 October 2020
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.
[Top] [C-Kermit Home] [Kermit Home]
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]
[Top] [C-Kermit Home] [Kermit Home]
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]
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]
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:
$ 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]
[Top] [C-Kermit Home] [Kermit Home]
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]
SET PREFIXING ALL
and try again.
[Top] [C-Kermit Home] [Kermit Home]
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]
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]
C-Kermit 7.0 includes a new command that handles PPP dialing in a natural and straightforward way:
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.
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:
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.
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).
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]