This window type is similar to 'screen cu -l /dev/ttya'. Read and write access is required on the device node, an exclusive open is attempted on the node to mark the connection line as busy. An optional parameter is allowed consisting of a comma separated list of flags in the notation used by stty(1): 1200,9600,19200 - First parameter is the. Trying to communicate to device attached to serial port on Xserve through terminal.terminal froze after first try (hardware related), however, now - after fixing hardware - when we try to connect using: screen /dev/cu.serial 115200 we get two errors in rapid succession: Cannot open line '/dev/cu.serial' for R/W: Resource Busy.

The Problem

For the project I am currently working I have a development board with a FTDI 2232 serial to USB adapter to connect to it. The Baudrate is set to Baudrate of 460800. This is not a problem on Linux and Windows. But if you are using OSX and open the serial device with a baudrate over 230400, it falls back to 9600 baud. (Up to 230400 all baudrates work fine)

I investigated already a bit into this, and the problem occurs independently of the program that you use to open the terminal. I tried GNU screen, and a couple of others.

I even tried to use other drivers, in my case the drivers provided by FTDI (stock OSX provides its own drivers for most serial converters). But this still didn’t help.

All combinations of serial terminal clients and drivers „pretend“ to open the device at 460800 baud, but if you look at the signals with an oscilloscope or logic analyzer you see that in reality it is only 9600.

The solution I found involves the commandline program stty, which can be used to set (among other options) the Baudrate of TTYs on Unix systems. stty opens the serial port device, and sets the new baudrate. However there is one tricky part left: OSX resets the baudrate after stty exits!! But I found a solution here

TL;DR: The Solution

Explanation: The first part (before the &) sets the baudrate for the terminal. The & sends the stty process to the background. The second part opens the serial terminal, while stty is still in the background. There is a small time frame after stty exits where OSX did not reset the baudrate yet, and this is used to connect to it with the correct baudrate.

Most recent update:Tue Jun 28 09:43:24 2011

As of C-Kermit is 9.0.300, 30 June 2011

WHAT IS C-KERMIT?

C-Kermit is a portable communications software package offering aconsistent and portable approach to serial and network communications: onlinesessions, file transfer, character-set translation, numeric and alphanumericpaging, and automation of all communications tasks.

C-Kermit is available for hundreds of different platforms including allvarieties 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, andworks in conjunction with its companion programs onWindows, DOS,IBM Mainframes,and almost any other platform you can think of.

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

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

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

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

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

There's a newsgroup:

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

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 at ColumbiaUniversity. It was originally written here in 1985 and has been activelydeveloped, maintained, and supported by us since then, with help andcontributions 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]

HOW IS C-KERMIT LICENSED?

C-Kermit 9.0 has a certified Open Source license:the Revised 3-Clause BSD License.

The following describes the C-Kermit 7.0 and 8.0 license:

C-Kermit has its own special kind of license:CLICK HERE toread it.

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

1. You may download C-Kermit without license or fee for your own useor internal use within your company or institution.
2. You may install C-Kermit without license or fee as a service orapplication on a computer within your company that is accessed by customers orclients. This provision would apply, for example, to an ISP or a medicalclaims clearinghouse.
3. You may include C-Kermit with a 'Free UNIX' or other OpenSource 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 asa software product, or a component of any product, to actual or potentialcustomers or clients without a commercial license; to see the commerciallicense terms, CLICK HERE.

In addition, we recommend that those who make more than casual use of C-Kermitpurchase the published manual,UsingC-Kermit. It's a complex program, it's even a programminglanguage, and for such things books work best for learning and reference.

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

DO I HAVE THE RIGHT VERSION OF C-KERMIT?

Serial Port Terminal Emulator

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

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

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

If you change or upgrade your operating system, you will probably need toobtain (or build) a new C-Kermit binary. The binaries are listed HERE. The source code can be found here:

along with building instructions.

In recent years, less and less importance is placed on stability andbackwards compatibility. New OS or library releases have an increasingtendency to break applications. Now with automatic patching, you might noteven know that your OS or libraries have changed, but then suddenly onemorning you find that C-Kermit and other applications have stopped working–failure load a library, segmentation fault (core dump), etc. This form ofsoftware rot was virtually unknown in the Old Days, now it is therule. Perfectly good applications have to be rebuilt or updatedconstantly. If left unattended, they 'rot' to the point of uselessness.

