| [ Home ] [ Kermit 95 ] [ C-kermit ] [ Scripts ] [ Current ] [ New ] [ FAQ ] [ Support ] |
Most recent update: Tue Dec 5 10:52:58 2006
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:
comp.protocols.kermit.misc
And an e-mail tech-support address:
kermit-support@columbia.edu
And lots of other resources. Also see:
[Top] [C-Kermit Home] [Kermit Home]
The definitive site for C-Kermit software and information is:
http://www.columbia.edu/kermit/ckermit.html
Any other source is likely to be incomplete and out of date.
[Top] [C-Kermit Home] [Kermit Home]
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:
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]
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:
http://www.columbia.edu/kermit/ckermit.html
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]
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]
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:
$ 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.
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-proprietray 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]
[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 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]
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]