source: trunk/third/kermit/ckuker.bwr @ 10780

Revision 10780, 94.8 KB checked in by brlewis, 27 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r10779, which included commits to RCS files with non-trunk default branches.
1CKUKER.BWR         "Beware File" for C-Kermit Version 6.0         -*- text -*-
3                                 UNIX VERSION
5As of C-Kermit version:  6.0.192
6This file last updated:  Fri Sep  6 23:23:23 1996
8Authors: Frank da Cruz and Christine M. Gianone, Columbia University.
10  Copyright (C) 1985, 1996, Trustees of Columbia University in the City of New
11  York.  The C-Kermit software may not be, in whole or in part, licensed or
12  sold for profit as a software product itself, nor may it be included in or
13  distributed with commercial products or otherwise distributed by commercial
14  concerns to their clients or customers without written permission of the
15  Office of Kermit Development and Distribution, Columbia University.  This
16  copyright notice must not be removed, altered, or obscured.
20This is the "beware file" for the UNIX version of C-Kermit.  It contains
21hints and tips, frequently asked questions (and answers), troubleshooting
22advice, limitations and restrictions, known bugs, etc, that apply to all UNIX
23variations, as well as to specific ones like HP-UX, AIX, SunOS, Solaris,
24Unixware, NeXTSTEP, etc etc.  It should be read in conjunction with the
25system-independent C-Kermit "beware file", ckcker.bwr, which contains similar
26information that applies to all versions of C-Kermit (VMS, OS/2, AOS/VS, VOS,
27etc, as well as to UNIX).
33  (2) BINARIES
35  (3.1) C-KERMIT AND AIX
36  (3.2) C-KERMIT AND HP-UX
39  (3.5) C-KERMIT AND QNX
65C-Kermit is documented in the book "Using C-Kermit" by Frank da Cruz and
66Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1.
67Price: US $39.95.  To order, call Columbia University, New York City,
68at +1 212 854-3703, or Digital Press / Butterworth-Heinemann at:
70  +1 800 366-2665  (Massachusetts office for USA & Canada)
71  +441 1993 414414 (Rushden, England office for Europe)
72  +61 2 372-5511   (Chatswood, NSW, office for Australia & New Zealand)
73  +65 220-3684     (Singapore office for Asia)
75A German edition is available from Verlag Heinz Heise in Hannover, Germany,
76Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 52-1 29.
78New features added since these books were published are documented in the
79ckcker.upd file.
83Please consult the documentation listed above, plus the ckcker.bwr file and
84this file itself, before submitting questions, reporting problems, etc, to:
86  E-Mail:
88    News: comp.protocols.kermit.misc
90    Post: The Kermit Project
91          Columbia University
92          612 West 115th Street
93          New York NY  10025-7799
94          USA
96    Fax: +1 212 663-8202
97     or: +1 212 662-6442
99Telephone support also available:
101  USA Only:  +1 900 555-5595, cost: $2.50 per minute
102  Anywhere:  +1 212 854-5126, cost: $25.00 per call, payable via Visa or MC.
107In addition to the published documentation, the following files are useful
108in troubleshooting:
110    ckaaaa.hlp:  Overview, file naming conventions, list of files, etc.
111    ckuins.doc:  Installation instructions for UNIX C-Kermit.
112    ckccfg.doc:  C-Kermit program configuration information.
113    ckcker.bwr:  C-Kermit "beware file" for all C-Kermit implementations.
114    ckuker.bwr:  C-Kermit "beware file" specific to UNIX (this file).
115    ckcplm.doc:  C-Kermit program logic manual.
116    ckcker.upd:  User documentation for features added since 5A(188).
117    ckcXXX.upd:  Program edit history for edit XXX, e.g. ckc190.upd.
121It is often dangerous to run a binary C-Kermit (or any other) program built
122on a different computer.  Particularly if that computer had a different C
123compiler, libraries, operating system version, processor features, etc, and
124especially if the program was built with shared libraries.
126It is often OK to run a binary built on an earlier OS version, but it is
127rarely possible (or safe) to run a binary built on a later one, for example
128to run a binary built under SunOS 4.1.2 on a SunOS 4.1.1 system.
130When in doubt, build C-Kermit from the source code on the system where it is
131to be run (if possible!).  If not, ask us for a binary specific to your
132configuration.  We might have one, and if we don't, we might be able to get
137The following sections apply to specific UNIX versions.
141Many problems reported with bidirectional terminal lines on AIX 3.2.x on the
142RS/6000.  Workaround: don't use bidirectional terminal lines, or write some
143kind of shell script that turns getty off on the line before starting Kermit,
144or before Kermit attempts to do the SET LINE.  (But note: These problems
145MIGHT be fixed in C-Kermit 6.0.192.)
147Reportedly, all versions of IBM AIX use the same (undocumented) lockfile
148conventions as RTAIX.  If this is true, the "makes" for PS/2 AIX and AIX/370
149will have to be changed to use the RTAIX convention (it may be sufficient to
150simply add -DRTAIX to the make entry).
152C-Kermit SET HOST or TELNET from AIX on an RS/6000 to another RS/6000 won't
153work right unless you set your local terminal type to something other than
154AIXTERM.  When your terminal type is AIXTERM, AIX TELNET sends two escapes
155whenever you type one, and the AIX telnet server swallows one of them.
156This has something to do with the "hft" device.  This behavior is reportedly
157removed in AIX 3.2.
159Transfer of binary -- and maybe even text -- files can fail on AIX 3.x.  The
160problem was traced to a facility in AIX whereby a particular port can have
161character-set translation done for it by the tty driver.  The following
162advice from a knowledgeable AIX user:
164  (begin quote...)  [This feature] has to be checked (and set/cleared) with
165  a separate command, unfortunately stty doesn't handle this.  To check:
167    $ setmaps
168    input map: none installed
169    output map: none installed
171  If it says anthing other than "none installed" for either one, it is likely
172  to cause a problem with kermit.  To get rid of installed maps:
174    $ setmaps -t NOMAP
176  However, I seem to recall that with some versions of AIX before 3.2.5, only
177  root could change the setting.  I'm not sure what versions - it might have
178  only been under AIX 3.1 that this was true.  At least with AIX 3.2.5 an
179  ordinary user can set or clear the maps.  (...end quote) And this would
180  imply that Kermit itself cannot be coded to take care of this, because it
181  would have to run as root.  On the same problem, another knowledgeable AIX
182  user says:
184  The way to get information on the NLS mapping under AIX (3.2.5 anyway) is
185  as follows.  From the command line type:
187    lsattr -l tty# -a imap -a omap -E -H
189  Replace the tty number for the number sign above. This will give a human
190  readable output of the settings that looks like this;
192    # lsattr -l tty2 -a imap -a omap -E -H
193    attribute value description     user_settable
195    imap      none  INPUT map file  True
196    omap      none  OUTPUT map file True
198  If you change the -H to a -O, you get output that can easily be processed
199  by another program or a shell script, for example:
201    # lsattr -l tty2 -a imap -a omap -E -O
202    #imap:omap
203    none:none
205  To change the settings from the command line, the chdev command is used
206  with the following syntax.
208    chdev -l tty# -a imap='none' -a omap='none'
210  Again substituting the appropriate tty port number for the number sign,
211  "none" being the value we want for C-Kermit.  Of course, the above can also
212  be changed by using the SMIT utility and selecting devices - tty.
213  (...end quote)
217During the C-Kermit 6.0 Beta cycle, something happened to ckcpro.w (or, more
218precisely, the ckcpro.c file that is generated from it) which causes HP
219optimizing compilers under HP-UX versions 7.0 and 8.0 (apparently on all
220platforms) as well as under HP-UX 9.0 on Motorola platforms only, to blow up.
221The symptoms vary from the system grinding to a halt, to the compiler
222crashing, to the compilation of the ckcpro.c module taking very long periods
223of time, like 9 hours.
225On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment size),
226seems to be important.  On Motorola systems, it is 16MB by default, whereas on
227RISC systems the default is much bigger.  Increasing maxdsiz to about 80MB
228seems to make the problem go away, but only if the system also has a lot of
229physical memory -- otherwise it swaps itself to death.
231Therefore, the C-Kermit 6.0 makefile entries for HP-UX 7.x and 8.x that do
232optimization, compile ckcpro.c first without optimization.  For HP-UX 9.0, a
233special entry, hpux90mot, was added for Motorola makes; the regular entries
234optimize all modules.
236Even so, the optimizing compiler will often complain about "some optimizations
237skipped" on certain modules, due to lack of space available to the optimizer.
238You can always increase the space (the incantation depends on the particular
239compiler version -- see the makefile), but doing so tends to make the
240compilations take a much longer time.  For example, the "hpux100o+" makefile
241entry adds the "+Onolimit" compiler flag, and about an hour to the compile
242time on an HP-9000/730.  But it *does* produce an executable that is about
24310K smaller :-)
245(3.2.0) Performance
247An unexpected slowness has been noted when transferring files over local
248Ethernet connections when an HP-UX system (9.0 or later, perhaps also earlier
249versions) is on the remote end.   The following experiment was conducted to
250determine the cause.
252The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20), both
253on the same local 10Mbps Ethernet.  Window size 20, packet length 4096, parity
254none, control prefixing "cautious", using only local disks on each machine --
255no NFS.  The file was a 1.08MB binary file (wermit), transferred in binary
256mode.  Conditions were relatively poor: the Sun and the local net heavily
257loaded; the HP system is slow and memory-constrained.
259 Client   Server   Send    Receive
260  Sun      HP       36       18    <-- K cps
261  HP       HP       25       15     
262  HP       Sun      77       83
263  Sun      Sun      60       60
265So whenever HP is the server we have bad performance.  Why?
267 . Changing file display to CRT has no effect (so it's not the curses
268   library on the client side).
270 . Changing TCP RECV-BUFFER or SEND-BUFFER has very little effect.
272 . Telling the client to make a binary-mode connection (SET TELNET BINARY
273   REQUESTED, which successfully negotiates a binary connection) has no effect.
275BUT...  If I start C-Kermit as a TCP server:
277  set host * 3000
278  server
280and then from the client "set host blah 3000", I get:
282 Client   Server   Send    Receive
283  HP       HP       50       50
284  Sun      HP       77       67
285  HP       Sun      57       85
286  Sun      Sun      57       50
288Therefore the HP-UX telnet server or pty driver seems to be adding more
289overhead than the SunOS one, and most others.  When going through this type of
290connection (a remote telnet server) there is nothing Kermit can do improve
291matters, since the telnet server and pty driver are between the two Kermits,
292and neither Kermit can have any influence over them (except putting the Telnet
293connection in binary mode, but that doesn't help).
295(3.2.1) HP-UX 5.21
297Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on the
298HP-9000 series 500 computers.  It only occurs when the controlling terminal
299is using an HP-27140 six-port modem mux.  The problem is not present if the
300controlling terminal is logged into an HP-27130 eight-port mux.  The symptom
301is that just after dialing successfully and connecting Kermit locks up and
302the port is unusable until both forks of Kermit and the login shell are
305(3.2.2) HP-UX 8.05
307To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install HP-UX
308patch PHNE_0899.  This patch deals with a lot of driver issues, particularly
309related to communication at higher speeds.
311(3.2.3) HP-UX 9.00 AND LATER
313HP-UX 9.00 and 9.01 need patch PHNE_3641 for hptt0.o, asio0.o, and ttycomn.o
314in libhp-ux.a.  Contact Hewlett Packard if you need this patch.  Without it,
315the dialout device (tty) will be hung after first use; subsequent attempts to
316use will return an error like "device busy".
318C-Kermit works fine -- including its curses-based file-transfer display -- on
319the console terminal, in a remote session (e.g. when logged in to the HP 9000
320on a terminal port or when telnetted or rlogin'd), and in an HP-VUE hpterm
321window or an xterm window.
323Before you can use serial ports on the HP-9000, you must configure them as
324either "terminals" or "modems" with SAM ("peripheral devices"..."terminals and
325modems"), as described in the HP manual, "Configuring HP-UX for Peripherals:
326HP 9000".  If you attempt to use a serial device before it has been configured
327this way, it will not work properly; typical symptoms are (a) no communication
328at all; (b) nonfunctional modem signals; and/or (c) massive amounts of
329character loss in both directions.
331In HP-UX 9.0, serial device names were different between HP9000 Series 700 and
332Series 800 systems.  In 10.0, device file names (and also major and minor
333numbers) have "converged", as shown in the following table:
335  Converged HP-UX Serial I/O Filenames : TTY Mux Naming
336  ---------------------------------------------------------------------
337  General meaning        S800 9.0          S700 9.0    Convio 10.0
338  ---------------------------------------------------------------------
339  tty* hardwired ports   tty<X>p<Y>        tty<YY>     tty<D>p<p>
340                         diag:mux<X>                   diag:mux<D>
341  ---------------------------------------------------------------------
342  ttyd* dial-in modems   ttyd<X>p<Y>       ttyd<YY>    ttyd<D>p<p>
343                         diag:ttyd<X>p<Y>              diag:ttyd<D>p<p>
344  ---------------------------------------------------------------------
345  cua* auto-dial out     cua<X>p<Y>        cua<YY>     cua<D>p<p>
346                         diag:cua<X>p<Y>
347  ---------------------------------------------------------------------
348  cul* dial-out          cul<X>p<Y>        cul<YY>     cul<D>p<p>
349                         diag:cul<X>p<Y>
350  ---------------------------------------------------------------------
351   <X>= LU (Logical Unit)  <D>= Devspec (decimal card instance)
352   <Y> or <YY> = Port      <p>= Port
354For dialing out, you should use the cua or cul devices.  When C-Kermit's
355CARRIER setting is AUTO or ON, C-Kermit will pop back to its prompt
356automatically if the carrier signal drops, e.g. when you log out from the
357remote computer or service.  If you use the tty<D>p<d> (e.g. tty0p0) device,
358the carrier signal is ignored.  The tty<D>p<d> device should be used for
359direct connections where the carrier signal does not follow RS-232
360conventions (use the cul device for hardwired connections through a true null
361modem).  Do not use the ttyd<D>p<d> device for dialing out.
363Kermit's access to serial devices is controlled by "UUCP lockfiles", which are
364intended to prevent different users using different software programs (Kermit,
365cu, etc, and UUCP itself) from accessing the same serial device at the same
366time.  When a device is in use by a particular user, a file with a special
367name is created in the /var/spool/locks directory.  The file's name indicates
368the device that is in use, and its contents indicates the process ID (pid) of
369the process that is using the device.  Since serial devices and the
370/var/spool/locks directory are not both publicly readable and writable, Kermit
371and other communication software must be installed setuid to the owner (bin)
372of the serial device and setgid to the group (daemon) of the /var/spool/locks
373directory.  Kermit's setuid and setgid privileges are enabled only when
374opening the device and accessing the lockfiles.
376Let's say "unit" means a string of decimal digits (the interface instance
377number) followed by the letter "p" (lowercase), followed by another string of
378decimal digits (the port number on the interface), e.g. "0p0", "0p1", "1p0",
379etc.  Then a normal serial device (driver) name consists of a prefix ("tty",
380"ttyd", "cua", "cul") followed by a unit, e.g. "cua0p0".  Kermit's treatment
381of UUCP lockfiles is as close as possible to that of the HP-UX "cu" program.
382Here is a table of the lockfiles that Kermit creates for unit 0p0:
384  Selection      Lockfile 1     Lockfile 2
385  ------------   ------------   ------------
386  /dev/tty0p0    LCK..tty0p0    (none)
387* /dev/ttyd0p0   LCK..ttyd0p0   (none)
388  /dev/cua0p0    LCK..cua0p0    LCK..ttyd0p0
389  /dev/cul0p0    LCK..cul0p0    LCK..ttyd0p0
390  <other>        LCK..<other>   (none)
392(* = Dialin device, should not be used.)
394The final case allows for symbolic links, etc, but, of course, it is not
395foolproof since we have no way of telling which device is really being used.
397When Kermit tries to open a dialout device whose name ends with a "unit", it
398searches the lockfile directory for all possible names for the same unit.  For
399example, if user selects /dev/cul2p3, Kermit looks for lockfiles named
400LCK..tty2p3, LCK..ttyd2p3, LCK..cua2p3, and LCK..cul2p3.
402If any of these files are found, Kermit opens them to find out the ID (pid) of
403the process that created them; if the pid is still valid, the process is still
404active, and so the SET LINE command fails and the user is informed of the pid
405so s/he can use "ps" to find out who is using the device.
407If the pid is not valid, the file is deleted.  If all such files (i.e. with
408same "unit" designation) are successfully removed, then the SET LINE command
409succeeds; up to four messages are printed telling the user which "stale
410lockfiles" are being removed.
412If the selected device was in use by "cu", Kermit can't open it, because "cu"
413has changed its ownership, so we never get as far as looking at the lockfiles.
414In the normal case, we can't even look at the device to see who the owner is
415because it is visible only to its (present) owner.  In this case, Kermit says
416(for example):
418  /dev/cua0p0: Permission denied
420When Kermit releases a device it has successfully opened, it removes all the
421lockfiles that it created.  This also happens whenever Kermit exits "under its
422own power".
424If Kermit is killed with a device open, the lockfile(s) are left behind.  The
425next Kermit program that tries to assign the device, under any of its various
426names, will automatically clean up the stale lockfiles because the pids
427they contain are invalid.
429(3.2.4) HP-UX 10.10 AND LATER
431C-Kermit is included as part of the HP-UX 10.xx operating system by contract
432between Hewlett Packard and Columbia University.  Each level of HP-UX 10.xx
433includes a freshly built C-Kermit binary in /bin/kermit, which should work
434correctly.  However, if you are building your own or downloading from
435Columbia, you should be aware that you can only use a binary that was built
436under the same OS level as you are running.  As of C-Kermit version 6.0, HP-UX
43710.xx binaries announce, in the startup herald and the VERSION command, the
438explicit HP-UX version they were built for: HP-UX 10.00, 10.10, 10.20, or
43910.30.  If there is a version mismatch, HP-UX does something like "Invalid
440version for shared lib /usr/lib/libc.1, IOT trap (core dumped)".
442Beginning in 10.10, libcurses is linked to libxcurses, the new UNIX95 (X/Open)
443version of curses, which has some serious bugs; some routines, when called,
444would hang and never return, some would dump core.  Evidently libxcurses
445contains a select() routine, and whenever C-Kermit calls what it thinks is the
446regular (sockets) select(), it gets the curses one, causing a segmentation
447fault.  There is a patch for this from HP, PHCO_8086, "s700_800 10.10
448libcurses patch", "shared lib curses program hangs on 10.10", "10.10 enhanced
449X/Open curses core dumps due to using wrong select call", 96/08/02 (you can
450tell if the patch is installed with "what /usr/lib/libxcurses.1"; the unpatched
451version is 76.20, the patched one is  It has been verified that
452C-Kermit works OK with the patched library, but results are not definite for
453HP-UX 10.20 or higher. 
455To ensure that C-Kermit works even on non-patched HP-UX 10.10 systems,
456separate makefile entries are provided for HP-UX 10.00/10.01, 10.10, 10.20,
457etc, in which the entries for 10.10 and above link with libHcurses, which is
458"HP curses", the one that was used in 10.00/10.01.
462Be sure to read the comments in the "linux:" makefile entry.  There are all
463sorts of confusing issues caused by the many and varied Linux distributions.
464Some of the worst involve the curses library and header files: where are they,
465what are they called, which ones are they really?  Ditto for UUCP lock files.
467Run C-Kermit in the regular console screen, which provides VT100 emulation via
468the "console" termcap entry, or under X-Windows in an xterm window.  Before
469starting C-Kermit in an xterm window, tell the xterm window's shell to "stty
472How to set up your PC console keyboard to send VT220 key sequences when using
473C-Kermit as your communications program in an X terminal window: Create a file
474somewhere (e.g. in /root/) called .xmodmaprc, containing something like the
477  keycode 77  = KP_F1       ! Num Lock     => DEC Gold (PF1)
478  keycode 112 = KP_F2       ! Keypad /     => DEC PF1
479  keycode 63  = KP_F3       ! Keypad *     => DEC PF3
480  keycode 82  = KP_F4       ! Keypad -     => DEC PF4
481  keycode 111 = Help        ! Print Screen => DEC Help
482  keycode 78  = F16         ! Scroll Lock  => DEC Do
483  keycode 110 = F16         ! Pause        => DEC Do
484  keycode 106 = Find        ! Insert       => DEC Find
485  keycode 97  = Insert      ! Home         => DEC Insert
486  keycode 99  = 0x1000ff00  ! Page Up      => DEC Remove
487  keycode 107 = Select      ! Delete       => DEC Select
488  keycode 103 = Page_Up     ! End          => DEC Prev Screen
489  keycode 22  = Delete      ! Backspace sends Delete (127)
491Then put "xmodmap <filename>" in your .xinitrc file (in your login
492directory), e.g.
494  xmodmap /root/.xmodmaprc
496Of course you can move things around.  Use the xev program to find out key
499Different UUCP lockfile conventions are used by Linux, depending on your Linux
500distribution.  In C-Kermit 6.0, "make linux" uses /var/lock/, decimal
501ASCII 10-byte PID string with leading spaces because -DLINUXFSSTND ("Linux File
502System Standard") is included in the compilation CFLAGS.  If you remove this
503definition, C-Kermit will use the earlier arrangement of integer PID,
504/usr/spool/uucp/  The leading spaces are required by FSSTND 1.2, but
505FSSTND 1.0 required leading zeros; to get the leading zeros, also include
506-DFSSTND10.  Use whichever option agrees with your uucp, cu, tip, etc,
509Building C-Kermit on Linux 1.1.33 and 1.1.34 gets fatal compilation errors
510due to inconsistencies in the Linux header files.  Linux kernel versions prior
511to 1.1.33 and later than 1.1.34 should be OK.
513C-Kermit versions prior to 5A(190) did not support hardware flow control or
514high interface speeds for Linux.
516One Linux user reported problems dialing out using the /dev/cua device;
517"device busy" errors.  He said that using the alternative name (driver) for
518the device, /dev/ttyS2, made the problem go away.
520Reportedly there is a bug in gcc 2.5.8 with signed to unsigned compares
521that can wreak havoc when Kermit (or most any other program) is compiled with
522this version of gcc; reportedly this can be worked around, at least in part,
523by adding "-fno-unroll-loops" to the gcc compilation options.
525Reportedly, if you have the iBCS2 (Intel Binary Compatibility Standard 2)
526module installed, you can also run SCO Xenix and UNIX binaries under Linux,
527including the SCO C-Kermit binaries, shareable libraries and all.
528(iCBS2 is available via anonymous ftp from, along with an
529SCO libc_s compatibility module for Linux).
531Some Linux users reported that after doing a file transfer using the
532fullscreen display (thermometer), that "screen scrolling locks up" and the
533cursor "is stuck on the bottom of the screen".  This probably only happens
534when using the console device.  This turns out to be a problem with Linux
535ncurses.  The workaround is to use "set file display crt" or "serial".  The
536cure (reportedly) is to build C-Kermit with Linux ncurses 1.8.7 (or later).
538(Time passes...)  Now (early 1996) we have increasing reports of C-Kermit core
539dumping in Linux 1.2.x, e.g. when the "set line" command is given.  But they
540are conflicting -- it happens to some people, not to others.  Not much can be
541said about this but:
543From: (Frank da Cruz)
544Newsgroups: comp.protocols.kermit.misc
545Subject: Re: Kermit drops core at SET LINE /dev/cua1
546Date: 14 Feb 1996 15:43:07 GMT
547Organization: Columbia University
549In article <4fr2nc$>,
550Branden Robinson <> wrote:
551: I'm trying to run C-Kermit under Linux, but as soon as I type "set line
552: /dev/cua1", kermit gets a segmentation fault.  This is the correct line, as
553: evidenced by the fact that "echo ATDT" and a phone number redirected to
554: /dev/cua1 makes the modem dial.
556: I thought this might have something to do with the lock file put on
557: /dev/cua1, but both the compliation with the -DLINUXFSSTND and without it
558: yield the same result.  What is going on here?
560: Relevant hardware:
561:  Hayes Accura 14.4 + FAX internal on COM 2
563: Relevant software:
564:  Linux Debian 0.93R6, kernel 1.2.13, GCC 2.6.3, C-kermit 1.90
566C-Kermit 5A(190) was tested successfully on every known Linux variation at
567the time it was released (October 1994), but since then what is
568collectively known as Linux has been changing rapidly out from underneath
569us, thanks in large part to its numerous repackagers.  Most of the
570problems stem from the many and varied curses libraries; this is the first
571report I have heard of this nature.  You might try:
573 1. The Debian C-Kermit distribution, put together and tested by the
574    Debian Project.  Maybe they linked it with different libraries than
575    you did:
579 2. The 6.0.192 Alpha not-yet-a-release:
583 3. Taking a debug log of a core-dumping session and sending the last
584    hundred lines or so to for analysis.  Also see if
585    you can get a backtrace from the core file to find out what routine it
586    was in when it faulted.  I don't know what the command for this is on
587    Linux -- locally I use "adb kermit core" and then "$c", where "kermit"
588    is Kermit's pathname and "core" is the core file's pathname.
589 (John D. Griffith) replies:
591Well I am succesfully using C-kermit 1.90 with the same modem on
592/dev/cua2 (COM3).  I am running linux 1.2.13 (a.out) and gcc 2.5.8.
593My distribution was originally Red Hat Release 1.0, but has been
594considerably customized since then.
595 (Bill Mitchell) replies:
597I'm the debian kermit maintainer, but I'm afraid I don't have much
598of a clue about this.  The debian kermit sources are stock kermit
599sources except for the addition of some debian-specific files (debian.*)
600which don't impact non-debian compilation and the addition of a debian
601target in debian.makefile.
602I use kermit regularly on my debian linux system with the 1.2.13 kernel,
603and my modem is on /dev/cua1.
605And in the same vein...
607Date: Wed, 15 Nov 95 10:16:24 EST
608From: Frank da Cruz <>
609To: kurt klingbeil <>
610Subject: Re: cku190 & linux 1.1.59 vs 1.2.x ??
611In-Reply-To: Your message of Tue, 14 Nov 1995 23:57:21 -0700 (MST)
613> Any idea what's changed in the serial handling of linux
614> between 1.1.x and 1.2.x ?
616Absolutely no idea.  It's just the way of the world.  The rule is that if
617Kermit works in release n of any operating system, then release n+1 breaks it.
618I think this must be an internal requirement for OS developers.  The nice
619thing about Linux is you don't even know who to ask about it.
621> Using cku190 to connect to a USR v.everything (no getty or any other process
622> active on that tty port):
623> I can dial, connect, run a remote session.
624> When I hangup, the loss of CD causes kermit
625> to disconnect, drop RTS and DTR, and return to its prompt.
627> When attempting to immediately re-connect to the modem
628> (using c command), I can see the DTR and RTS lines being brought up:
629> (The modem's CTS and DSR remain set at all times.)
631> Under Linux 1.1.59, kermit is immediately able to communincate with
632> the modem.  Under Linux 1.2.{3,8,13} kermit appears to be hung -
633> no modem responses are received, kermit ignores it's escape character
634> and will wait forever.  If one sends kermit a signal (either via kill,
635> or, if one is on the console via break (control-C is ignored as well)),
636> then a few characters of garbage appear in kermit's session, and
637> things are back to normal.
639> I suspect that either a previously non-blocking read is now a blocking
640> read, or that previously the port was being properly flushed before
641> a connection was made, and that under 1.2.x it isn't and hence kermit
642> gets deadlocked waiting forever for a conidition which never occurs.
644> Any ideas ?
646(Unhelpful response deleted)
648Could this be the explanation? --
650Date: Sat, 13 Jan 1996 09:48:11 -0800 (PST)
651From: John Harris <>
652Subject: C-Kermit Installation on Linux 1.2.1
654Below is a letter which addresses the problem I was having installing
655C-Kermit on a Linux platform.  So you do not need to waste your time
656addressing my difficulty, I wish to inform you that I have just resolved
657it; that is, the compile now takes place without even a warning.
659So that someone else can benefit, I briefly describe the cause of the
660problem.  The following directories were not present: /usr/include/linux/
661and /usr/src/linux/include/asm.  There may also have been other files
662missing in certain directories; for example, /usr/include/linux and
663/usr/include/asm.  The problem may have arisen from an oversight during
664Linux installation; for example, I may have forgotten to create the file
665system in advance of installation with "mke2fs -c <partition> <size>" or
666perhaps I simply neglected to transfer some library files during the
667software installation itself.
669In more recent releases of Linux (mid-1996), the trend is to replace curses by
670ncurses.  But of course this is not transparent to application software that
671includes curses.h and links with libcurses.  Linus says it *should* be
672transparent -- the application should continue to refer to curses and not to
673ncurses.  C-Kermit follows this recommendation, so if you have curses-related
674trouble during compilation or at runtime, create symbolic links called
675curses.h and libcurses.a (or .sa, or .so, or .so.XX, etc) pointing to
676ncurses.h and libncurses-dot-whatever, and rebuild Kermit.
678Also note that some Linux distributions have internal problems in their header
679files.  In one case, there are fatal errors in <termcap.h> that can be fixed
680by adding "#include <termios.h>" to the termcap.h file.
682See additional comments in the Linux entry in the makefile.
686Run C-Kermit in a Terminal, Stuart, or xterm window, or when logged in
687remotely through a serial port or TELNET connection.  C-Kermit does not work
688correctly when invoked directly from the NeXTSTEP File Viewer or Dock.  This
689is because the terminal-oriented gtty, stty, & ioctl calls don't work on the
690little window that NeXTSTEP pops up for non-NeXTSTEP applications like Kermit.
691CBREAK and No-ECHO settings do not take effect in the command parser --
692commands are parsed strictly line at a time.  "set line /dev/cua" works.
693During CONNECT mode, the console stays in cooked mode, so characters are not
694transmitted until carriage return or linefeed is typed, and you can't escape
695back.  If you want to run Kermit directly from the File Viewer, then launch it
696from a shell script that puts it in the desired kind of window, something like
697this (for "Terminal"):
699  Terminal -Lines 24 -Columns 80 -WinLocX 100 -WinLocY 100 $FONT $FONTSIZE \
700  -SourceDotLogin -Shell /usr/local/bin/kermit &
702C-Kermit does not work correctly on a NeXT with NeXTSTEP 3.0 to which you have
703established an rlogin connection, due to a bug in NeXTSTEP 3.0, which has been
704reported to NeXT.
706The SET CARRIER command has no effect on the NeXT -- this is a limitation of
707the tty device drivers.
709Hardware flow control on the NeXT is selected not by "set flow rts/cts" in
710Kermit (since NeXTSTEP offers no API for this), but rather, by using a
711specially-named driver for the serial device: /dev/cufa instead /dev/cua;
712/dev/cufb instead of /dev/cub.  This is available only on 68040-based NeXT
713models (the situation for Intel NeXTSTEP implementations is unknown).
715NeXT-built 68030 and 68040 models have different kinds of serial interfaces;
716the 68030 has a Macintosh-like RS-422 interface, which lacks RTS and CTS
717signals; the 68040 has an RS-423 (RS-232 compatible) interface, which
718supports the commonly-used modem signals.  WARNING: the connectors look
719exactly the same, but the pins are used in completely DIFFERENT ways --
720different cables are required for the two kinds of interfaces.
722  IF YOU GET LOTS OF RETRANSMISSIONS during file transfer, even when
723  using a /dev/cuf* device and the modem is correctly configured for
726On the NeXT, Kermit reportedly (by TimeMon) causes the kernel to use a lot of
727CPU time when using a "set line" connection.  That's because there is no DMA
728channel for the NeXT serial port, so the port must interrupt the kernel for
729each character in or out.
731One user reported trouble running C-Kermit on a NeXT from within NeXT's
732Subprocess class under NeXTstep 3.0, and/or when rlogin'd from one NeXT to
733another: Error opening /dev/tty:, congm: No such device or address.
734Diagnosis: Bug in NeXTSTEP 3.0, cure unknown.
738Support for QNX 4.x was added in C-Kermit 5A(190).  This is a full-function
739implementation, thoroughly tested on QNX 4.21, and verified to work in both
74016-bit and 32-bit versions.  Most advanced features are supported including
741TCP/IP, high serial speeds, hardware flow-control, modem-signal awareness,
742curses support, etc.
744Dialout devices are normally /dev/ser1, /dev/ser2, ..., and can be opened
745explicitly with SET LINE.  Reportedly, "/dev/ser" (no unit number) opens the
746first available /dev/ser<n> device.
748Like all other UNIX C-Kermit implementations, QNX C-Kermit does not provide
749any kind of terminal emulation.  Terminal specific functions are provided by
750your terminal, terminal window (e.g. QNX Terminal or xterm), or emulator.
752QNX C-Kermit, as distributed, does not include support for UUCP line-locking;
753the QNX makefile entries (qnx32 and qnx16) include the -DNOUUCP switch.  This
754is because QNX, as distributed, does not include UUCP, and its own
755communications software (e.g. qterm) does not use UUCP line locking.  If you
756have a UUCP product installed on your QNX system, remove the -DNOUUCP switch
757from the makefile entry and rebuild.  Then check to see that Kermit's UUCP
758lockfile conventions are the same as those of your UUCP package; if not, read
759the UUCP lockfile section ckuins.doc and make the necessary changes to the
760makefile entry (e.g. add -DHDBUUCP).
762BUG: The fullscreen file transfer display works fine the first time, but it is
763fractured on subsequent file transfers.  Cause and cure unknown.
767There is all sorts of confusion among SCO versions, particularly when third-
768party communications boards and drivers are installed, regarding lockfile
769naming conventions.  Basically, all bets are off if you are using a third
770party multiport board.  At least you have the source code.  Hopefully you also
771have a C compiler :-)
773Use SCO-provided utilities for switching the directionality of a modem line,
774such as "enable" and "disable" commands.  For example, to dial out on tty1a,
775which is normally set up for logins:
777  disable tty1a
778  kermit -l /dev/tty1a
779  enable tty1a
781In SCO Xenix, you must use SET CARRIER ON *and* use the upper-case tty device
782name in order to have carrier detection.  SET CARRIER OFF should work with
783either upper or lowercase tty devices.  SET CARRIER AUTO is the same as OFF.
785SCO Xenix and UNIX can provide different names for the same device.  In Xenix,
786/dev/tty1a refers to a terminal device that has no modem control; open, read,
787write, and close operations do not depend on carrier.  On the other hand,
788/dev/tty1A (same name, but with final letter upper case), is the same device
789with modem control, in which carrier is required (the SET LINE command does
790not complete until carrier appears, read/write operations fail if there is no
791carrier, etc).  In the SCO case, C-Kermit always uses the lowercase name when
792creating the UUCP lockfile (this is, according to SCO experts, the proper
793behavior, but reportedly not all other communications applications found on
794SCO systems follow this rule).
796One user of C-Kermit 5A(190) on SCO UNIX 3.2.4 reported that C-Kermit dumps
797core when receiving files in local mode.  The crash invariably occurs when the
79816384th byte arrives, obviously indicating some kind of int/long, or
799short/int, or similar mismatch in argument-passing -- no doubt the byte count.
800Other users of SCO UNIX 3.2.4, built using the same makefile entry, report
801that they can receive files of any length with no problem at all.  Maybe it
802depends on which file transfer display is being used?  If this happens to you,
803try using a different file transfer display (SET FILE DISPLAY NONE, SERIAL,
806SCO users report that only one copy of Kermit can run at a time when a
807Stallion Technologies multiport boards are installed.
811The built-in SunLink X.25 support for Solaris 2.3/2.4./25 and SunLink 8.01 or
8129.00 works OK provided the X.25 system has been installed and initialized
813properly.  Packet sizes might need to be reduced to 256, maybe even less,
814depending on the configuration of the X.25 installation.  On one connection
815where C-Kermit 6.0 was tested, very large packets and window sizes could be
816used in one direction, but only very small ones would work in the other.
818In any case, according to Sun, C-Kermit's X.25 support is superfluous with
819SunLink 8.x / Solaris 2.3.  Quoting an anonymous Sun engineer:
821  ... there is now no need to include any X.25 code within kermit.  As of
822  X.25 8.0.1 we support the use of kermit, uucp and similar protocols over
823  devices of type /dev/xty.  This facility was there in 8.0, and should
824  also work on the 8.0 release if patch 101524 is applied, but I'm not 100%
825  sure it will work in all cases, which is why we only claim support from
826  8.0.1 onwards.
828  When configuring X.25, on the "Advanced Configuration->Parameters" screen
829  of the x25tool you can select a number of XTY devices.  If you set this
830  to be > 1, press Apply, and reboot, you will get a number of /dev/xty
831  entries created.
833  Ignore /dev/xty0, it is a special case.  All the others can be used exactly
834  as if they were a serial line (e.g. /dev/tty) connected to a modem, except
835  that instead of using Hayes-style commands, you use PAD commands.
837  From kermit you can do a 'set line' command to, say, /dev/xty1, then set
838  your dialing command to be "CALL 12345678", etc.  All the usual PAD
839  commands will work (SET, PAR, etc).
841  I know of one customer in Australia who is successfully using this, with
842  kermit scripts, to manage some X.25-connected switches. He used standard
843  kermit, compiled for Solaris 2, with X.25 8.0 xty devices.
845C-Kermit can't be compiled successfully under Solaris 2.3 using SUNWspro cc
8462.0.1 unless at least some of the following patches are applied to cc (it is
847not known which one(s), if any, fix the problem):
849  100935-01 SparcCompiler C 2.0.1: bad code generated when addresses
850    of two double arguments are involved
851  100961-05 SPARCcompilers C 2.0.1: conditional expression with
852    function returning strucure gives wrong value
853  100974-01 SparcWorks 2.0.1: dbx jumbo patch
854  101424-01 SPARCworks 2.0.1 maketool SEGV's instantly on Solaris 2.3
856With unpatched cc 2.0.1, the symptom is that certain modules generate
857truncated object files, resulting in many unresolved references at link time.
859Using a Sun workstation keyboard for VT emulation when accessing VMS:
861From: Jerry Leichter <>
862Newsgroups: comp.os.vms
863Subject: Re: VT100 keyboard mapping to Sun X server
864Date: Mon, 19 Aug 1996 12:44:21 -0400
866> I am stuck right now using a Sun keyboard (type 5) on systems running SunOS
867> and Solaris.  I would like to use EVE on an OpenVMS box with display back to
868> the Sun.  Does anyone know of a keyboard mapping (or some other procedure)
869> which will allow the Sun keyboard to approximate a VT100/VT220?
871You can't get it exactly - because the keypad has one fewer key - but
872you can come pretty close.  Here's a set of keydefs I use:
874keycode 101=KP_0
875keycode 119=KP_1
876keycode 120=KP_2
877keycode 121=KP_3
878keycode 98=KP_4
879keycode 99=KP_5
880keycode 100=KP_6
881keycode 75=KP_7
882keycode 76=KP_8
883keycode 77=KP_9
884keycode 52=KP_F1
885keycode 53=KP_F2
886keycode 54=KP_F3
887keycode 57=KP_Decimal
888keycode 28=Left
889keycode 29=Right
890keycode 30=KP_Separator
891keycode 105=KP_F4
892keycode 78=KP_Subtract
893keycode 8=Left
894keycode 10=Right
895keycode 32=Up
896keycode 33=Down
897keycode 97=KP_Enter
899Put this in a file - I use "keydefs" in my home directory and feed it
900into xmodmap:
902  xmodmap - <$HOME/keydefs
904This takes care of the arrow keys and the "calculator" key cluster.  The
905"+" key will play the role of the DEC "," key.  The Sun "-" key will be
906like the DEC "-" key, though it's in a physically different position -
907where the DEC PF4 key is.  The PF4 key is ... damn, I'm not sure where
908"key 105" is.  I *think* it may be on the leftmost key of the group of
909four just above the "calculator" key cluster.
911I also execute the following (this is all in my xinitrc file):
913xmodmap -e 'keysym KP_Decimal = KP_Decimal'
914xmodmap -e 'keysym BackSpace = Delete BackSpace' \
915        -e 'keysym Delete = BackSpace Delete'
916xmodmap -e 'keysym KP_Decimal = Delete Delete KP_Decimal'
917xmodmap -e 'add mod1 = Meta_R'
918xmodmap -e 'add mod1 = Meta_L'
920Beware of one thing about xmodmap:  Keymap changes are applied to the
921*whole workstation*, not just to individual windows.  There is, in fact,
922no way I know of to apply them to individual windows.  These definitions
923*may* confuse some Unix programs (and/or some Unix users).
925If you're using Motif, you may also need to apply bindings at the Motif
926level.  If just using xmodmap doesn't work, I can try and dig that stuff
927up for you.
929(end quote)
931  NOTE: The rest of the problems in this section have to do with bidirectional
932  tty lines and the Solaris Port Monitor.  Hopefully these are all fixed in
933  C-Kermit 6.0.192 Beta.029, 22 Aug 96.
935Reportedly, "C-Kermit ... causes a SPARCstation running Solaris 2.3
936to panic after the modem connects.  I have tried compiling C-Kermit with Sun's
937unbundled C compiler, with GCC Versions 2.4.5 and 2.5.3, with make targets
938'sunos51', 'sunos51tcp', 'sunos51gcc', and even 'sys5r4', and each time it
939compiles and starts up cleanly, but without fail, as soon as I dial the number
940and get a 'CONNECT' message from the modem, I get:
943  kermit: Data fault
944  kernel read fault at addr=0x45c, pme=0x0
945  Sync Error Reg 80 <INVALID>
946  ...
947  panic: Data Fault.
948  ...
949  Rebooting...
951The same modem works fine for UUCP/tip calling."  Also (reportedly), this only
952happens if the dialout port is configured as in/out via admintool.  If it is
953configured as out-only, no problem.  This is the same dialing code that works
954on hundreds of other System-V based UNIX OS's.  Since it should be impossible
955for a user program to crash the operating system, this problem must be chalked
956up to a Solaris bug.  Even if you SET CARRIER OFF, CONNECT, and dial manually
957by typing ATDTnnnnnnn, the system panics as soon as the modem issues its
958CONNECT message.  (Clearly, when you are dialing manually, C-Kermit does not
959know a thing about the CONNECT message, and so the panic is almost certainly
960caused by the transition of the Carrier Detect (CD) line from off to on.)
961This problem was reported by many users, all of whom say that C-Kermit worked
962fine on Solaris 2.1 and 2.2.  If the speculation about CD is true, then a
963possible workaround might be to configure the modem to leave CD on (or off)
964all the time.  Perhaps by the time you read this, a patch will have been
965issued for Solaris 2.3.
967The following is from Karl S. Marsh, Systems & Networks Administrator,
968AMBIX Systems Corp, Rochester, NY (begin quote):
971  Solaris 2.3 Patch 101318-45
972  C-Kermit 5A(189) (and presumably this applies to 188 and 190 also)
973  eeprom setting:
974    ttya-rts-dtr-off=false
975    ttya-ignore-cd=false
976    ttya-mode=19200,8,n,8,-
978"To use C-Kermit on a bidirectional port in this environment, do not use
979admintool to configure the port.  Use admintool to delete any services running
980on the port and then quit admintool and issue the following command:
982  pmadm -a -p zsmon -s ttyb -i root -fu -v 1 -m "`ttyadm -b -d /dev/term/b \
983  -l conttyH -m ldterm,ttcompat -s /usr/bin/login -S n`"
985[NOTE: This was copied from a fax, so please check it carefully]  where:
987  -a = Add service
988  -p = pmtag (zsmon)
989  -s = service tag (ttyb)
990  -i = id to be associated with service tag (root)
991  -fu = create utmp entry
992  -v = version of ttyadm
993  -m = port monitor-specific portion of the port monitor administrative file
994       entry for the service
995  -b = set up port for bidirectional use
996  -d = full path name of device
997  -l = which ttylabel in the /etc/ttydefs file to use
998  -m = a list of pushable STREAMS modules
999  -s = pathname of service to be invoked when connection request received
1000  -S = software carrier detect on or off (n = off)
1002"This is exactly how I was able to get Kermit to work on a bi-directional
1003port without crashing the system."  (End quote)
1005On the Solaris problem, also see SunSolve Bug ID 1150457 ("Using C-Kermit, get
1006Bad Trap on receiving prompt from remote system").  Another user reported "So,
1007I have communicated with the Sun tech support person that submitted this bug
1008report [1150457].  Apparently, this bug was fixed under one of the jumbo
1009kernel patches.  It would seem that the fix did not live on into 101318-45, as
1010this is EXACTLY the error that I see when I attempt to use kermit on my
1013Later (Aug 94)...  C-Kermit dialout successfully tested on a Sun4m with a
1014heavily patched Solaris 2.3.  The patches most likely to have been relevant:
1016101318-50: SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
1017101720-01: SunOS 5.3: ttymon - prompt not always visible on a modem connection
1018101815-01: SunOS 5.3: Data fault in put() NULL queue passed from
1019                      ttycommon_qfull()
1020101328-01: SunOS 5.3: Automation script to properly setup tty ports prior to
1021                      PCTS execution
1023Still later (Nov 94): another user (Bo Kullmar in Sweden) reports that after
1024using C-Kermit to dial out on a bidirectional port, the port might not answer
1025subsequent incoming calls, and says "the problem is easy enough to to fix with
1026the Serial Port Manager; I just delete the service and and install it again
1027using the graphical interface, which underneath uses commands like sacadm and
1028pmadm."  Later Bo reports, "I have found that if I run Kermit with the
1029following script then it works.  This script is for /dev/cua/a, -s a is the
1030last a in /dev/cua/a
1032  #! /bin/sh
1033  kermit
1034  sleep 2
1035  surun pmadm -e -p zsmon -s a
1037(end quote)
1041Sun SPARCstation users should read the section "Setting up Modem Software" in
1042the Desktop SPARC Sun System & Network Manager's Guide.  If you don't set up
1043your serial ports correctly, Kermit (and other communications software) won't
1044work right.
1046Reportedly, C-Kermit does not work correctly on a Sun SPARCstation in an Open
1047Windows window with scrolling enabled.  Disable scrolling, or else invoke
1048Kermit in a terminal emulation window (xterm, crttool, vttool) under SunView
1049(this might be fixed in later SunOS releases).
1051On the Sun with Open Windows, an additional symptom has been reported:
1052outbound SunLink X.25 connections "magically" translate CR typed at the
1053keyboard into LF before transmission to the remote host.  This doesn't happen
1054under SunView.
1056SET CARRIER ON, when used on the SunOS 4.1 version of C-Kermit (compiled in
1057the BSD universe), causes the program to hang uninterruptibly when SET LINE
1058is issued for a device that is not asserting carrier.  When Kermit is built
1059in the Sys V universe on the same computer, there is no problem (it can be
1060interrupted with Ctrl-C).  This is apparently a limitation of the BSD-style
1061tty driver.
1063SunOS 4.1 C-Kermit has been observed to dump core when running a complicated
1064script program under cron.  The dump invariably occurs in ttoc(), while trying
1065to output a character to a TCP/IP TELNET connection.  ttoc() contains a
1066write() call, and when the system or the network is very busy, the write()
1067call can get stuck for long periods of time.  To break out of deadlocks caused
1068by stuck write() calls, there is an alarm around the write().  It is possible
1069that the core dump occurs when this alarm signal is caught.  (This one has
1070not been observed recently -- possibly fixed in edit 190.)
1072On Sun computers with SunOS 4.0 or 4.1, SET FLOW RTS/CTS works only if the
1073carrier signal is present from the communication device at the time when
1074C-Kermit enters packet mode or CONNECT mode.  If carrier is not sensed (e.g.
1075when dialing), C-Kermit does not attempt to turn on RTS/CTS flow control.
1076This is because the SunOS serial device driver does not allow characters to
1077be output if RTS/CTS is set (CRTSCTS) but carrier (and DSR) are not present.
1078Workaround (maybe):  SET CARRIER OFF before giving the SET LINE command,
1079establish the connection, then SET FLOW RTS/CTS
1081It has also been reported that RTS/CTS flow control under SunOS 4.1 through
10824.1.3 works only on INPUT, not on output, and that there is a patch from Sun
1083to correct this problem: Patch-ID# T100513-04, 20 July 1993 (this patch might
1084apply only to SunOS 4.1.3).  It might also be necessary to configure the
1085eeprom parameters of the serial port; e.g. do the following as root at the
1086shell prompt:
1088  eeprom  ttya-ignore-cd=false
1089  eeprom  ttya-rts-dtr-off=true
1091There have been reports of file transfer failures on Sun-3 systems when using
1092long packets and/or large window sizes.  One user says that when this happens,
1093the console issues many copies of this message:
1095  chaos vmunix: zs1: ring buffer overflow
1097This means that SunOS is not scheduling Kermit frequently enough to service
1098interrupts from the zs serial device (Zilog 8350 SCC serial communication
1099port) before its input silo overflows.  Workaround: use smaller packets
1100and/or a smaller window size, or use "nice" to increase Kermit's priority.
1101Use hardware flow control if available, or remove other active processes
1102before running Kermit.
1104SunLink X.25 support in C-Kermit 5A(190) has been built and tested
1105successfully under SunOS 4.1.3b and SunLink X.25 7.00.
1109There is no hardware flow control in Ultrix.  That's not a Kermit deficiency,
1110but an Ultrix one.
1112Reportedly, DEC ULTRIX 4.3 is immune to C-Kermit's disabling of SIGQUIT,
1113which is the signal that is generated when the user types Ctrl-\, which kills
1114the current process (i.e. C-Kermit) and dumps core.  Diagnosis and cure
1115unknown.  Workaround: before starting C-Kermit -- or for that matter, when you
1116first log in because this applies to all processes, not just Kermit -- give
1117the following UNIX command:
1119  stty quit undef
1121Certain operations driven by RS-232 modem signal do not work on DECstations or
1122other DEC platforms whose serial interfaces use MMP connectors (DEC version of
1123RJ45 telephone jack with with offset tab).  These connectors convey only the
1124DSR and DTR modem signals, but not carrier (CD), RTS, CTS, or RI.  Use SET
1125CARRIER OFF to enable communication, or "hotwire" DSR to CD.
1129Using the UnixWare 1.1 Application Server, one user reports a system panic
1130when the following script program is executed:
1132  set line /dev/tty4
1133  set speed 9600
1134  output \13
1135  connect
1137The panic does not happen if a PAUSE is inserted:
1139  set line /dev/tty4
1140  set speed 9600
1141  pause 1
1142  output \13
1143  connect
1145This is using a Stallion EasyIO card installed as board 0 on IRQ 12 on
1146a Gateway 386 with the Stallion-supplied driver.  The problem was reported
1147to Novell and Stallion, resolution pending.  (Reportedly, this problem
1148is now fixed.)
1152Reportedly, version 5A(190), when built under Apollo SR10 using "make
1153sr10-bsd", compiles, links, and executes OK, but leaves the terminal unusable
1154after it exits -- the "cs7" or "cs8" (character size) parameter has become
1155cs5.  The terminal must be reset from another terminal.  Cause and cure
1156unknown.  Suggested workaround: Wrap Kermit in a shell script something like:
1158  kermit @*
1159  stty sane
1163Reportedly, if you type lots of Ctrl-C's during execution of the
1164initialization file, ghost Kermit processes will be created, and will compete
1165for the keyboard.  They can only be removed via "kill -9" from another
1166terminal, or by rebooting.  Diagnosis -- something strange happening with
1167the SIGINT handler while the process is reading the directory (it seems to
1168occur during the SET PROMPT [\v(dir)] ... sequence).  Cure: unknown.
1169Workaround: don't interrupt C-Kermit while it is executing its init file on
1170the Tandy 16/6000.
1174Reportedly, if a modem is set for &S0 (assert DSR at all times), the system
1175resets or drops DTR every 30 seconds; reportedly DEC says to set &S1.
1177Digital UNIX 3.2 evidently wants to believe your terminal is one line longer
1178than you say it is, e.g. when a "more" or "man" command is given.  This is has
1179nothing to do with C-Kermit, but tends to annoy those who use Kermit or other
1180terminal emulators to access Digital UNIX systems.  Workaround: tell UNIX
1181to "stty rows 23" (or whatever).
1185Reportedly on Silicon Graphics (SGI) machines with IRIX 4.0, Kermit cannot be
1186suspended by typing the suspend ("swtch") character if it was started from
1187csh, even though other programs can be suspended this way, and even though the
1188Z and SUSPEND commands still work correctly.  This is evidently because IRIX's
1189csh does not deliver the SIGTSTP signal to Kermit.  The reason other programs
1190can be suspended in the same environment is probably that they do not trap
1191SIGTSTP themselves, so the shell is doing the suspending rather than the
1194Reportedly some Indys have bad serial port hardware.  IRIX 5.2, for example,
1195needs patch 151 to work around this; or upgrade to a later release.
1196Similarly, IRIX 5.2 has several problems with serial i/o, flow control, etc.
1197Again, patch or upgrade.
1199For hardware flow control on IRIX, use the ttyf* (modem control AND hardware
1200flow control) devices and not the ttyd* (direct) or ttym* (modem control but
1201no hardward flow control) ones, and obtain the proper "hardware handshaking"
1202cable from SGI, which is incompatible with the ones for the Macintosh and
1203NeXT even though they look the same.  "man serial" for further info.
1207The BeBox isn't a real product yet, and BeOS -- particularly the POSIX pieces
1208of it -- aren't finished.  As the POSIX bits are fleshed out, a lot of the
1209Be-specific code can Be removed.  The workarounds in this version are for
1210DR7, contributed by an anonymous donor, sufficient to:
1212  - set line /dev/serial2 (and probably the other serial ports)
1213  - set speed 115200 (and at least some of the lower baud rates)
1214  - connect
1215  - set modem type hayes (and likely others, too)
1216  - dial [phone number]
1217  - set send packet length 2048 (other lengths for both send and receive)
1218  - set receive packet length 2048
1219  - set file type binary (text mode works, too)
1220  (with remote kermit session in server mode)
1221  - put bedrop.jpg
1222  - get bedrop.jpg
1223  - get bedrop.jpg bedrop.jpg2
1224  - finish, bye
1226The following do not work:
1227  - kermit does not detect modem hangup
1228  - !/RUN/PUSH [commandline command]
1229  - running kermit in remote mode
1230  - using other protocols (x/y/zmodem)
1231  - TCP networking interface (Be's TCP/IP API has a ways to go, still)
1235In version 6.0, the default C-Kermit prompt includes your current (working)
1236directory; for example:
1238  [/usr/olga] C-Kermit>
1240If that directory is on an NFS-mounted disk, and NFS stops working or the
1241disk becomes unavailable, C-Kermit will hang waiting for NFS and/or the disk
1242to come back.  Whether you can interrupt C-Kermit when it is hung this way
1243depends on the specific OS.  Kermit has called the operating systems's
1244getcwd() function, and is waiting for it to return.  Some versions of UNIX
1245(e.g. HP-UX 9.x) allow this function to be interrupted with SIGINT (Ctrl-C),
1246others (such as HP-UX 8.x) do not.  To avoid this effect, you can always
1247use SET PROMPT change your prompt to something that does not involve calling
1248getcwd(), but if NFS is not responding, C-Kermit will still hang any time you
1249give a command that refers to the current directory.  Also note that in some
1250cases, the uninterruptibility of NFS-dependent system or library calls is
1251considered a bug, and sometimes there are patches.  For HP-UX, for example:
1253  HP-UX 10.20     libc    PHCO_8764
1254  HP-UX 10.10     libc    PHCO_8763
1255  HP-UX 9.x       libc    PHCO_7747       S700
1256  HP-UX 9.x       libc    PHCO_6779       S800
1258You might have reason to make C-Kermit the login shell for a specific user,
1259by entering the pathname of Kermit (possibly with command-line switches, such
1260as -x to put it in server mode) into the shell field of the /etc/passwd file.
1261This works pretty well.  In some cases, for "ultimate security", you might
1262want to use a version built with -DNOPUSH (see ckccfg.doc) for this, but even
1263if you don't, then PUSHing or shelling out from C-Kermit just brings up a
1264new copy of C-Kermit (but warning: this does not prevent the user from
1265explicitly running a shell; e.g. "run /bin/sh"; use NOPUSH to prevent this).
1267C-Kermit will not work as expected on a remote UNIX system, when used through
1268the "splitvt" or GNU "screen" programs.  In this case, terminal connections to
1269the remote UNIX system work, but attempts to transfer files fail because the
1270screen optimization (or at least, line wrapping, control-character absorption)
1271done by this package interferes with Kermit's packets.
1273You might try the following -- what we call "doomsday Kermit" settings to
1274push packets through even the densest and most obstructive connections, such
1275as "screen" and "splitvt" (and certain kinds of 3270 protocol emulators):
1276Give these commands to BOTH Kermit programs:
1281  SET RECEIVE START 62       
1282  SET SEND START 62         
1283  SET SEND PAUSE 100
1284  SET BLOCK B               
1286If it works, it will be slow.
1288On UNIX workstations equipped with DOS emulators like SoftPC, watch out for
1289what these emulators do to the serial port drivers.  After using a DOS
1290emulator, particularly if you use it to run DOS communications software, you
1291might have to reconfigure the serial ports for use by UNIX.
1293On AT&T 7300 (3B1) machines, you might have to "stty nl1" before starting
1294C-Kermit.  Do this if characters are lost during communications operations.
1296Under the bash shell (versions prior to 1.07 from CWRU), "pushing" to an
1297inferior shell and then exiting back to Kermit leaves Kermit in the background
1298such that it must be explicitly fg'd.  This is reportedly fixed in version
12991.07 of bash.
1301Interruption by Ctrl-Z makes UNIX C-Kermit try to suspend itself with
1302kill(0,SIGSTOP), but only on systems that support job control, as determined
1303by whether the symbol SIGTSTP is defined (or on POSIX or SVR4 systems, if
1304syconf(_SC_JOB_CONTROL) or _POSIX_JOB_CONTROL in addition to SIGTSTP).
1305However, if Kermit is running under a login shell (such as the original Bourne
1306shell) that does not support job control, the user's session hangs and must be
1307logged out from another terminal, or hung up on.  There is no way Kermit can
1308defend itself against this.  If you use a non-job control shell on a computer
1309that supports job control, give a command like "stty susp undef" to fix it so
1310the suspend signal is not attached to any particular key, or give the command
1311SET SUSPEND OFF to C-Kermit, or build C-Kermit with -DNOJC.
1313Reportedly, the UNIX C-Kermit server, under some conditions, on certain
1314particular systems, fails to log out its login session upon receipt of a
1315BYE command.  Before relying on the BYE command working, test it a few times
1316to make sure it works on your system: there might be system configuration or
1317security mechanisms to prevent an inferior process (like Kermit) from
1318killing a superior one (like the login shell).
1322C-Kermit's initialization file for UNIX is .kermrc (lowercase, starts with
1323period) in your home directory, unless Kermit was built with the system-wide
1324initialization-file option (see ckuins.doc).
1326C-Kermit identifies your home directory based on the environment variable,
1327HOME.  Most UNIX systems set this variable automatically when you log in.  If
1328C-Kermit can't find your initialization file, check your HOME variable:
1330  echo $HOME      (at the UNIX prompt)
1334  echo \$(HOME)   (at the C-Kermit prompt)
1336If HOME is not defined, or is defined incorrectly, add the appropriate
1337definition to your UNIX .profile or .login file, depending on your shell:
1339  setenv HOME full-pathname-of-your-home-directory  (C-Shell, .login file)
1341  HOME=full-pathname-of-your-home-directory         (sh, ksh, .profile file)
1342  export HOME
1344NOTE: Various other operations depend on the correct definition of HOME.
1345These include the "tilde-expansion" feature, which allows you to refer to
1346your home directory as "~" in filenames used in C-Kermit commands, e.g.
1348  send ~/.kermrc
1350as well as the \v(home) variable.
1352Prior to version 5A(190), C-Kermit would look for its initialization file in
1353the current directory if it was not found in the home directory.  This feature
1354was removed from 5A(190) because it was a security risk.  Some people, however,
1355liked this behavior and had .kermrc files in all their directories that would
1356set up things appropriately for the files therein.  If you want this behavior,
1357you can accomplish it in various ways, for example:
1359 . Create a shell alias, for example:
1360   alias kd="kermit -Y ./.kermrc"
1362 . Create a .kermrc file in your home directory, whose contents are:
1363   take ./.kermrc   
1365The TAKE command does not search your UNIX PATH for command files.  If a
1366command file is not in the current directory, you must give a full path
1367specification for it.  This poses a problem for TAKE commands that are
1368themselves in TAKE files.  See the trick used in CKETEST.INI...
1370Suppose you need to pass a password from the UNIX command line to a C-Kermit
1371script program, in such a way that it does not show up in "ps" or "w" listings.
1372Here is a method (not guaranteed to be 100% secure, but definitely more secure
1373than the more obvious methods):
1375  echo mypassword | kermit myscript
1377The "myscript" file contains all the commands that need to be executed during
1378the Kermit session, up to and including EXIT, and also includes an ASK or ASKQ
1379command to read the password from standard input, which has been piped in from
1380the UNIX 'echo' command, but it must not include a CONNECT command.  Only
1381"kermit myscript" shows up in the ps listing.
1385Version-7 based UNIX implementations, including 4.3 BSD and earlier and
1386UNIX systems based upon BSD, use a 4-bit field to record a serial device's
1387terminal speed.  This leaves room for 16 speeds, which are normally:
1389  0, 50, 75, 110, 134.5, 150, 200, 300, 600, 1200, 1800, 2400, 4800, and 9600
1391The remaining two are usually called EXTA and EXTB, and are defined by the
1392particular UNIX implementation.  C-Kermit determines which speeds are
1393available on your system based on whether symbols for them are defined in your
1394terminal device header files.  EXTA is generally assumed to be 19200 and EXTB
139538400, but these assumptions might be wrong, or they might not apply to a
1396particular device that does not support these speeds.  Presumably, if you try
1397to set a speed that is not legal on a particular device, the driver will
1398return an error, but this can not be guaranteed.
1400On these systems, it is usually not possible to select a speed of 14400 bps
1401for use with V.32bis modems.  In that case, use 19200 or 38400 bps, configure
1402your modem to lock its interface speed and to use RTS/CTS flow control, and
1405Some recent versions of UNIX, and/or terminal device drivers that come with
1406certain third-party add-in high-speed serial communication interfaces, use the
1407low "baud rates" to stand for higher ones.  For example, SET SPEED 50 gets you
140857600 bps; SET SPEED 75 gets you 76800; SET SPEED 110 gets 115200.
1410SCO ODT 3.0 is an example where a "baud-rate-table patch" can be applied that
1411can rotate the tty driver baud rate table such that 600=57600 and 1800=115k
1412baud.   Similarly for Digiboard multiport/portservers, which have a
1413"fastbaud" setting that does this.
1415The situation is similar, but different, in System V.  SVID Third Edition
1416lists the same speeds, 0 through 38400.
1418For further details, read the section TERMINAL SPEEDS in ckuins.doc.
1422The SET CARRIER command works as advertised only if the underlying operating
1423system and device drivers support this feature; in particular only if a read()
1424operation returns immediately with an error code if the carrier signal goes
1425away.  And, of course, if the devices themselves (e.g. modems)
1426are configured appropriately and the cables convey the carrier signal, etc.
1428When UNIX C-Kermit exits, it closes (and must close) the communications
1429device.  If you were dialed out, this will most likely hang up the connection.
1430If you want to get out of Kermit and still use Kermit's communication device,
1431you have several choices:
1433 1. Shell out from Kermit or suspend Kermit, and refer to the device literally
1434    (as in "term -blah -blah < /dev/cua > /dev/cua").
1436 2. Shell out from Kermit and use the device's file descriptor which Kermit
1437    makes available to you in the \v(ttyfd) variable.
1439 3. Use C-Kermit's REDIRECT command.  See the CKCKER.UPD file about this.
1441If you are having trouble dialing:
1443 1. Make sure the dialout line is configured correctly.  More
1444    about this below.
1446 2. Make sure all necessary patches are installed for your operating
1447    system.
1449 3. If you can't dial on a "bidirectional" line, then configure it for
1450    outbound-only (remove the getty) and try again.  (The mechanisms -- if
1451    any -- for grabbing bidirectional lines for dialout vary wildly
1452    among UNIX implementations and releases, and C-Kermit -- which runs on
1453    well over 300 different UNIX variations -- makes no effort to keep up
1454    with them; the recommended method for coping with this situation is to
1455    wrap C-Kermit in a shell script that takes the appropriate actions.)
1457 4. Make sure C-Kermit's SET DIAL and SET MODEM parameters agree with the
1458    modem you are actually using -- pay particular attention to SET DIAL
1461 5. Try SET DIAL HANGUP OFF before the DIAL command.  Also, SET DIAL DISPLAY
1462    ON to watch what's happening.  See section 8 of ckuins.doc.
1464 6. Read pages 50-67 of "Using C-Kermit".
1466 7. As a last resort, don't use the DIAL command at all; SET CARRIER OFF and
1467    CONNECT to the modem and dial interactively, or write a script program to
1468    dial the modem.
1470Make sure your dialout line is correctly configured for dialing out (as
1471opposed to login).  The method for doing this is different for each kind of
1472UNIX system.  Consult your system documentation for configuring lines for
1473dialing out (for example, SUN SparcStation IPC users should read the section
1474"Setting up Modem Software" in the Desktop SPARC Sun System & Network
1475Manager's Guide; HP-9000 workstation users should consult the manual
1476"Configuring HP-UX for Peripherals", etc).
1478Symptom: DIAL works, but a subsequent CONNECT command does not.  Diagnosis:
1479the modem is not asserting Carrier Detect (CD) after the connection is made,
1480or the cable does not convey the CD signal.  Cure: Reconfigure the modem,
1481replace the cable.  Workaround: SET CARRIER OFF (at least in System-V based
1482UNIX versions).
1484C-Kermit tries to use the 8th bit for data when parity is NONE, and this
1485generally works on real UNIX terminal (tty) devices, but it often does not
1486work when the UNIX system is accessed over a network via telnet or rlogin
1487protocols, including (in many cases) through terminal servers.  For example,
1488an Encore computer with Annex terminal servers only gives a 7-bit path if
1489the rlogin protocol is selected in the terminal server but it gives the full
14908 bits if the proprietary RDP protocol is used.
1492If file transfer does not work through a host to which you have rlogin'd,
1493use "rlogin -8" rather than "rlogin".  If that doesn't work, tell both Kermit
1494programs to "set parity space".
1496The Encore TELNET server does not allow long bursts of input.  When you have
1497a TELNET connection to an Encore, tell C-Kermit on the Encore to SET RECEIVE
1498PACKET-LENGTH 200 or thereabouts.
1500For Berkeley-UNIX-based systems (4.3BSD and earlier), Kermit includes code to
1501use LPASS8 mode when parity is none, which is supposed to allow 8-bit data and
1502Xon/Xoff flow control at the same time.  However, as of edit 174, this code is
1503entirely disabled because it is unreliable: even though the host operating
1504system might (or might not) support LPASS8 mode correctly, the host access
1505protocols (terminal servers, telnet, rlogin, etc) generally have no way of
1506finding out about it and therefore render it ineffective, causing file
1507transfer failures.  So as of edit 174, Kermit once again uses rawmode for
15088-bit data, and so there is no Xon/Xoff flow control during file transfer or
1509terminal emulation in the Berkeley-based versions (4.3 and earlier, not 4.4).
1511Also on Berkeley-based systems (4.3 and earlier), there is apparently no way
1512to configure a dialout line for proper carrier handling, i.e. ignore carrier
1513during dialing, require carrier thereafter, get a fatal error on any attempt
1514to read from the device after carrier drops (this is handled nicely in System
1515V by manipulation of the CLOCAL flag).  The symptom is that carrier loss does
1516not make C-Kermit pop back to the prompt automatically.  This is evident on
1517the NeXT, for example, but not on SunOS, which supports the CLOCAL flag.  This
1518is not a Kermit problem, but a limitation of the underlying operating system.
1519For example, the cu program on the NeXT doesn't notice carrier loss either,
1520whereas cu on the Sun does.
1522On certain AT&T UNIX systems equipped with AT&T modems, DIAL and HANGUP don't
1523work right.  Workarounds: (1) SET DIAL HANGUP OFF before attempting to dial;
1524(2) If HANGUP doesn't work, SET LINE, and then SET LINE <device> to totally
1525close and reopen the device.  If all else fails, SET CARRIER OFF.
1527C-Kermit does not contain any particular support for AT&T DataKit devices.
1528You can use Kermit software to dial in to a DataKit line, but C-Kermit does
1529not contain the specialized code required to dial out from a DataKit line.  If
1530the UNIX system is connected to DataKit via serial ports, dialout should work
1531normally (e.g. set line /dev/ttym1, set speed 19200, connect, and then see the
1532DESTINATION: prompt, from which you can connect to another computer on the
1533DataKit network or to an outgoing modem pool, etc).  But if the UNIX system
1534is connected to the DataKit network through the special DataKit interface
1535board, then SET LINE to a DataKit pseudodevice (such as /dev/dk031t) will not
1536work (you must use the DataKit "dk" or "dkcu" program instead).
1538In some BSD-based UNIX C-Kermit versions, SET LINE to a port that has nothing
1539plugged in to it with SET CARRIER ON will hang the program (as it should), but
1540it can't be interrupted with Ctrl-C.  The interrupt trap is correctly armed,
1541but apparently the UNIX open() call cannot be interrupted in this case.  When
1542SET CARRIER is OFF or AUTO, the SET LINE will eventually return, but then the
1543program hangs (uninterruptibly) when the EXIT or QUIT command (or, presumably,
1544another SET LINE command) is given.  The latter is probably because of the
1545attempt to hang up the modem.  (In edit 169, a timeout alarm was placed around
1546this operation.)
1548With SET DIAL HANGUP OFF in effect, the DIAL command might work only once,
1549but not again on the same device.  In that case, give a SET LINE command
1550with no arguments to close the device, and then another SET LINE command for
1551the desired device.  Or rebuild your version of Kermit with the -DCLSOPN
1552compile-time switch (see ckuins.doc).
1554The DIAL command says "To cancel: Type your interrupt character (normally
1555Ctrl-C)."  This is just one example of where program messages and
1556documentation assume your interrupt character is Ctrl-C.  But it might be
1557something else.  In most (but not necessarily all) cases, the character
1558referred to is the one that generates the SIGINT signal.  If Ctrl-C doesn't
1559act as an interrupt character for you, type the Unix command "stty -a" or
1560"stty all" or "stty everything" to see what your interrupt character is.
1561(Kermit could be made to find out what the interrupt character is, but this
1562would require a lot of system-dependent coding and #ifdefs, and a new routine
1563and interface between the system-dependent and system-independent parts of the
1566In general, the hangup operation on a serial communication device is prone
1567to failure.  C-Kermit tries to support many, many different kinds of
1568computers, and there seems to be no portable method for hanging up a modem
1569connection (i.e. turning off the RS-232 DTR signal and then turning it back on
1570again).  If HANGUP, DIAL, and/or Ctrl-\H do not work for you, and you are a
1571programmer, look at the tthang() function in ckutio.c and see if you can add
1572code to make it work correctly for your system, and send the code to the
1573address above.  (NOTE: This problem has been largely sidestepped as of edit
1574188, in which Kermit first attempts to hang up the modem by "escaping back"
1575via +++ and then giving the modem's hangup command, e.g. ATH0, when DIAL
1576MODEM-HANGUP is ON, which is the default setting.)
1578Even when Kermit's modem-control software is configured correctly for your
1579computer, it can only work right if your modem is also configured to assert
1580the CD signal when it is connected to the remote modem and to hang up the
1581connection when your computer drops the DTR signal.  So before deciding Kermit
1582doesn't work with your modem, check your modem configuration AND the cable (if
1583any) connecting your modem to the computer -- it should be a straight-through
1584modem cable conducting the signals FG, SG, TD, RD, RTS, CTS, DSR, DTR, CD,
1585and RI.
1587Many UNIX systems keep aliases for dialout devices; for example, /dev/acu
1588might be an alias for /dev/tty00.  But most of these UNIX systems also use
1589UUCP lockfile conventions that do not take this aliasing into account, so if
1590one user assigns (e.g.) /dev/acu, then another user can still assign the same
1591device by referring to its other name.  This is not a Kermit problem --
1592Kermit must follow the lockfile conventions used by the vendor-supplied
1593software (cu, tip, uucp).
1595The SET FLOW-CONTROL KEEP option should be given *before* any communication
1596(dialing, terminal emulation, file transfer, INPUT/OUTPUT/TRANSMIT, etc) is
1597attempted, if you want C-Kermit to use all of the device's preexisting
1598flow-control related settings.  The default flow-control setting is XON/XOFF,
1599and it will take effect when the first communication-related command is given,
1600and a subsequent SET FLOW KEEP command will not necessarily know how to
1601restore *all* of the device's original flow-control settings.
1605SET FLOW RTS/CTS is available in UNIX C-Kermit only when the underlying
1606operating system provides an Application Program Interface (API) for turning
1607this feature on and off under program control, which turns out to be a rather
1608rare feature among UNIX systems.  To see if your UNIX C-Kermit version
1609supports hardware flow control, type "set flow ?" at the C-Kermit prompt, and
1610look for "rts/cts" among the options.  Other common situations include:
1612 1. The API is available, so "set flow rts/cts" appears as a valid C-Kermit
1613    command, but it doesn't do anything because the device driver (part of
1614    the operating system) was never coded to do hardware flow control.  This
1615    is common among System V R4 implementations (details below).
1617 2. The API is not available, so "set flow rts/cts" does NOT appear as a valid
1618    C-Kermit command, but you can still get RTS/CTS flow control by selecting
1619    a specially named device in your SET LINE command.  Examples:
1621      NeXTSTEP: /dev/cufa instead of /dev/cua, /dev/cufb instead of /dev/cub
1622      (68040 only; "man zs" for further info).
1624      IRIX: /dev/ttyf2 instead of /dev/ttyd2 or /dev/ttym2 ("man 7 serial").
1626 3. The API is available, doesn't work, but a workaround as in (2) can be used.
1628 4. The API is available, but Kermit doesn't know about it.  In these cases,
1629    you can usually use an stty command to enable RTS/CTS on the device, e.g.
1630    "stty crtscts" or "stty ctsflow", "stty rtsflow", before starting Kermit,
1631    and then tell Kermit to SET FLOW KEEP.
1633 5. No API and no special device drivers.  Hardware flow control is completely
1634    unavailable.
1636System V R4 based UNIXes are supposed to supply a <termiox.h> file, which
1637gives Kermit the necessary interface to command the terminal driver to
1638enable/disable hardware flow control.  Unfortunately, but predictably, many
1639implementations of SVR4 whimsically place this file in /usr/include/sys rather
1640than /usr/include (where SVID clearly specifies it should be; see SVID, Third
1641Edition, V1, termiox(BA_DEV).  Thus if you build C-Kermit with any of the
1642makefile entries that contain -DTERMIOX or -DSTERMIOX (the latter to select
1643<sys/termiox.h>), C-Kermit will have "set flow rts/cts" and possibly other
1644hardware flow-control related commands.  BUT...  That does not necessarily
1645mean that they will work.  In some cases, the underlying functions are simply
1646not coded into the operating system.
1650UNIX C-Kermit's SET KEY command currently can not be used with keys that
1651generate "wide" scan codes or multibyte sequences, such as workstation
1652function or arrow keys, because UNIX C-Kermit does not have direct access to
1653the keyboard.  More about this in CKCKER.BWR.
1655However, many UNIX workstations and/or console drivers provide their own key
1656mapping feature.  With xterm, for example, you can use 'xmodmap' ("man
1657xmodmap" for details); here is an xterm mapping to map the Sun keyboard to DEC
1658VT200 values for use with VT-terminal oriented applications like VMS EVE:
1660  keycode 101=KP_0
1661  keycode 119=KP_1
1662  keycode 120=KP_2
1663  keycode 121=KP_3
1664  keycode 98=KP_4
1665  keycode 99=KP_5
1666  keycode 100=KP_6
1667  keycode 75=KP_7
1668  keycode 76=KP_8
1669  keycode 77=KP_9
1670  keycode 52=KP_F1
1671  keycode 53=KP_F2
1672  keycode 54=KP_F3
1673  keycode 57=KP_Decimal
1674  keycode 28=Left
1675  keycode 29=Right
1676  keycode 30=KP_Separator
1677  keycode 105=KP_F4
1678  keycode 78=KP_Subtract
1679  keycode 8=Left
1680  keycode 10=Right
1681  keycode 32=Up
1682  keycode 33=Down
1683  keycode 97=KP_Enter
1685Users of Linux consoles can use loadkeys ("man dumpkeys loadkeys keytables"
1686for details.  The format used by loadkeys is compatible with that used by
1687Xmodmap, although it is not definitely certain that the keycodes are
1688compatible for different keyboard types (e.g. Sun vs HP vs PC, etc).
1690UNIX GNU EMACS includes a "kermit" library that allows Kermit connections to
1691be made to other computers from within an EMACS window.  As of June 1994,
1692there is also a Kermit file transfer library for GNU EMACS.
1696UNIX C-Kermit does not reject incoming files on the basis of size.  There
1697appears to be no good (reliable, portable) way to determine in advance how
1698much disk space is available, either on the device, or (when quotas are
1699involved) to the user.
1701File transfer will fail if the incoming file is bigger than your ULIMIT.
1702Use the UNIX ulimit command to examine or change your ULIMIT (the number is
1703in 512-byte blocks, i.e. 0.5K).
1705UNIX C-Kermit discards all carriage returns from incoming files when in text
1708If C-Kermit is receiving a file on a dialup connection and the connection
1709hangs up, the SIGHUP signal is delivered to the top-level shell, which kills
1710all processes (including Kermit and any of its subforks) and closes all open
1711files, including the file that was being received.  Even if you have told
1712Kermit to SET FILE INCOMPLETE DISCARD, the partially received file is kept.
1713See comments in ckutio.c (search for SIGHUP) for details.
1715If you SET FILE DISPLAY FULLSCREEN, and C-Kermit complains "Sorry, terminal
1716type not supported", it means that the terminal library (termcap or termlib)
1717that C-Kermit was built with does not know about a terminal whose name is the
1718current value of your TERM environment variable.  If this happens, EXIT from
1719C-Kermit and set a UNIX terminal type from among the supported values that is
1720also supported by your terminal emulator, or else have an entry for your
1721terminal type added to the system termcap and/or terminfo database.
1723If you attempt to suspend C-Kermit during local-mode file transfer and then
1724continue it in the background (via bg), it will block for "tty output" if
1725you are using the FULLSCREEN file transfer display.  This is apparently
1726a problem with curses.  Moving a local-mode file transfer back and forth
1727between foreground and background works correctly, however, with the SERIAL,
1728CRT, or NONE file transfer displays.
1730If C-Kermit's command parser no longer echoes, or otherwise acts strangely,
1731after returning from a file transfer with the fullscreen (curses) display,
1732and your version of UNIX is based on AT&T System V, then try rebuilding your
1733version of C-Kermit with -DCK_NEWTERM.  Similarly if it echoes doubly, which
1734might even happen during a subsequent CONNECT session.  If rebuilding with
1735-DCK_NEWTERM doesn't fix it, then there is something very strange about your
1736systems curses library, and you should probably not use it.  Tell C-Kermit
1737to SET FILE DISPLAY CRT or anything else other than FULLSCREEN, or rebuild
1738without -DCK_CURSES, and without linking with (termlib and) curses.
1740It has been observed on a couple platforms -- e.g. BSDI and QNX -- that the
1741curses display works properly only once.  The second and subsequent times,
1742the display is a mess.  The reason is unknown, the cure is unknown.  See the
1743comments in screenc() in ckuusx.c.  In one other case (one of the Linux
1744distributions), a cure was obtained by linking to a different curses library
1745(ncurses rather than curses).
1747Reportedly, when using "MSEND *" from a 14-character filename UNIX system to
1748another system (e.g. BSD) that allows longer names, with SET FILE NAMES
1749LITERAL, any files with 14-character names will have a space added to the end
1750of the name on the receiving machine (this *should* be fixed in 6.0).
1752Optimum file transfer performance is a matter of tuning parameters like packet
1753length, window size, control-character unprefixing, and on serial connections,
1754ensuring there is an effective flow control method, preferably hardware (such
1755as RTS/CTS).
1757However, a fully-configured C-Kermit program can be slower than a minimally
1758configured one simply because of its size.  A command-line-only version that
1759is stripped of every conceivable feature not affecting file transfer (such as
1760"sunos41m" for the Sun or "dellsys5r4m" for Dell) can move files faster than a
1761full-featured one.  Thus, it might make sense to keep a minimal version
1762available as well as a full-featured one.  See the files ckuins.doc and
1763ckccfg.doc as well as the makefile for how to do this.
1765A fairly substantial reduction in size and a noticeable improvement in speed
1766can be obtained simply by rebuilding C-Kermit without the debugging feature:
1768  make <entryname> KFLAGS=-DNODEBUG
1770See ckccfg.doc for more detailed information about configuration.
1774UNIX C-Kermit can be used in conjunction with other communications software
1775in various ways.  C-Kermit can be invoked from another communications program
1776as an "external protocol", and C-Kermit can also invoke other communication
1777software to perform external protocols.
1779This sort of operation makes sense only when you are dialing out from your
1780UNIX system.  If the UNIX system is the one you have dialed in to, you don't
1781need any of these tricks.  Just run the desired software on your UNIX system
1782instead of Kermit.  When dialing out from a UNIX system, the difficulty is
1783getting two programs to share the same communication device in spite of the
1784UNIX UUCP lockfile mechanism, which would normally prevent any sharing, and
1785preventing the external protocol from closing (and therefore hanging up) the
1786device when it exits back to the program that invoked it.
1787(This section deleted; see ckcker.upd.)
1789"pcomm" is a general-purpose terminal program that provides file transfer
1790capabilities itself (X- and YMODEM variations) and the ability to call on
1791external programs to do file transfers (ZMODEM and Kermit, for example).  You
1792can tell pcomm the command to send or receive a file with an external
1794                        send                            receive
1795        ZMODEM          sz <filename>                   rz
1796        Kermit          kermit -s <filename>            kermit -r
1798pcomm runs external programs for file transfer by making stdin and stdout
1799point to the modem port, and then exec-ing "/bin/sh -c xxx" (where xxx is the
1800appropriate command).  However, C-Kermit does not treat stdin and stdout as
1801the communication device unless you instruct it:
1803                        send                            receive
1804        Kermit          kermit -l 0 -s <filename>       kermit -l 0 -r
1806The "-l 0" option means to use file descriptor 0 for the communication device.
1808In general, any program can pass any open file descriptor to C-Kermit for the
1809communication device in the "-l" command-line option.  When Kermit is given
1810a number as the argument to the "-l" option, it simply uses it as a file
1811descriptor, and it does not attempt to close it upon exit.
1813Here's another example, for Seyon (a Linux communication program).  First try
1814the technique above.  If that works, fine; otherwise...  If Seyon does not
1815give you a way to access and pass along the file descriptor, but it starts up
1816the Kermit program with its standard i/o redirected to its (Seyon's)
1817communications file descriptor, you can also experiment with the following
1818method, which worked here in brief tests on SunOS.  Instead of having Seyon
1819use "kermit -r" or "kermit -s filename" as its Kermit protocol commands, use
1820something like this (examples assume C-Kermit 6.0):
1822  For serial connections:
1824    kermit -YqQl 0 -r                     <-- to receive
1825    kermit -YqQl 0 -s filename(s)         <-- to send one or more files
1827  For Telnet connections:
1829    kermit -YqQF 0 -r                     <-- to receive
1830    kermit -YqQF 0 -s filename(s)         <-- to send one or more files
1832Command line options:
1834  Y    - skip executing the init file
1835  Q    - use fast file transfer settings
1836  l 0  - transfer files using file descriptor 0 for a serial connection
1837  F 0  - transfer files using file descriptor 0 for a Telnet connection
1838  q    - quiet - no messages
1839  r    - receive
1840  s    - send
1844   (This section is obsolete, but not totally useless. 
1845    See section 8 of CKCKER.UPD.)
1847After you have opened a communication link with C-Kermit's SET LINE (SET PORT)
1848or SET HOST (TELNET) command, C-Kermit makes its file descriptor available to
1849you in the \v(ttyfd) variable so you can make it available to other programs
1850that you RUN from C-Kermit.  Here, for example, C-Kermit runs itself as an
1851external protocol:
1853  C-Kermit>set modem type hayes
1854  C-Kermit>set line /dev/acu
1855  C-Kermit>set speed 2400
1856  C-Kermit>dial 7654321
1857   Call complete.
1858  C-Kermit>echo \v(ttyfd)
1859   3
1860  C-Kermit>run kermit -l \v(ttyfd)
1862Other programs that accept open file descriptors on the command line can be
1863started in the same way.
1865You can also use your shell's i/o redirection facilities to assign C-Kermit's
1866open file descriptor (ttyfd) to stdin or stdout.  For example, old versions of
1867the UNIX ZMODEM programs, sz and rz, when invoked as external protocols,
1868expect to find the communication device assigned to stdin and stdout with no
1869option for specifying any other file descriptor on the sz or rz command line.
1870However, you can still invoke sz and rz as exterior protocols from C-Kermit if
1871your current shell ($SHELL variable) is ksh (the Korn shell) or bash (the
1872Bourne-Again shell), which allows assignment of arbitrary file descriptors to
1873stdin and stdout:
1875  C-Kermit> run rz <&\v(ttyfd) >&\v(ttyfd)
1879  C-Kermit> run sz <&\v(ttyfd) >&\v(ttyfd)
1881In version 5A(190) and later, you can use C-Kermit's REDIRECT command, if it
1882is available in your version of C-Kermit, to accomplish the same thing without
1883going through the shell:
1885  C-Kermit> redirect rz
1889  C-Kermit> redirect sz
1891A complete set of rz,sz,rb,sb,rx,sx macros for UNIX C-Kermit is defined in
1892the file ckurzsz.ini.  It automatically chooses the best redirection method.
1896The "term" program provides an error-corrected, multiplexed connection
1897between two UNIX systems, allowing you to run multiple applications over a
1898single connection, for example several terminal windows and a file transfer
1899simultaneously.  Term depends on a communications application (such as
1900C-Kermit) to make the connection and then redirect it to term's standard i/o.
1901The advantages of using C-Kermit rather than other communication programs for
1902this include:
1904 . C-Kermit's script language lets you automate the entire process.
1906 . With C-Kermit's REDIRECT command, term sessions are not limited to serial
1907   connections, but can work over network connections (TCP/IP, X.25) too.
1909Here is an example showing how to set up a term session between two UNIX
1910systems with with C-Kermit (assuming the connection has already been made
1911by C-Kermit, e.g. by dialing up):
1913  C-Kermit> connect
1914  login: xxx
1915  Password: xxx
1916  $ exec term -r -s 38400 -A
1917  ^\c (escape back)
1918  C-Kermit>redirect term -s 38400 -A &
1919  C-Kermit>push
1920  $
1922Now you can run term clients such as trsh and tupload at the local shell
1927If C-Kermit has problems creating files in writable directories when it is
1928installed setuid or setgid on BSD-based versions of UNIX such
1929as NeXTSTEP 3.0, it probably needs to be rebuilt with the -DSW_ACC_ID
1930comilation switch (see ckuins.doc).
1932Reportedly, when coming into a Sequent UNIX (DYNIX) system through an X.25
1933connection, Kermit doesn't work right because the Sequent's FIONREAD ioctl
1934returns incorrect data.  To work around, use the 1-character-at-a-time version
1935of myread() in ckutio.c (i.e. undefine MYREAD in ckutio.c and rebuild the
1942Date: Thu, 12 Mar 92 1:59:25 MEZ
1943From: Walter Mecky <>
1944Subject: Help.Unix.sw
1947PRODUCT:        Unix
1948RELEASE:        Dell SVR4 V2.1 (is USL V3.0)
1949MACHINE:        AT-386
1950PATHNAME:       /usr/lib/
1951                /usr/ccs/lib/libc.a
1952ABSTRACT:       Function ttyname() does not close its file descriptor
1954        ttyname(3C) opens /dev but never closes it. So if it is called
1955        often enough the open(2) in ttyname() fails. Because the broken
1956        ttyname() is in the shared lib too all programs using it can
1957        fail if they call it often enough. One important program is
1958        uucico which calls ttyname for every file it transfers.
1960Here is a little test program if your system has the bug:
1962#include <stdlib.h>
1963#include <stdio.h>
1964main() {
1965    int i = 0;
1966    while (ttyname(0) != NULL)
1967      i++;
1968    perror("ttyname");
1969    printf("i=%d\n", i);
1972If this program runs longer than some seconds you don't have the bug.
1975        None
1977        Very easy if you have source code.
1979Another user reports some more explicit symptoms and recoveries:
1981> What happens is when invoking ckermit we get one of the following
1982> error messages:
1983>   You must set line
1984>   Not a tty
1985>   No more processes.
1986> One of the following three actions clears the peoblem:
1987>   shutdown -y -g0 -i6
1988>   kill -9 the ttymon with the highest PID
1989>   Invoke sysadm and disable then enable the line you want to use.
1990> Turning off respawn of sac -t 300 and going to getty's and uugetty's
1991> does not help.
1993> Also C-Kermit reports "?timed out closing /dev/ttyxx".
1994> If this happens all is well.
1998(Note: the following problem also occurs on SGI and probably many other
1999UNIX systems):
2001From: James Spath <>
2003Date: Wed, 9 Sep 1992 20:20:28 -0400
2004Subject: C-Kermit vs uugetty (or init) on Sperry 5000
2006We have sucessfully compiled the above release on a Unisys/Sperry 5000/95.  We
2007used the sys5r3 option, rather than sys5r2 since we have VR3 running on our
2008system.  In order to allow dialout access to non-superusers, we had to do
2009"chmod 666 /dev/tty###", where it had been -rw--w--w- (owned by uucp), and to
2010do "chmod +w /usr/spool/locks".  We have done text and binary file transfers
2011through local and remote connections.
2013The problem concerning uucp ownership and permissions is worse than I thought
2014at first.  Apparently init or uugetty changes the file permissions after each
2015session.  So I wrote the following C program to open a set of requested tty
2016lines.  I run this for any required outgoing line prior to a Kermit session.
2018   ------ cut here -------
2019/* opentty.c -- force allow read on tty lines for modem i/o */
2020/* idea from: restrict.c -- Systsem 5 Admin book Thomas/Farrow p. 605 */
2021/* /jes jim spath { } */
2022/* 08-Sep-92 NO COPYRIGHT. */
2023/* this must be suid to open other tty lines */
2025/* #define DEBUG */
2026#define TTY "/dev/tty"
2027#define LOK "/usr/spool/locks/LCK..tty"
2028#include <stdio.h>
2030/* allowable lines: */
2031#define TOTAL_LINES 3
2032static char allowable[TOTAL_LINES][4] = { "200", "201", "300" };
2033static int total=TOTAL_LINES;
2034int allow;
2036/* states: */
2037#define TTY_UNDEF 0
2038#define TTY_LOCK  1
2039#define TTY_OKAY  2
2041main(argc, argv)
2042int argc; char *argv[]; {
2043    char device[512];
2044    char lockdev[512];
2045    int i;
2046    if (argc == 1) {
2047        fprintf(stderr, "usage: open 200 [...]\n");
2048    }
2049    while (--argc > 0 && (*++argv) != NULL ) {
2050#ifdef DEBUG
2051        fprintf(stderr, "TRYING: %s%s\n", TTY, *argv);
2053        sprintf(device, "%s%s", TTY, *argv);
2054        sprintf(lockdev, "%s%s", LOK, *argv);
2055        allow = TTY_UNDEF; i = 0;
2056        while (i <= total) { /* look at all defined lines */
2057#ifdef DEBUG
2058            fprintf(stderr, "LOCKFILE? %s?\n", lockdev);
2060            if (access(lockdev, 00) == 0) {
2061                allow=TTY_LOCK;
2062                break;
2063            }
2064#ifdef DEBUG
2065            fprintf(stderr, "DOES:%s==%s?\n", allowable[i], *argv);
2067            if (strcmp(allowable[i], *argv) == 0)
2068              allow=TTY_OKAY;
2069            i++;
2070        }
2071#ifdef DEBUG
2072        fprintf(stderr, "allow=%d\n", allow);
2074        switch (allow) {
2075          case TTY_UNDEF:
2076            fprintf (stderr, "open: not allowed on %s\n", *argv);
2077            break;
2078          case TTY_LOCK:
2079            fprintf (stderr, "open: device locked: %s\n", lockdev);
2080            break;
2081          case TTY_OKAY:
2082            /* attempt to change mode on device */
2083            if (chmod (device, 00666) < 0)
2084              fprintf (stderr, "open: cannot chmod on %s\n", device);
2085            break;
2086          default:
2087            fprintf (stderr, "open: FAULT\n");
2088        }
2089    }
2090    exit (0);
2095(End of CKUKER.BWR)
Note: See TracBrowser for help on using the repository browser.