C-Kermit itself is quite stable. In most cases it does not need to bechanged 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 alwayspick it up again from here

Meanwhile as time passes, platforms where we built previous C-Kermitreleases might be upgraded, stop working, or otherwise become unavailable tous, in which case we can no longer make binaries for that platform. In suchcases you'll need to build from source code if you have a C compiler (andplease send in the resulting binary), or run a binary from an earlierC-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 areNOTin the publicly distributed C-Kermit binaries. Youcan't use the prebuilt binaries to make secure connections. If you try togive them a command like SET AUTH, Kermit will say'?No keywords match - auth'. To get a version of C-Kermit that hassecurity features, you must download the source code and build ityourself.

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 USAlaws, which forbid export of software that contains strong encryptionalgorithms in binary executable (ready to run) format without a license.Thus, each user or site that needs C-Kermit's security features mustdownload the source code, compile it with the appropriate options, and linkit with the desired security libraries such as Kerberos or OpenSSL (themakefile contains ready-made targets for most platforms to do this). Sitesthat does not have the desired libraries and header files must obtain themfrom the appropriate source (not us) and install them first.

Then why (you might ask) are we able to distribute Kermit95 (the Windows version of Kermit) with security built in, in binary form?That's because we spent the months required to obtainpermission from the US Department of CommerceBureau of Industry and Security. Thistime-consuming and laborious process would be required for eachC-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, andgive a 'make' command referencing the appropriate target, e.g. 'makefreebsd50+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 theheader-file search list, some extra libraries linked in.

In case there is not a premade target in the makefile for the desiredplatform and security method(s), first check the latest development build (not released yet), maybeit has been added. If not, you will need to add one yourself, using similartargets as a model. For more information see the Kermit Security Reference. If you add a newtarget, 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 runon another machine that has a different version of OpenSSL. This isexplained in Section 4.2.3 of theKermit Security Reference. It can also happenon the same machine if you change the OpenSSL version without rebuildingC-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 theplatform-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 forautomation, plus sections on troubleshooting, tutorials on datacommunications, and tons of reference material. Until a new edition ispublished, this book remains the fundamental reference for the commandand scripting language of C-Kermit and Kermit 95. You can also finda scripting tutorial with lots of examplesHERE.

C-Kermit7.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 firstversion to include secure authentication and encryption, and in which thecommand language was greatly extended by the addition of 'switches' (commandmodifiers), and which was the first version to support Unicode (the UniversalCharacter Set), plus other changes too numerous to list here.

C-Kermit8.0 Supplement

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

C-Kermit9.0 Supplement

The new features of C-Kermit 9.0, mainly support for large filesand 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 Kermitwebsite, especially the C-Kermit/K95 script library.

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

WHY IS THERE NO TERMINAL EMULATOR IN C-KERMIT?

• How Do I Tell C-Kermit to Emulate a TVI955 (or other kind of) Terminal?
• How Do I Map the F-Keys in C-Kermit?

The platforms where C-Kermit runs -- UNIX, VMS, VOS, AOS/VS, etc -- are notlike DOS or Windows. One of the most common questions about C-Kermit (andabout the platforms it runs on) is 'How Do I Tell C-Kermit to Emulate aTVI955 Terminal?' (substituteyour 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 Unixis a multiuser, multitasking operating system, not a single-user systemdesigned 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, aTelnet connection, an Rlogin connection, an SSH connection, etc etc, and therecan be any number of them at once. The price you pay for this flexibility isthat applications can't access the hardware directly.

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

Instead, the console (physical keyboard and 'raw' screen + drivers) or thexterm window give you what amounts to an actual TERMINAL. Its characteristicsare what they are; you can't change them (except you can do some key mappingin X which can affect xterm). If you want TVI955 or Wyse60 emulation andyour 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 ahardwired connection from another computer through the serial port, or forthat matter from an actual physical terminal (VT100, Wyse, TVI, etc), or froma PC that is running an emulator for a physical terminal. Obviously, when youcome into Unix this way -- i.e. from a remote computer or terminal -- Unixapplications haven't a prayer of directly accessing the keyboard or screenthat you are using, and so can not tell which keys have been pressed orcontrol the appearance of your screen.

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

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

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

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 VT100superset) or in the case of Xfree86 xterm, vt220. Ifyou are coming into Linux remotely, then your Linux terminal type should bethe kind of terminal or emulator you have locally. If you have TCP/IP accessto the remote computer, and both computers support X, it might be possible torun the remote computer's X terminal with its disply directed at your localcomputer's X server. For example, to access VMS from Linux, you might set upVMS like this:

This way, you'll be running the VMS xterm (DECterm) 'on' Linux, rather thanthe regular Linux xterm (it's actually running on VMS, but using your Linuxscreen as its display). You'll have complications with fonts and keymapping, which can be solved, but the details are beyond the scope of thisdocument (but seethis VMS newsgroupposting for hints).

In UNIX the communications function generally resides in some otherprogram, such as kermit, cu, telnet, rlogin, ssh, etc. Thus, unlike inWindows and other single-user operating systems, the terminal emulation andcommunication functions are separate. In a typical scenario, you start anxterm window, and then start (say)C-Kermitin the xterm window andhave it make the desired connection. C-Kermit provides the connection, xtermprovides 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 scriptingon the connection. These are 'value-added' services within the terminalscreen through which you are viewing C-Kermit (and through C-Kermit, theremote computer).

If you are using xterm, it is possible to change what certain keys sendby using xmodmap. For example, the regular xterm probably does not supporthigh-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 doesthis already:

or (b) use xmodmap to assign the appropriate sequence to the key asdescribed at various places in Section 3 of theUnix C-Kermit Hints and Tips page. If you are usingthe Linux console, some other form of key mapping might be available, but itwill 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, andthere is no possibility of mapping or redefining keys in these programs, letalone of 'PCTERM emulation', in which raw PC up/down event scan codes are sentby the terminal emulator. This is the price we pay for the cross-platformcode portability and openness of access that Unix (and VMS, etc) offer us. InWindows we can write full-function terminal emulators because we can getdirectly 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 aspcomm) that claim to emulate various terminal types on Unix by using cursesto translate the escape sequences of one type of terminal to those ofanother. However, the curses database does not fully describe a terminal,and curses has no more direct access to the keyboard and screen than anyother application, so this approach is usually adequate -- if at all -- onlyin the host-to-screen direction.

These days, Unix (Linux, FreeBSD, Solaris, etc) is a general-purpose multiuserOS that everybody is trying to turn into a single-user PC operating systemlike Windows, and at the same time Windows is a single-user PC operatingsystem that everybody is trying to turn into a general-purpose multiuseroperating system like Unix. Each one is best at what it was originallydesigned for. If you want a platform for which high-performance, fullyfunctional terminal emulators are available, you're better off with Windows(or even DOS).If you want a platform that is generally useful, programmable, relativelysecure, and supports multiple users coming in from a variety of sources from avariety 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 uswith two workstations on our desks, or booting back and forth betweentwo OS's, or running DOS or Windows emulators under Unix so we can havea 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-Kermitmust 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 forthe device, nor for the lockfile directory. Therefore the dialout programmust be installed with 'setuid' or 'setgid' privileges, as well as anappropriate owner and/or group, in order to access the needed resources.Briefly, Kermit must be installed with the same owner, group, and permissionsas the cu program, or the dialout devices and lockfile directory must allowgroup read/write permission to the user. For more detail, readSections 10 and11 of theC-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 than2³¹ or 2³² bytes long,because it uses the traditional file i/o APIs that use 32-bit words torepresent the file size. The C-Kermit file code was written in the dayslong before files longer than 2GB were supported or even contemplated in theoperating systems where C-Kermit ran.

Luckily, however, on many 64-bit platforms, the traditional APIs 'justwork', allowing files of any valid size to be sent -- via Kermit or FTPprotocol -- provided the recipient is capable of creating long files.Examples include (but are not necessarily limited to) Linux on 64-bitarchitectures 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'mnot sure). A great deal of testing and refinement has been done in thisarea for version 9.0, which is still in development but which can bedownloaded and tested by anybody – just CLICKHERE.

THE NEXT RELEASE of C-Kermit will supportlarge files not only on 64-bit platforms but also also on mostrelatively 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.

[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 explanationis that Kermit 7.0 and later 'unprefix' certain control characters bydefault, for speed, but your connection is not transparent to one or more ofthese control characters. This change was made due to popular demand, soKermit protocol transfers would work as fast as possible 'out of the box'without users having to know or SET anything. The downside, of course, isthat high-speed tuning doesn't work on every connection or with everypossible 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]

Best Terminal Emulator Mac

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 asKermit 95 for Windows, can do this).But you can achieve the same effect as follows:

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

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

WHY DOESN'T MY SCRIPT WORK?

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

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

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

HINTS:

• Read the C-Kermit Script Tutorial
• Don't execute scripts with'kermit<scriptfile'.Kermit needs direct access to the script file so it can move back andforth in it, which you can't do with redirected standard input. Again,see the script tutorial.
• In most cases you don't need to script interactions with a modem.There are built-in commands to control the modem for you (DIAL, SET DIAL,SET MODEM, PDIAL, ANSWER, etc). If you don't have a manual, use the HELPcommand to find out about them. Use SET DIAL DISPLAY ON to monitorinteractions between Kermit and the modem.
• Use SET INPUT ECHO ON to observe all interactions while writing anddebugging your script.
• Always include IF SUCCESS or IF FAILURE after everyINPUT or other command that might fail.
• Use LOG SESSION to record all interactions in a file.
• On Telnet connections, don't assume the remote system will issue a login:prompt; it might skip it if your username is sent ahead in the Telnetnegotiations. To prevent this (and therefore force a login prompt), includea 'SET LOGIN USERID' command in your script before it makes the connection.

C-Kermit's script language is thoroughly documented in Chapters 17-19 ofthe manual and lots of sample scripts areavailable 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 PPPdialer in Linux and other kinds of Unix. Until now, there has never beena good answer. There were some half-good answers, such as those found inItem 27 of theKermit FAQ. The problem was that any connection openedby 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 PPPconnection.

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

EXEC[/REDIRECT] command [ arg1 [ arg2 [ ... ] ]

Runs the given command with the arguments in such a way that thecommand 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 theopen files, read/write pointers, working directory, process ID, user ID(unless the command is setuid'd), group ID (unless thecommand is setgid'd), etc; in UNIX, the EXEC command issimply a front end for the execvp() system service.

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

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

Just before the EXEC command, you might also need to send a commandto the terminal server that tells it to start PPP; some terminal serversalways 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':

• You don't have to control the modem itself with AT commands; Kermit'sDIAL command does this for you; thus you don't have to rewrite your scriptif you change modems.
• You can have Kermit automatically redial automatically as many timesas you want until it gets a connection (if that is legal in yourcountry); in this example, three numbers are dialed up to 100 timeseach.
• You can have Kermit fetch the number or numbers from a dialingdirectory.
• You can have Kermit cycle through a list of phone numbers withouthaving to enter the numbers in a dialing directory, as shown above.
• Dialing is location-independent; you can use the same script to dialfrom different areas or countries.
• Once the connection is made, the full power of Kermit's scriptlanguage is available to manage the dialog with the terminal serveror other device that answers the phone call.

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

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

The sample script is not universal, but not that hard to generalize bymaking it a Kerbang script (called, say, 'startppp')that takes phone numbers, username, and password as command-line arguments andprompts 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, preferablyRTS/CTS. The same kind of flow control must be enabled in whatever is on theother end of the serial-port cable (modem, terminal server, computer). Ifyou 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 arestill lost, then on PC-based UNIXes (Linux, FreeBSD, NetBSD, SCO, etc), themost 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 fortwo).
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 everyoperating system (Linux, NetBSD, etc etc). In general, there is aconfiguration file somewhere that lists COM ports, something like this:

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

WHY DOESN'T C-KERMIT REDIAL AUTOMATICALLY?

Automatic redialing is illegal in many countries, so C-Kermit does not do itby default. If you want Kermit to redial modem calls automatically when theyare busy (etc), you can tell Kermit to SET DIAL RETRIES n, wheren is a number specifying how many times the DIAL command is allowed todial 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 ifcorresponds to a country where Kermit knows redialing is legal (e.g. countrycode 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 bydefault. If you want Kermit to use tone dialing, you must tell it to SET DIALMETHOD TONE.

Kermit also automatically uses Tone dialing if it knows your country code(SET DIAL COUNTRY-CODE or the K_COUNTRYCODE environment variable) and ifcorresponds to a country where Kermit knows Tone dialing is universallyaccepted (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