CKUKER.BWR "Beware File" for C-Kermit Version 6.0 -*- text -*- UNIX VERSION As of C-Kermit version: 6.0.192 This file last updated: Fri Sep 6 23:23:23 1996 Authors: Frank da Cruz and Christine M. Gianone, Columbia University. Copyright (C) 1985, 1996, Trustees of Columbia University in the City of New York. The C-Kermit software may not be, in whole or in part, licensed or sold for profit as a software product itself, nor may it be included in or distributed with commercial products or otherwise distributed by commercial concerns to their clients or customers without written permission of the Office of Kermit Development and Distribution, Columbia University. This copyright notice must not be removed, altered, or obscured. WHAT IS IN THIS FILE This is the "beware file" for the UNIX version of C-Kermit. It contains hints and tips, frequently asked questions (and answers), troubleshooting advice, limitations and restrictions, known bugs, etc, that apply to all UNIX variations, as well as to specific ones like HP-UX, AIX, SunOS, Solaris, Unixware, NeXTSTEP, etc etc. It should be read in conjunction with the system-independent C-Kermit "beware file", ckcker.bwr, which contains similar information that applies to all versions of C-Kermit (VMS, OS/2, AOS/VS, VOS, etc, as well as to UNIX). CONTENTS: (0) DOCUMENTATION (1) IMPORTANT FILES (2) BINARIES (3) NOTES ON SPECIFIC UNIX VERSIONS (3.1) C-KERMIT AND AIX (3.2) C-KERMIT AND HP-UX (3.3) C-KERMIT AND LINUX (3.4) C-KERMIT AND NEXTSTEP (3.5) C-KERMIT AND QNX (3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER (3.7) C-KERMIT AND SOLARIS (3.8) C-KERMIT AND SUNOS (3.9) C-KERMIT AND ULTRIX (3.10) C-KERMIT AND UNIXWARE (3.11) C-KERMIT AND APOLLO SR10 (3.12) C-KERMIT AND TANDY XENIX 3.0 (3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX) (3.14) C-KERMIT AND SGI IRIX (3.15) C-KERMIT AND THE BEBOX (4) GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS (5) INITIALIZATION AND COMMAND FILES (6) COMMUNICATION SPEED SELECTION (7) COMMUNICATIONS AND DIALING (8) HARDWARE FLOW CONTROL (9) TERMINAL CONNECTION AND KEY MAPPING (10) FILE TRANSFER (11) EXTERNAL FILE TRANSFER PROTOCOLS (11.1) C-KERMIT AS AN EXTERNAL PROTOCOL (11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT (11.3) USING C-KERMIT WITH TERM (12) MISCELLANEOUS (0) DOCUMENTATION C-Kermit is documented in the book "Using C-Kermit" by Frank da Cruz and Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1. Price: US $39.95. To order, call Columbia University, New York City, at +1 212 854-3703, or Digital Press / Butterworth-Heinemann at: +1 800 366-2665 (Massachusetts office for USA & Canada) +441 1993 414414 (Rushden, England office for Europe) +61 2 372-5511 (Chatswood, NSW, office for Australia & New Zealand) +65 220-3684 (Singapore office for Asia) A German edition is available from Verlag Heinz Heise in Hannover, Germany, Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 52-1 29. New features added since these books were published are documented in the ckcker.upd file. TECHNICAL SUPPORT Please consult the documentation listed above, plus the ckcker.bwr file and this file itself, before submitting questions, reporting problems, etc, to: E-Mail: kermit-support@columbia.edu News: comp.protocols.kermit.misc Post: The Kermit Project Columbia University 612 West 115th Street New York NY 10025-7799 USA Fax: +1 212 663-8202 or: +1 212 662-6442 Telephone support also available: USA Only: +1 900 555-5595, cost: $2.50 per minute Anywhere: +1 212 854-5126, cost: $25.00 per call, payable via Visa or MC. (1) IMPORTANT FILES In addition to the published documentation, the following files are useful in troubleshooting: ckaaaa.hlp: Overview, file naming conventions, list of files, etc. ckuins.doc: Installation instructions for UNIX C-Kermit. ckccfg.doc: C-Kermit program configuration information. ckcker.bwr: C-Kermit "beware file" for all C-Kermit implementations. ckuker.bwr: C-Kermit "beware file" specific to UNIX (this file). ckcplm.doc: C-Kermit program logic manual. ckcker.upd: User documentation for features added since 5A(188). ckcXXX.upd: Program edit history for edit XXX, e.g. ckc190.upd. (2) BINARIES It is often dangerous to run a binary C-Kermit (or any other) program built on a different computer. Particularly if that computer had a different C compiler, libraries, operating system version, processor features, etc, and especially if the program was built with shared libraries. It is often OK to run a binary built on an earlier OS version, but it is rarely possible (or safe) to run a binary built on a later one, for example to run a binary built under SunOS 4.1.2 on a SunOS 4.1.1 system. When in doubt, build C-Kermit from the source code on the system where it is to be run (if possible!). If not, ask us for a binary specific to your configuration. We might have one, and if we don't, we might be able to get one. (3) NOTES ON SPECIFIC UNIX VERSIONS The following sections apply to specific UNIX versions. (3.1) C-KERMIT AND AIX Many problems reported with bidirectional terminal lines on AIX 3.2.x on the RS/6000. Workaround: don't use bidirectional terminal lines, or write some kind of shell script that turns getty off on the line before starting Kermit, or before Kermit attempts to do the SET LINE. (But note: These problems MIGHT be fixed in C-Kermit 6.0.192.) Reportedly, all versions of IBM AIX use the same (undocumented) lockfile conventions as RTAIX. If this is true, the "makes" for PS/2 AIX and AIX/370 will have to be changed to use the RTAIX convention (it may be sufficient to simply add -DRTAIX to the make entry). C-Kermit SET HOST or TELNET from AIX on an RS/6000 to another RS/6000 won't work right unless you set your local terminal type to something other than AIXTERM. When your terminal type is AIXTERM, AIX TELNET sends two escapes whenever you type one, and the AIX telnet server swallows one of them. This has something to do with the "hft" device. This behavior is reportedly removed in AIX 3.2. Transfer of binary -- and maybe even text -- files can fail on AIX 3.x. The problem was traced to a facility in AIX whereby a particular port can have character-set translation done for it by the tty driver. The following advice from a knowledgeable AIX user: (begin quote...) [This feature] has to be checked (and set/cleared) with a separate command, unfortunately stty doesn't handle this. To check: $ setmaps input map: none installed output map: none installed If it says anthing other than "none installed" for either one, it is likely to cause a problem with kermit. To get rid of installed maps: $ setmaps -t NOMAP However, I seem to recall that with some versions of AIX before 3.2.5, only root could change the setting. I'm not sure what versions - it might have only been under AIX 3.1 that this was true. At least with AIX 3.2.5 an ordinary user can set or clear the maps. (...end quote) And this would imply that Kermit itself cannot be coded to take care of this, because it would have to run as root. On the same problem, another knowledgeable AIX user says: The way to get information on the NLS mapping under AIX (3.2.5 anyway) is as follows. From the command line type: lsattr -l tty# -a imap -a omap -E -H Replace the tty number for the number sign above. This will give a human readable output of the settings that looks like this; # lsattr -l tty2 -a imap -a omap -E -H attribute value description user_settable imap none INPUT map file True omap none OUTPUT map file True If you change the -H to a -O, you get output that can easily be processed by another program or a shell script, for example: # lsattr -l tty2 -a imap -a omap -E -O #imap:omap none:none To change the settings from the command line, the chdev command is used with the following syntax. chdev -l tty# -a imap='none' -a omap='none' Again substituting the appropriate tty port number for the number sign, "none" being the value we want for C-Kermit. Of course, the above can also be changed by using the SMIT utility and selecting devices - tty. (...end quote) (3.2) C-KERMIT AND HP-UX During the C-Kermit 6.0 Beta cycle, something happened to ckcpro.w (or, more precisely, the ckcpro.c file that is generated from it) which causes HP optimizing compilers under HP-UX versions 7.0 and 8.0 (apparently on all platforms) as well as under HP-UX 9.0 on Motorola platforms only, to blow up. The symptoms vary from the system grinding to a halt, to the compiler crashing, to the compilation of the ckcpro.c module taking very long periods of time, like 9 hours. On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment size), seems to be important. On Motorola systems, it is 16MB by default, whereas on RISC systems the default is much bigger. Increasing maxdsiz to about 80MB seems to make the problem go away, but only if the system also has a lot of physical memory -- otherwise it swaps itself to death. Therefore, the C-Kermit 6.0 makefile entries for HP-UX 7.x and 8.x that do optimization, compile ckcpro.c first without optimization. For HP-UX 9.0, a special entry, hpux90mot, was added for Motorola makes; the regular entries optimize all modules. Even so, the optimizing compiler will often complain about "some optimizations skipped" on certain modules, due to lack of space available to the optimizer. You can always increase the space (the incantation depends on the particular compiler version -- see the makefile), but doing so tends to make the compilations take a much longer time. For example, the "hpux100o+" makefile entry adds the "+Onolimit" compiler flag, and about an hour to the compile time on an HP-9000/730. But it *does* produce an executable that is about 10K smaller :-) (3.2.0) Performance An unexpected slowness has been noted when transferring files over local Ethernet connections when an HP-UX system (9.0 or later, perhaps also earlier versions) is on the remote end. The following experiment was conducted to determine the cause. The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20), both on the same local 10Mbps Ethernet. Window size 20, packet length 4096, parity none, control prefixing "cautious", using only local disks on each machine -- no NFS. The file was a 1.08MB binary file (wermit), transferred in binary mode. Conditions were relatively poor: the Sun and the local net heavily loaded; the HP system is slow and memory-constrained. Client Server Send Receive Sun HP 36 18 <-- K cps HP HP 25 15 HP Sun 77 83 Sun Sun 60 60 So whenever HP is the server we have bad performance. Why? . Changing file display to CRT has no effect (so it's not the curses library on the client side). . Changing TCP RECV-BUFFER or SEND-BUFFER has very little effect. . Telling the client to make a binary-mode connection (SET TELNET BINARY REQUESTED, which successfully negotiates a binary connection) has no effect. BUT... If I start C-Kermit as a TCP server: set host * 3000 server and then from the client "set host blah 3000", I get: Client Server Send Receive HP HP 50 50 Sun HP 77 67 HP Sun 57 85 Sun Sun 57 50 Therefore the HP-UX telnet server or pty driver seems to be adding more overhead than the SunOS one, and most others. When going through this type of connection (a remote telnet server) there is nothing Kermit can do improve matters, since the telnet server and pty driver are between the two Kermits, and neither Kermit can have any influence over them (except putting the Telnet connection in binary mode, but that doesn't help). (3.2.1) HP-UX 5.21 Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on the HP-9000 series 500 computers. It only occurs when the controlling terminal is using an HP-27140 six-port modem mux. The problem is not present if the controlling terminal is logged into an HP-27130 eight-port mux. The symptom is that just after dialing successfully and connecting Kermit locks up and the port is unusable until both forks of Kermit and the login shell are killed." (3.2.2) HP-UX 8.05 To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install HP-UX patch PHNE_0899. This patch deals with a lot of driver issues, particularly related to communication at higher speeds. (3.2.3) HP-UX 9.00 AND LATER HP-UX 9.00 and 9.01 need patch PHNE_3641 for hptt0.o, asio0.o, and ttycomn.o in libhp-ux.a. Contact Hewlett Packard if you need this patch. Without it, the dialout device (tty) will be hung after first use; subsequent attempts to use will return an error like "device busy". C-Kermit works fine -- including its curses-based file-transfer display -- on the console terminal, in a remote session (e.g. when logged in to the HP 9000 on a terminal port or when telnetted or rlogin'd), and in an HP-VUE hpterm window or an xterm window. Before you can use serial ports on the HP-9000, you must configure them as either "terminals" or "modems" with SAM ("peripheral devices"..."terminals and modems"), as described in the HP manual, "Configuring HP-UX for Peripherals: HP 9000". If you attempt to use a serial device before it has been configured this way, it will not work properly; typical symptoms are (a) no communication at all; (b) nonfunctional modem signals; and/or (c) massive amounts of character loss in both directions. In HP-UX 9.0, serial device names were different between HP9000 Series 700 and Series 800 systems. In 10.0, device file names (and also major and minor numbers) have "converged", as shown in the following table: Converged HP-UX Serial I/O Filenames : TTY Mux Naming --------------------------------------------------------------------- General meaning S800 9.0 S700 9.0 Convio 10.0 --------------------------------------------------------------------- tty* hardwired ports ttyp tty ttyp

diag:mux diag:mux --------------------------------------------------------------------- ttyd* dial-in modems ttydp ttyd ttydp

diag:ttydp diag:ttydp

--------------------------------------------------------------------- cua* auto-dial out cuap cua cuap

diag:cuap --------------------------------------------------------------------- cul* dial-out culp cul culp

diag:culp --------------------------------------------------------------------- = LU (Logical Unit) = Devspec (decimal card instance) or = Port

= Port For dialing out, you should use the cua or cul devices. When C-Kermit's CARRIER setting is AUTO or ON, C-Kermit will pop back to its prompt automatically if the carrier signal drops, e.g. when you log out from the remote computer or service. If you use the ttyp (e.g. tty0p0) device, the carrier signal is ignored. The ttyp device should be used for direct connections where the carrier signal does not follow RS-232 conventions (use the cul device for hardwired connections through a true null modem). Do not use the ttydp device for dialing out. Kermit's access to serial devices is controlled by "UUCP lockfiles", which are intended to prevent different users using different software programs (Kermit, cu, etc, and UUCP itself) from accessing the same serial device at the same time. When a device is in use by a particular user, a file with a special name is created in the /var/spool/locks directory. The file's name indicates the device that is in use, and its contents indicates the process ID (pid) of the process that is using the device. Since serial devices and the /var/spool/locks directory are not both publicly readable and writable, Kermit and other communication software must be installed setuid to the owner (bin) of the serial device and setgid to the group (daemon) of the /var/spool/locks directory. Kermit's setuid and setgid privileges are enabled only when opening the device and accessing the lockfiles. Let's say "unit" means a string of decimal digits (the interface instance number) followed by the letter "p" (lowercase), followed by another string of decimal digits (the port number on the interface), e.g. "0p0", "0p1", "1p0", etc. Then a normal serial device (driver) name consists of a prefix ("tty", "ttyd", "cua", "cul") followed by a unit, e.g. "cua0p0". Kermit's treatment of UUCP lockfiles is as close as possible to that of the HP-UX "cu" program. Here is a table of the lockfiles that Kermit creates for unit 0p0: Selection Lockfile 1 Lockfile 2 ------------ ------------ ------------ /dev/tty0p0 LCK..tty0p0 (none) * /dev/ttyd0p0 LCK..ttyd0p0 (none) /dev/cua0p0 LCK..cua0p0 LCK..ttyd0p0 /dev/cul0p0 LCK..cul0p0 LCK..ttyd0p0 LCK.. (none) (* = Dialin device, should not be used.) The final case allows for symbolic links, etc, but, of course, it is not foolproof since we have no way of telling which device is really being used. When Kermit tries to open a dialout device whose name ends with a "unit", it searches the lockfile directory for all possible names for the same unit. For example, if user selects /dev/cul2p3, Kermit looks for lockfiles named LCK..tty2p3, LCK..ttyd2p3, LCK..cua2p3, and LCK..cul2p3. If any of these files are found, Kermit opens them to find out the ID (pid) of the process that created them; if the pid is still valid, the process is still active, and so the SET LINE command fails and the user is informed of the pid so s/he can use "ps" to find out who is using the device. If the pid is not valid, the file is deleted. If all such files (i.e. with same "unit" designation) are successfully removed, then the SET LINE command succeeds; up to four messages are printed telling the user which "stale lockfiles" are being removed. If the selected device was in use by "cu", Kermit can't open it, because "cu" has changed its ownership, so we never get as far as looking at the lockfiles. In the normal case, we can't even look at the device to see who the owner is because it is visible only to its (present) owner. In this case, Kermit says (for example): /dev/cua0p0: Permission denied When Kermit releases a device it has successfully opened, it removes all the lockfiles that it created. This also happens whenever Kermit exits "under its own power". If Kermit is killed with a device open, the lockfile(s) are left behind. The next Kermit program that tries to assign the device, under any of its various names, will automatically clean up the stale lockfiles because the pids they contain are invalid. (3.2.4) HP-UX 10.10 AND LATER C-Kermit is included as part of the HP-UX 10.xx operating system by contract between Hewlett Packard and Columbia University. Each level of HP-UX 10.xx includes a freshly built C-Kermit binary in /bin/kermit, which should work correctly. However, if you are building your own or downloading from Columbia, you should be aware that you can only use a binary that was built under the same OS level as you are running. As of C-Kermit version 6.0, HP-UX 10.xx binaries announce, in the startup herald and the VERSION command, the explicit HP-UX version they were built for: HP-UX 10.00, 10.10, 10.20, or 10.30. If there is a version mismatch, HP-UX does something like "Invalid version for shared lib /usr/lib/libc.1, IOT trap (core dumped)". Beginning in 10.10, libcurses is linked to libxcurses, the new UNIX95 (X/Open) version of curses, which has some serious bugs; some routines, when called, would hang and never return, some would dump core. Evidently libxcurses contains a select() routine, and whenever C-Kermit calls what it thinks is the regular (sockets) select(), it gets the curses one, causing a segmentation fault. There is a patch for this from HP, PHCO_8086, "s700_800 10.10 libcurses patch", "shared lib curses program hangs on 10.10", "10.10 enhanced X/Open curses core dumps due to using wrong select call", 96/08/02 (you can tell if the patch is installed with "what /usr/lib/libxcurses.1"; the unpatched version is 76.20, the patched one is 76.20.1.2. It has been verified that C-Kermit works OK with the patched library, but results are not definite for HP-UX 10.20 or higher. To ensure that C-Kermit works even on non-patched HP-UX 10.10 systems, separate makefile entries are provided for HP-UX 10.00/10.01, 10.10, 10.20, etc, in which the entries for 10.10 and above link with libHcurses, which is "HP curses", the one that was used in 10.00/10.01. (3.3) C-KERMIT AND LINUX Be sure to read the comments in the "linux:" makefile entry. There are all sorts of confusing issues caused by the many and varied Linux distributions. Some of the worst involve the curses library and header files: where are they, what are they called, which ones are they really? Ditto for UUCP lock files. Run C-Kermit in the regular console screen, which provides VT100 emulation via the "console" termcap entry, or under X-Windows in an xterm window. Before starting C-Kermit in an xterm window, tell the xterm window's shell to "stty sane". How to set up your PC console keyboard to send VT220 key sequences when using C-Kermit as your communications program in an X terminal window: Create a file somewhere (e.g. in /root/) called .xmodmaprc, containing something like the following: keycode 77 = KP_F1 ! Num Lock => DEC Gold (PF1) keycode 112 = KP_F2 ! Keypad / => DEC PF1 keycode 63 = KP_F3 ! Keypad * => DEC PF3 keycode 82 = KP_F4 ! Keypad - => DEC PF4 keycode 111 = Help ! Print Screen => DEC Help keycode 78 = F16 ! Scroll Lock => DEC Do keycode 110 = F16 ! Pause => DEC Do keycode 106 = Find ! Insert => DEC Find keycode 97 = Insert ! Home => DEC Insert keycode 99 = 0x1000ff00 ! Page Up => DEC Remove keycode 107 = Select ! Delete => DEC Select keycode 103 = Page_Up ! End => DEC Prev Screen keycode 22 = Delete ! Backspace sends Delete (127) Then put "xmodmap " in your .xinitrc file (in your login directory), e.g. xmodmap /root/.xmodmaprc Of course you can move things around. Use the xev program to find out key codes. Different UUCP lockfile conventions are used by Linux, depending on your Linux distribution. In C-Kermit 6.0, "make linux" uses /var/lock/LCK..name, decimal ASCII 10-byte PID string with leading spaces because -DLINUXFSSTND ("Linux File System Standard") is included in the compilation CFLAGS. If you remove this definition, C-Kermit will use the earlier arrangement of integer PID, /usr/spool/uucp/LCK..name. The leading spaces are required by FSSTND 1.2, but FSSTND 1.0 required leading zeros; to get the leading zeros, also include -DFSSTND10. Use whichever option agrees with your uucp, cu, tip, etc, programs. Building C-Kermit on Linux 1.1.33 and 1.1.34 gets fatal compilation errors due to inconsistencies in the Linux header files. Linux kernel versions prior to 1.1.33 and later than 1.1.34 should be OK. C-Kermit versions prior to 5A(190) did not support hardware flow control or high interface speeds for Linux. One Linux user reported problems dialing out using the /dev/cua device; "device busy" errors. He said that using the alternative name (driver) for the device, /dev/ttyS2, made the problem go away. Reportedly there is a bug in gcc 2.5.8 with signed to unsigned compares that can wreak havoc when Kermit (or most any other program) is compiled with this version of gcc; reportedly this can be worked around, at least in part, by adding "-fno-unroll-loops" to the gcc compilation options. Reportedly, if you have the iBCS2 (Intel Binary Compatibility Standard 2) module installed, you can also run SCO Xenix and UNIX binaries under Linux, including the SCO C-Kermit binaries, shareable libraries and all. (iCBS2 is available via anonymous ftp from tsx-11.mit.edu, along with an SCO libc_s compatibility module for Linux). Some Linux users reported that after doing a file transfer using the fullscreen display (thermometer), that "screen scrolling locks up" and the cursor "is stuck on the bottom of the screen". This probably only happens when using the console device. This turns out to be a problem with Linux ncurses. The workaround is to use "set file display crt" or "serial". The cure (reportedly) is to build C-Kermit with Linux ncurses 1.8.7 (or later). (Time passes...) Now (early 1996) we have increasing reports of C-Kermit core dumping in Linux 1.2.x, e.g. when the "set line" command is given. But they are conflicting -- it happens to some people, not to others. Not much can be said about this but: From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Kermit drops core at SET LINE /dev/cua1 Date: 14 Feb 1996 15:43:07 GMT Organization: Columbia University In article <4fr2nc$n0o@mozo.cc.purdue.edu>, Branden Robinson wrote: : I'm trying to run C-Kermit under Linux, but as soon as I type "set line : /dev/cua1", kermit gets a segmentation fault. This is the correct line, as : evidenced by the fact that "echo ATDT" and a phone number redirected to : /dev/cua1 makes the modem dial. : : I thought this might have something to do with the lock file put on : /dev/cua1, but both the compliation with the -DLINUXFSSTND and without it : yield the same result. What is going on here? : : Relevant hardware: : Hayes Accura 14.4 + FAX internal on COM 2 : : Relevant software: : Linux Debian 0.93R6, kernel 1.2.13, GCC 2.6.3, C-kermit 1.90 : C-Kermit 5A(190) was tested successfully on every known Linux variation at the time it was released (October 1994), but since then what is collectively known as Linux has been changing rapidly out from underneath us, thanks in large part to its numerous repackagers. Most of the problems stem from the many and varied curses libraries; this is the first report I have heard of this nature. You might try: 1. The Debian C-Kermit distribution, put together and tested by the Debian Project. Maybe they linked it with different libraries than you did: ftp://kermit.columbia.edu/kermit/linux/ 2. The 6.0.192 Alpha not-yet-a-release: ftp://kermit.columbia.edu/kermit/test/ 3. Taking a debug log of a core-dumping session and sending the last hundred lines or so to kermit@columbia.edu for analysis. Also see if you can get a backtrace from the core file to find out what routine it was in when it faulted. I don't know what the command for this is on Linux -- locally I use "adb kermit core" and then "$c", where "kermit" is Kermit's pathname and "core" is the core file's pathname. griffith@axopta.kodak.com (John D. Griffith) replies: Well I am succesfully using C-kermit 1.90 with the same modem on /dev/cua2 (COM3). I am running linux 1.2.13 (a.out) and gcc 2.5.8. My distribution was originally Red Hat Release 1.0, but has been considerably customized since then. mitchell@mdd.comm.mot.com (Bill Mitchell) replies: I'm the debian kermit maintainer, but I'm afraid I don't have much of a clue about this. The debian kermit sources are stock kermit sources except for the addition of some debian-specific files (debian.*) which don't impact non-debian compilation and the addition of a debian target in debian.makefile. I use kermit regularly on my debian linux system with the 1.2.13 kernel, and my modem is on /dev/cua1. And in the same vein... Date: Wed, 15 Nov 95 10:16:24 EST From: Frank da Cruz To: kurt klingbeil Subject: Re: cku190 & linux 1.1.59 vs 1.2.x ?? In-Reply-To: Your message of Tue, 14 Nov 1995 23:57:21 -0700 (MST) > Any idea what's changed in the serial handling of linux > between 1.1.x and 1.2.x ? > Absolutely no idea. It's just the way of the world. The rule is that if Kermit works in release n of any operating system, then release n+1 breaks it. I think this must be an internal requirement for OS developers. The nice thing about Linux is you don't even know who to ask about it. > Using cku190 to connect to a USR v.everything (no getty or any other process > active on that tty port): > I can dial, connect, run a remote session. > When I hangup, the loss of CD causes kermit > to disconnect, drop RTS and DTR, and return to its prompt. > > When attempting to immediately re-connect to the modem > (using c command), I can see the DTR and RTS lines being brought up: > (The modem's CTS and DSR remain set at all times.) > > Under Linux 1.1.59, kermit is immediately able to communincate with > the modem. Under Linux 1.2.{3,8,13} kermit appears to be hung - > no modem responses are received, kermit ignores it's escape character > and will wait forever. If one sends kermit a signal (either via kill, > or, if one is on the console via break (control-C is ignored as well)), > then a few characters of garbage appear in kermit's session, and > things are back to normal. > > I suspect that either a previously non-blocking read is now a blocking > read, or that previously the port was being properly flushed before > a connection was made, and that under 1.2.x it isn't and hence kermit > gets deadlocked waiting forever for a conidition which never occurs. > > Any ideas ? > (Unhelpful response deleted) Could this be the explanation? -- Date: Sat, 13 Jan 1996 09:48:11 -0800 (PST) From: John Harris Subject: C-Kermit Installation on Linux 1.2.1 Below is a letter which addresses the problem I was having installing C-Kermit on a Linux platform. So you do not need to waste your time addressing my difficulty, I wish to inform you that I have just resolved it; that is, the compile now takes place without even a warning. So that someone else can benefit, I briefly describe the cause of the problem. The following directories were not present: /usr/include/linux/ and /usr/src/linux/include/asm. There may also have been other files missing in certain directories; for example, /usr/include/linux and /usr/include/asm. The problem may have arisen from an oversight during Linux installation; for example, I may have forgotten to create the file system in advance of installation with "mke2fs -c " or perhaps I simply neglected to transfer some library files during the software installation itself. In more recent releases of Linux (mid-1996), the trend is to replace curses by ncurses. But of course this is not transparent to application software that includes curses.h and links with libcurses. Linus says it *should* be transparent -- the application should continue to refer to curses and not to ncurses. C-Kermit follows this recommendation, so if you have curses-related trouble during compilation or at runtime, create symbolic links called curses.h and libcurses.a (or .sa, or .so, or .so.XX, etc) pointing to ncurses.h and libncurses-dot-whatever, and rebuild Kermit. Also note that some Linux distributions have internal problems in their header files. In one case, there are fatal errors in that can be fixed by adding "#include " to the termcap.h file. See additional comments in the Linux entry in the makefile. (3.4) C-KERMIT AND NEXTSTEP Run C-Kermit in a Terminal, Stuart, or xterm window, or when logged in remotely through a serial port or TELNET connection. C-Kermit does not work correctly when invoked directly from the NeXTSTEP File Viewer or Dock. This is because the terminal-oriented gtty, stty, & ioctl calls don't work on the little window that NeXTSTEP pops up for non-NeXTSTEP applications like Kermit. CBREAK and No-ECHO settings do not take effect in the command parser -- commands are parsed strictly line at a time. "set line /dev/cua" works. During CONNECT mode, the console stays in cooked mode, so characters are not transmitted until carriage return or linefeed is typed, and you can't escape back. If you want to run Kermit directly from the File Viewer, then launch it from a shell script that puts it in the desired kind of window, something like this (for "Terminal"): Terminal -Lines 24 -Columns 80 -WinLocX 100 -WinLocY 100 $FONT $FONTSIZE \ -SourceDotLogin -Shell /usr/local/bin/kermit & C-Kermit does not work correctly on a NeXT with NeXTSTEP 3.0 to which you have established an rlogin connection, due to a bug in NeXTSTEP 3.0, which has been reported to NeXT. The SET CARRIER command has no effect on the NeXT -- this is a limitation of the tty device drivers. Hardware flow control on the NeXT is selected not by "set flow rts/cts" in Kermit (since NeXTSTEP offers no API for this), but rather, by using a specially-named driver for the serial device: /dev/cufa instead /dev/cua; /dev/cufb instead of /dev/cub. This is available only on 68040-based NeXT models (the situation for Intel NeXTSTEP implementations is unknown). NeXT-built 68030 and 68040 models have different kinds of serial interfaces; the 68030 has a Macintosh-like RS-422 interface, which lacks RTS and CTS signals; the 68040 has an RS-423 (RS-232 compatible) interface, which supports the commonly-used modem signals. WARNING: the connectors look exactly the same, but the pins are used in completely DIFFERENT ways -- different cables are required for the two kinds of interfaces. IF YOU GET LOTS OF RETRANSMISSIONS during file transfer, even when using a /dev/cuf* device and the modem is correctly configured for RTS/CTS flow control, YOU PROBABLY HAVE THE WRONG KIND OF CABLE. On the NeXT, Kermit reportedly (by TimeMon) causes the kernel to use a lot of CPU time when using a "set line" connection. That's because there is no DMA channel for the NeXT serial port, so the port must interrupt the kernel for each character in or out. One user reported trouble running C-Kermit on a NeXT from within NeXT's Subprocess class under NeXTstep 3.0, and/or when rlogin'd from one NeXT to another: Error opening /dev/tty:, congm: No such device or address. Diagnosis: Bug in NeXTSTEP 3.0, cure unknown. (3.5) C-KERMIT AND QNX Support for QNX 4.x was added in C-Kermit 5A(190). This is a full-function implementation, thoroughly tested on QNX 4.21, and verified to work in both 16-bit and 32-bit versions. Most advanced features are supported including TCP/IP, high serial speeds, hardware flow-control, modem-signal awareness, curses support, etc. Dialout devices are normally /dev/ser1, /dev/ser2, ..., and can be opened explicitly with SET LINE. Reportedly, "/dev/ser" (no unit number) opens the first available /dev/ser device. Like all other UNIX C-Kermit implementations, QNX C-Kermit does not provide any kind of terminal emulation. Terminal specific functions are provided by your terminal, terminal window (e.g. QNX Terminal or xterm), or emulator. QNX C-Kermit, as distributed, does not include support for UUCP line-locking; the QNX makefile entries (qnx32 and qnx16) include the -DNOUUCP switch. This is because QNX, as distributed, does not include UUCP, and its own communications software (e.g. qterm) does not use UUCP line locking. If you have a UUCP product installed on your QNX system, remove the -DNOUUCP switch from the makefile entry and rebuild. Then check to see that Kermit's UUCP lockfile conventions are the same as those of your UUCP package; if not, read the UUCP lockfile section ckuins.doc and make the necessary changes to the makefile entry (e.g. add -DHDBUUCP). BUG: The fullscreen file transfer display works fine the first time, but it is fractured on subsequent file transfers. Cause and cure unknown. (3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER There is all sorts of confusion among SCO versions, particularly when third- party communications boards and drivers are installed, regarding lockfile naming conventions. Basically, all bets are off if you are using a third party multiport board. At least you have the source code. Hopefully you also have a C compiler :-) Use SCO-provided utilities for switching the directionality of a modem line, such as "enable" and "disable" commands. For example, to dial out on tty1a, which is normally set up for logins: disable tty1a kermit -l /dev/tty1a enable tty1a In SCO Xenix, you must use SET CARRIER ON *and* use the upper-case tty device name in order to have carrier detection. SET CARRIER OFF should work with either upper or lowercase tty devices. SET CARRIER AUTO is the same as OFF. SCO Xenix and UNIX can provide different names for the same device. In Xenix, /dev/tty1a refers to a terminal device that has no modem control; open, read, write, and close operations do not depend on carrier. On the other hand, /dev/tty1A (same name, but with final letter upper case), is the same device with modem control, in which carrier is required (the SET LINE command does not complete until carrier appears, read/write operations fail if there is no carrier, etc). In the SCO case, C-Kermit always uses the lowercase name when creating the UUCP lockfile (this is, according to SCO experts, the proper behavior, but reportedly not all other communications applications found on SCO systems follow this rule). One user of C-Kermit 5A(190) on SCO UNIX 3.2.4 reported that C-Kermit dumps core when receiving files in local mode. The crash invariably occurs when the 16384th byte arrives, obviously indicating some kind of int/long, or short/int, or similar mismatch in argument-passing -- no doubt the byte count. Other users of SCO UNIX 3.2.4, built using the same makefile entry, report that they can receive files of any length with no problem at all. Maybe it depends on which file transfer display is being used? If this happens to you, try using a different file transfer display (SET FILE DISPLAY NONE, SERIAL, CRT, or FULLSCREEN). SCO users report that only one copy of Kermit can run at a time when a Stallion Technologies multiport boards are installed. (3.7) C-KERMIT AND SOLARIS The built-in SunLink X.25 support for Solaris 2.3/2.4./25 and SunLink 8.01 or 9.00 works OK provided the X.25 system has been installed and initialized properly. Packet sizes might need to be reduced to 256, maybe even less, depending on the configuration of the X.25 installation. On one connection where C-Kermit 6.0 was tested, very large packets and window sizes could be used in one direction, but only very small ones would work in the other. In any case, according to Sun, C-Kermit's X.25 support is superfluous with SunLink 8.x / Solaris 2.3. Quoting an anonymous Sun engineer: ... there is now no need to include any X.25 code within kermit. As of X.25 8.0.1 we support the use of kermit, uucp and similar protocols over devices of type /dev/xty. This facility was there in 8.0, and should also work on the 8.0 release if patch 101524 is applied, but I'm not 100% sure it will work in all cases, which is why we only claim support from 8.0.1 onwards. When configuring X.25, on the "Advanced Configuration->Parameters" screen of the x25tool you can select a number of XTY devices. If you set this to be > 1, press Apply, and reboot, you will get a number of /dev/xty entries created. Ignore /dev/xty0, it is a special case. All the others can be used exactly as if they were a serial line (e.g. /dev/tty) connected to a modem, except that instead of using Hayes-style commands, you use PAD commands. From kermit you can do a 'set line' command to, say, /dev/xty1, then set your dialing command to be "CALL 12345678", etc. All the usual PAD commands will work (SET, PAR, etc). I know of one customer in Australia who is successfully using this, with kermit scripts, to manage some X.25-connected switches. He used standard kermit, compiled for Solaris 2, with X.25 8.0 xty devices. C-Kermit can't be compiled successfully under Solaris 2.3 using SUNWspro cc 2.0.1 unless at least some of the following patches are applied to cc (it is not known which one(s), if any, fix the problem): 100935-01 SparcCompiler C 2.0.1: bad code generated when addresses of two double arguments are involved 100961-05 SPARCcompilers C 2.0.1: conditional expression with function returning strucure gives wrong value 100974-01 SparcWorks 2.0.1: dbx jumbo patch 101424-01 SPARCworks 2.0.1 maketool SEGV's instantly on Solaris 2.3 With unpatched cc 2.0.1, the symptom is that certain modules generate truncated object files, resulting in many unresolved references at link time. Using a Sun workstation keyboard for VT emulation when accessing VMS: From: Jerry Leichter Newsgroups: comp.os.vms Subject: Re: VT100 keyboard mapping to Sun X server Date: Mon, 19 Aug 1996 12:44:21 -0400 > I am stuck right now using a Sun keyboard (type 5) on systems running SunOS > and Solaris. I would like to use EVE on an OpenVMS box with display back to > the Sun. Does anyone know of a keyboard mapping (or some other procedure) > which will allow the Sun keyboard to approximate a VT100/VT220? You can't get it exactly - because the keypad has one fewer key - but you can come pretty close. Here's a set of keydefs I use: keycode 101=KP_0 keycode 119=KP_1 keycode 120=KP_2 keycode 121=KP_3 keycode 98=KP_4 keycode 99=KP_5 keycode 100=KP_6 keycode 75=KP_7 keycode 76=KP_8 keycode 77=KP_9 keycode 52=KP_F1 keycode 53=KP_F2 keycode 54=KP_F3 keycode 57=KP_Decimal keycode 28=Left keycode 29=Right keycode 30=KP_Separator keycode 105=KP_F4 keycode 78=KP_Subtract keycode 8=Left keycode 10=Right keycode 32=Up keycode 33=Down keycode 97=KP_Enter Put this in a file - I use "keydefs" in my home directory and feed it into xmodmap: xmodmap - <$HOME/keydefs This takes care of the arrow keys and the "calculator" key cluster. The "+" key will play the role of the DEC "," key. The Sun "-" key will be like the DEC "-" key, though it's in a physically different position - where the DEC PF4 key is. The PF4 key is ... damn, I'm not sure where "key 105" is. I *think* it may be on the leftmost key of the group of four just above the "calculator" key cluster. I also execute the following (this is all in my xinitrc file): xmodmap -e 'keysym KP_Decimal = KP_Decimal' xmodmap -e 'keysym BackSpace = Delete BackSpace' \ -e 'keysym Delete = BackSpace Delete' xmodmap -e 'keysym KP_Decimal = Delete Delete KP_Decimal' xmodmap -e 'add mod1 = Meta_R' xmodmap -e 'add mod1 = Meta_L' Beware of one thing about xmodmap: Keymap changes are applied to the *whole workstation*, not just to individual windows. There is, in fact, no way I know of to apply them to individual windows. These definitions *may* confuse some Unix programs (and/or some Unix users). If you're using Motif, you may also need to apply bindings at the Motif level. If just using xmodmap doesn't work, I can try and dig that stuff up for you. (end quote) NOTE: The rest of the problems in this section have to do with bidirectional tty lines and the Solaris Port Monitor. Hopefully these are all fixed in C-Kermit 6.0.192 Beta.029, 22 Aug 96. Reportedly, "C-Kermit ... causes a SPARCstation running Solaris 2.3 to panic after the modem connects. I have tried compiling C-Kermit with Sun's unbundled C compiler, with GCC Versions 2.4.5 and 2.5.3, with make targets 'sunos51', 'sunos51tcp', 'sunos51gcc', and even 'sys5r4', and each time it compiles and starts up cleanly, but without fail, as soon as I dial the number and get a 'CONNECT' message from the modem, I get: BAD TRAP kermit: Data fault kernel read fault at addr=0x45c, pme=0x0 Sync Error Reg 80 ... panic: Data Fault. ... Rebooting... The same modem works fine for UUCP/tip calling." Also (reportedly), this only happens if the dialout port is configured as in/out via admintool. If it is configured as out-only, no problem. This is the same dialing code that works on hundreds of other System-V based UNIX OS's. Since it should be impossible for a user program to crash the operating system, this problem must be chalked up to a Solaris bug. Even if you SET CARRIER OFF, CONNECT, and dial manually by typing ATDTnnnnnnn, the system panics as soon as the modem issues its CONNECT message. (Clearly, when you are dialing manually, C-Kermit does not know a thing about the CONNECT message, and so the panic is almost certainly caused by the transition of the Carrier Detect (CD) line from off to on.) This problem was reported by many users, all of whom say that C-Kermit worked fine on Solaris 2.1 and 2.2. If the speculation about CD is true, then a possible workaround might be to configure the modem to leave CD on (or off) all the time. Perhaps by the time you read this, a patch will have been issued for Solaris 2.3. The following is from Karl S. Marsh, Systems & Networks Administrator, AMBIX Systems Corp, Rochester, NY (begin quote): "Environment: Solaris 2.3 Patch 101318-45 C-Kermit 5A(189) (and presumably this applies to 188 and 190 also) eeprom setting: ttya-rts-dtr-off=false ttya-ignore-cd=false ttya-mode=19200,8,n,8,- "To use C-Kermit on a bidirectional port in this environment, do not use admintool to configure the port. Use admintool to delete any services running on the port and then quit admintool and issue the following command: pmadm -a -p zsmon -s ttyb -i root -fu -v 1 -m "`ttyadm -b -d /dev/term/b \ -l conttyH -m ldterm,ttcompat -s /usr/bin/login -S n`" [NOTE: This was copied from a fax, so please check it carefully] where: -a = Add service -p = pmtag (zsmon) -s = service tag (ttyb) -i = id to be associated with service tag (root) -fu = create utmp entry -v = version of ttyadm -m = port monitor-specific portion of the port monitor administrative file entry for the service -b = set up port for bidirectional use -d = full path name of device -l = which ttylabel in the /etc/ttydefs file to use -m = a list of pushable STREAMS modules -s = pathname of service to be invoked when connection request received -S = software carrier detect on or off (n = off) "This is exactly how I was able to get Kermit to work on a bi-directional port without crashing the system." (End quote) On the Solaris problem, also see SunSolve Bug ID 1150457 ("Using C-Kermit, get Bad Trap on receiving prompt from remote system"). Another user reported "So, I have communicated with the Sun tech support person that submitted this bug report [1150457]. Apparently, this bug was fixed under one of the jumbo kernel patches. It would seem that the fix did not live on into 101318-45, as this is EXACTLY the error that I see when I attempt to use kermit on my system." Later (Aug 94)... C-Kermit dialout successfully tested on a Sun4m with a heavily patched Solaris 2.3. The patches most likely to have been relevant: 101318-50: SunOS 5.3: Jumbo patch for kernel (includes libc, lockd) 101720-01: SunOS 5.3: ttymon - prompt not always visible on a modem connection 101815-01: SunOS 5.3: Data fault in put() NULL queue passed from ttycommon_qfull() 101328-01: SunOS 5.3: Automation script to properly setup tty ports prior to PCTS execution Still later (Nov 94): another user (Bo Kullmar in Sweden) reports that after using C-Kermit to dial out on a bidirectional port, the port might not answer subsequent incoming calls, and says "the problem is easy enough to to fix with the Serial Port Manager; I just delete the service and and install it again using the graphical interface, which underneath uses commands like sacadm and pmadm." Later Bo reports, "I have found that if I run Kermit with the following script then it works. This script is for /dev/cua/a, -s a is the last a in /dev/cua/a #! /bin/sh kermit sleep 2 surun pmadm -e -p zsmon -s a (end quote) (3.8) C-KERMIT AND SUNOS Sun SPARCstation users should read the section "Setting up Modem Software" in the Desktop SPARC Sun System & Network Manager's Guide. If you don't set up your serial ports correctly, Kermit (and other communications software) won't work right. Reportedly, C-Kermit does not work correctly on a Sun SPARCstation in an Open Windows window with scrolling enabled. Disable scrolling, or else invoke Kermit in a terminal emulation window (xterm, crttool, vttool) under SunView (this might be fixed in later SunOS releases). On the Sun with Open Windows, an additional symptom has been reported: outbound SunLink X.25 connections "magically" translate CR typed at the keyboard into LF before transmission to the remote host. This doesn't happen under SunView. SET CARRIER ON, when used on the SunOS 4.1 version of C-Kermit (compiled in the BSD universe), causes the program to hang uninterruptibly when SET LINE is issued for a device that is not asserting carrier. When Kermit is built in the Sys V universe on the same computer, there is no problem (it can be interrupted with Ctrl-C). This is apparently a limitation of the BSD-style tty driver. SunOS 4.1 C-Kermit has been observed to dump core when running a complicated script program under cron. The dump invariably occurs in ttoc(), while trying to output a character to a TCP/IP TELNET connection. ttoc() contains a write() call, and when the system or the network is very busy, the write() call can get stuck for long periods of time. To break out of deadlocks caused by stuck write() calls, there is an alarm around the write(). It is possible that the core dump occurs when this alarm signal is caught. (This one has not been observed recently -- possibly fixed in edit 190.) On Sun computers with SunOS 4.0 or 4.1, SET FLOW RTS/CTS works only if the carrier signal is present from the communication device at the time when C-Kermit enters packet mode or CONNECT mode. If carrier is not sensed (e.g. when dialing), C-Kermit does not attempt to turn on RTS/CTS flow control. This is because the SunOS serial device driver does not allow characters to be output if RTS/CTS is set (CRTSCTS) but carrier (and DSR) are not present. Workaround (maybe): SET CARRIER OFF before giving the SET LINE command, establish the connection, then SET FLOW RTS/CTS It has also been reported that RTS/CTS flow control under SunOS 4.1 through 4.1.3 works only on INPUT, not on output, and that there is a patch from Sun to correct this problem: Patch-ID# T100513-04, 20 July 1993 (this patch might apply only to SunOS 4.1.3). It might also be necessary to configure the eeprom parameters of the serial port; e.g. do the following as root at the shell prompt: eeprom ttya-ignore-cd=false eeprom ttya-rts-dtr-off=true There have been reports of file transfer failures on Sun-3 systems when using long packets and/or large window sizes. One user says that when this happens, the console issues many copies of this message: chaos vmunix: zs1: ring buffer overflow This means that SunOS is not scheduling Kermit frequently enough to service interrupts from the zs serial device (Zilog 8350 SCC serial communication port) before its input silo overflows. Workaround: use smaller packets and/or a smaller window size, or use "nice" to increase Kermit's priority. Use hardware flow control if available, or remove other active processes before running Kermit. SunLink X.25 support in C-Kermit 5A(190) has been built and tested successfully under SunOS 4.1.3b and SunLink X.25 7.00. (3.9) C-KERMIT AND ULTRIX There is no hardware flow control in Ultrix. That's not a Kermit deficiency, but an Ultrix one. Reportedly, DEC ULTRIX 4.3 is immune to C-Kermit's disabling of SIGQUIT, which is the signal that is generated when the user types Ctrl-\, which kills the current process (i.e. C-Kermit) and dumps core. Diagnosis and cure unknown. Workaround: before starting C-Kermit -- or for that matter, when you first log in because this applies to all processes, not just Kermit -- give the following UNIX command: stty quit undef Certain operations driven by RS-232 modem signal do not work on DECstations or other DEC platforms whose serial interfaces use MMP connectors (DEC version of RJ45 telephone jack with with offset tab). These connectors convey only the DSR and DTR modem signals, but not carrier (CD), RTS, CTS, or RI. Use SET CARRIER OFF to enable communication, or "hotwire" DSR to CD. (3.10) C-KERMIT AND UNIXWARE Using the UnixWare 1.1 Application Server, one user reports a system panic when the following script program is executed: set line /dev/tty4 set speed 9600 output \13 connect The panic does not happen if a PAUSE is inserted: set line /dev/tty4 set speed 9600 pause 1 output \13 connect This is using a Stallion EasyIO card installed as board 0 on IRQ 12 on a Gateway 386 with the Stallion-supplied driver. The problem was reported to Novell and Stallion, resolution pending. (Reportedly, this problem is now fixed.) (3.11) C-KERMIT AND APOLLO SR10 Reportedly, version 5A(190), when built under Apollo SR10 using "make sr10-bsd", compiles, links, and executes OK, but leaves the terminal unusable after it exits -- the "cs7" or "cs8" (character size) parameter has become cs5. The terminal must be reset from another terminal. Cause and cure unknown. Suggested workaround: Wrap Kermit in a shell script something like: kermit @* stty sane (3.12) C-KERMIT AND TANDY XENIX 3.0 Reportedly, if you type lots of Ctrl-C's during execution of the initialization file, ghost Kermit processes will be created, and will compete for the keyboard. They can only be removed via "kill -9" from another terminal, or by rebooting. Diagnosis -- something strange happening with the SIGINT handler while the process is reading the directory (it seems to occur during the SET PROMPT [\v(dir)] ... sequence). Cure: unknown. Workaround: don't interrupt C-Kermit while it is executing its init file on the Tandy 16/6000. (3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX) Reportedly, if a modem is set for &S0 (assert DSR at all times), the system resets or drops DTR every 30 seconds; reportedly DEC says to set &S1. Digital UNIX 3.2 evidently wants to believe your terminal is one line longer than you say it is, e.g. when a "more" or "man" command is given. This is has nothing to do with C-Kermit, but tends to annoy those who use Kermit or other terminal emulators to access Digital UNIX systems. Workaround: tell UNIX to "stty rows 23" (or whatever). (3.14) C-KERMIT AND SGI IRIX Reportedly on Silicon Graphics (SGI) machines with IRIX 4.0, Kermit cannot be suspended by typing the suspend ("swtch") character if it was started from csh, even though other programs can be suspended this way, and even though the Z and SUSPEND commands still work correctly. This is evidently because IRIX's csh does not deliver the SIGTSTP signal to Kermit. The reason other programs can be suspended in the same environment is probably that they do not trap SIGTSTP themselves, so the shell is doing the suspending rather than the application. Reportedly some Indys have bad serial port hardware. IRIX 5.2, for example, needs patch 151 to work around this; or upgrade to a later release. Similarly, IRIX 5.2 has several problems with serial i/o, flow control, etc. Again, patch or upgrade. For hardware flow control on IRIX, use the ttyf* (modem control AND hardware flow control) devices and not the ttyd* (direct) or ttym* (modem control but no hardward flow control) ones, and obtain the proper "hardware handshaking" cable from SGI, which is incompatible with the ones for the Macintosh and NeXT even though they look the same. "man serial" for further info. (3.15) C-KERMIT AND THE BEBOX The BeBox isn't a real product yet, and BeOS -- particularly the POSIX pieces of it -- aren't finished. As the POSIX bits are fleshed out, a lot of the Be-specific code can Be removed. The workarounds in this version are for DR7, contributed by an anonymous donor, sufficient to: - set line /dev/serial2 (and probably the other serial ports) - set speed 115200 (and at least some of the lower baud rates) - connect - set modem type hayes (and likely others, too) - dial [phone number] - set send packet length 2048 (other lengths for both send and receive) - set receive packet length 2048 - set file type binary (text mode works, too) (with remote kermit session in server mode) - put bedrop.jpg - get bedrop.jpg - get bedrop.jpg bedrop.jpg2 - finish, bye The following do not work: - kermit does not detect modem hangup - !/RUN/PUSH [commandline command] - running kermit in remote mode - using other protocols (x/y/zmodem) - TCP networking interface (Be's TCP/IP API has a ways to go, still) (4) GENERAL UNIX-SPECIFIC HINTS, LIMITATIONS, AND BUGS In version 6.0, the default C-Kermit prompt includes your current (working) directory; for example: [/usr/olga] C-Kermit> If that directory is on an NFS-mounted disk, and NFS stops working or the disk becomes unavailable, C-Kermit will hang waiting for NFS and/or the disk to come back. Whether you can interrupt C-Kermit when it is hung this way depends on the specific OS. Kermit has called the operating systems's getcwd() function, and is waiting for it to return. Some versions of UNIX (e.g. HP-UX 9.x) allow this function to be interrupted with SIGINT (Ctrl-C), others (such as HP-UX 8.x) do not. To avoid this effect, you can always use SET PROMPT change your prompt to something that does not involve calling getcwd(), but if NFS is not responding, C-Kermit will still hang any time you give a command that refers to the current directory. Also note that in some cases, the uninterruptibility of NFS-dependent system or library calls is considered a bug, and sometimes there are patches. For HP-UX, for example: HP-UX 10.20 libc PHCO_8764 HP-UX 10.10 libc PHCO_8763 HP-UX 9.x libc PHCO_7747 S700 HP-UX 9.x libc PHCO_6779 S800 You might have reason to make C-Kermit the login shell for a specific user, by entering the pathname of Kermit (possibly with command-line switches, such as -x to put it in server mode) into the shell field of the /etc/passwd file. This works pretty well. In some cases, for "ultimate security", you might want to use a version built with -DNOPUSH (see ckccfg.doc) for this, but even if you don't, then PUSHing or shelling out from C-Kermit just brings up a new copy of C-Kermit (but warning: this does not prevent the user from explicitly running a shell; e.g. "run /bin/sh"; use NOPUSH to prevent this). C-Kermit will not work as expected on a remote UNIX system, when used through the "splitvt" or GNU "screen" programs. In this case, terminal connections to the remote UNIX system work, but attempts to transfer files fail because the screen optimization (or at least, line wrapping, control-character absorption) done by this package interferes with Kermit's packets. You might try the following -- what we call "doomsday Kermit" settings to push packets through even the densest and most obstructive connections, such as "screen" and "splitvt" (and certain kinds of 3270 protocol emulators): Give these commands to BOTH Kermit programs: SET FLOW NONE SET CONTROL PREFIX ALL SET RECEIVE PACKET-LENGTH 70 SET RECEIVE START 62 SET SEND START 62 SET SEND PAUSE 100 SET BLOCK B If it works, it will be slow. On UNIX workstations equipped with DOS emulators like SoftPC, watch out for what these emulators do to the serial port drivers. After using a DOS emulator, particularly if you use it to run DOS communications software, you might have to reconfigure the serial ports for use by UNIX. On AT&T 7300 (3B1) machines, you might have to "stty nl1" before starting C-Kermit. Do this if characters are lost during communications operations. Under the bash shell (versions prior to 1.07 from CWRU), "pushing" to an inferior shell and then exiting back to Kermit leaves Kermit in the background such that it must be explicitly fg'd. This is reportedly fixed in version 1.07 of bash. Interruption by Ctrl-Z makes UNIX C-Kermit try to suspend itself with kill(0,SIGSTOP), but only on systems that support job control, as determined by whether the symbol SIGTSTP is defined (or on POSIX or SVR4 systems, if syconf(_SC_JOB_CONTROL) or _POSIX_JOB_CONTROL in addition to SIGTSTP). However, if Kermit is running under a login shell (such as the original Bourne shell) that does not support job control, the user's session hangs and must be logged out from another terminal, or hung up on. There is no way Kermit can defend itself against this. If you use a non-job control shell on a computer that supports job control, give a command like "stty susp undef" to fix it so the suspend signal is not attached to any particular key, or give the command SET SUSPEND OFF to C-Kermit, or build C-Kermit with -DNOJC. Reportedly, the UNIX C-Kermit server, under some conditions, on certain particular systems, fails to log out its login session upon receipt of a BYE command. Before relying on the BYE command working, test it a few times to make sure it works on your system: there might be system configuration or security mechanisms to prevent an inferior process (like Kermit) from killing a superior one (like the login shell). (5) INITIALIZATION AND COMMAND FILES C-Kermit's initialization file for UNIX is .kermrc (lowercase, starts with period) in your home directory, unless Kermit was built with the system-wide initialization-file option (see ckuins.doc). C-Kermit identifies your home directory based on the environment variable, HOME. Most UNIX systems set this variable automatically when you log in. If C-Kermit can't find your initialization file, check your HOME variable: echo $HOME (at the UNIX prompt) or: echo \$(HOME) (at the C-Kermit prompt) If HOME is not defined, or is defined incorrectly, add the appropriate definition to your UNIX .profile or .login file, depending on your shell: setenv HOME full-pathname-of-your-home-directory (C-Shell, .login file) or: HOME=full-pathname-of-your-home-directory (sh, ksh, .profile file) export HOME NOTE: Various other operations depend on the correct definition of HOME. These include the "tilde-expansion" feature, which allows you to refer to your home directory as "~" in filenames used in C-Kermit commands, e.g. send ~/.kermrc as well as the \v(home) variable. Prior to version 5A(190), C-Kermit would look for its initialization file in the current directory if it was not found in the home directory. This feature was removed from 5A(190) because it was a security risk. Some people, however, liked this behavior and had .kermrc files in all their directories that would set up things appropriately for the files therein. If you want this behavior, you can accomplish it in various ways, for example: . Create a shell alias, for example: alias kd="kermit -Y ./.kermrc" . Create a .kermrc file in your home directory, whose contents are: take ./.kermrc The TAKE command does not search your UNIX PATH for command files. If a command file is not in the current directory, you must give a full path specification for it. This poses a problem for TAKE commands that are themselves in TAKE files. See the trick used in CKETEST.INI... Suppose you need to pass a password from the UNIX command line to a C-Kermit script program, in such a way that it does not show up in "ps" or "w" listings. Here is a method (not guaranteed to be 100% secure, but definitely more secure than the more obvious methods): echo mypassword | kermit myscript The "myscript" file contains all the commands that need to be executed during the Kermit session, up to and including EXIT, and also includes an ASK or ASKQ command to read the password from standard input, which has been piped in from the UNIX 'echo' command, but it must not include a CONNECT command. Only "kermit myscript" shows up in the ps listing. (6) COMMUNICATION SPEED SELECTION Version-7 based UNIX implementations, including 4.3 BSD and earlier and UNIX systems based upon BSD, use a 4-bit field to record a serial device's terminal speed. This leaves room for 16 speeds, which are normally: 0, 50, 75, 110, 134.5, 150, 200, 300, 600, 1200, 1800, 2400, 4800, and 9600 The remaining two are usually called EXTA and EXTB, and are defined by the particular UNIX implementation. C-Kermit determines which speeds are available on your system based on whether symbols for them are defined in your terminal device header files. EXTA is generally assumed to be 19200 and EXTB 38400, but these assumptions might be wrong, or they might not apply to a particular device that does not support these speeds. Presumably, if you try to set a speed that is not legal on a particular device, the driver will return an error, but this can not be guaranteed. On these systems, it is usually not possible to select a speed of 14400 bps for use with V.32bis modems. In that case, use 19200 or 38400 bps, configure your modem to lock its interface speed and to use RTS/CTS flow control, and tell C-Kermit to SET SPEED RTS/CTS and SET DIAL SPEED-MATCHING OFF. Some recent versions of UNIX, and/or terminal device drivers that come with certain third-party add-in high-speed serial communication interfaces, use the low "baud rates" to stand for higher ones. For example, SET SPEED 50 gets you 57600 bps; SET SPEED 75 gets you 76800; SET SPEED 110 gets 115200. SCO ODT 3.0 is an example where a "baud-rate-table patch" can be applied that can rotate the tty driver baud rate table such that 600=57600 and 1800=115k baud. Similarly for Digiboard multiport/portservers, which have a "fastbaud" setting that does this. The situation is similar, but different, in System V. SVID Third Edition lists the same speeds, 0 through 38400. For further details, read the section TERMINAL SPEEDS in ckuins.doc. (7) COMMUNICATIONS AND DIALING The SET CARRIER command works as advertised only if the underlying operating system and device drivers support this feature; in particular only if a read() operation returns immediately with an error code if the carrier signal goes away. And, of course, if the devices themselves (e.g. modems) are configured appropriately and the cables convey the carrier signal, etc. When UNIX C-Kermit exits, it closes (and must close) the communications device. If you were dialed out, this will most likely hang up the connection. If you want to get out of Kermit and still use Kermit's communication device, you have several choices: 1. Shell out from Kermit or suspend Kermit, and refer to the device literally (as in "term -blah -blah < /dev/cua > /dev/cua"). 2. Shell out from Kermit and use the device's file descriptor which Kermit makes available to you in the \v(ttyfd) variable. 3. Use C-Kermit's REDIRECT command. See the CKCKER.UPD file about this. If you are having trouble dialing: 1. Make sure the dialout line is configured correctly. More about this below. 2. Make sure all necessary patches are installed for your operating system. 3. If you can't dial on a "bidirectional" line, then configure it for outbound-only (remove the getty) and try again. (The mechanisms -- if any -- for grabbing bidirectional lines for dialout vary wildly among UNIX implementations and releases, and C-Kermit -- which runs on well over 300 different UNIX variations -- makes no effort to keep up with them; the recommended method for coping with this situation is to wrap C-Kermit in a shell script that takes the appropriate actions.) 4. Make sure C-Kermit's SET DIAL and SET MODEM parameters agree with the modem you are actually using -- pay particular attention to SET DIAL SPEED-MATCHING. 5. Try SET DIAL HANGUP OFF before the DIAL command. Also, SET DIAL DISPLAY ON to watch what's happening. See section 8 of ckuins.doc. 6. Read pages 50-67 of "Using C-Kermit". 7. As a last resort, don't use the DIAL command at all; SET CARRIER OFF and CONNECT to the modem and dial interactively, or write a script program to dial the modem. Make sure your dialout line is correctly configured for dialing out (as opposed to login). The method for doing this is different for each kind of UNIX system. Consult your system documentation for configuring lines for dialing out (for example, SUN SparcStation IPC users should read the section "Setting up Modem Software" in the Desktop SPARC Sun System & Network Manager's Guide; HP-9000 workstation users should consult the manual "Configuring HP-UX for Peripherals", etc). Symptom: DIAL works, but a subsequent CONNECT command does not. Diagnosis: the modem is not asserting Carrier Detect (CD) after the connection is made, or the cable does not convey the CD signal. Cure: Reconfigure the modem, replace the cable. Workaround: SET CARRIER OFF (at least in System-V based UNIX versions). C-Kermit tries to use the 8th bit for data when parity is NONE, and this generally works on real UNIX terminal (tty) devices, but it often does not work when the UNIX system is accessed over a network via telnet or rlogin protocols, including (in many cases) through terminal servers. For example, an Encore computer with Annex terminal servers only gives a 7-bit path if the rlogin protocol is selected in the terminal server but it gives the full 8 bits if the proprietary RDP protocol is used. If file transfer does not work through a host to which you have rlogin'd, use "rlogin -8" rather than "rlogin". If that doesn't work, tell both Kermit programs to "set parity space". The Encore TELNET server does not allow long bursts of input. When you have a TELNET connection to an Encore, tell C-Kermit on the Encore to SET RECEIVE PACKET-LENGTH 200 or thereabouts. For Berkeley-UNIX-based systems (4.3BSD and earlier), Kermit includes code to use LPASS8 mode when parity is none, which is supposed to allow 8-bit data and Xon/Xoff flow control at the same time. However, as of edit 174, this code is entirely disabled because it is unreliable: even though the host operating system might (or might not) support LPASS8 mode correctly, the host access protocols (terminal servers, telnet, rlogin, etc) generally have no way of finding out about it and therefore render it ineffective, causing file transfer failures. So as of edit 174, Kermit once again uses rawmode for 8-bit data, and so there is no Xon/Xoff flow control during file transfer or terminal emulation in the Berkeley-based versions (4.3 and earlier, not 4.4). Also on Berkeley-based systems (4.3 and earlier), there is apparently no way to configure a dialout line for proper carrier handling, i.e. ignore carrier during dialing, require carrier thereafter, get a fatal error on any attempt to read from the device after carrier drops (this is handled nicely in System V by manipulation of the CLOCAL flag). The symptom is that carrier loss does not make C-Kermit pop back to the prompt automatically. This is evident on the NeXT, for example, but not on SunOS, which supports the CLOCAL flag. This is not a Kermit problem, but a limitation of the underlying operating system. For example, the cu program on the NeXT doesn't notice carrier loss either, whereas cu on the Sun does. On certain AT&T UNIX systems equipped with AT&T modems, DIAL and HANGUP don't work right. Workarounds: (1) SET DIAL HANGUP OFF before attempting to dial; (2) If HANGUP doesn't work, SET LINE, and then SET LINE to totally close and reopen the device. If all else fails, SET CARRIER OFF. C-Kermit does not contain any particular support for AT&T DataKit devices. You can use Kermit software to dial in to a DataKit line, but C-Kermit does not contain the specialized code required to dial out from a DataKit line. If the UNIX system is connected to DataKit via serial ports, dialout should work normally (e.g. set line /dev/ttym1, set speed 19200, connect, and then see the DESTINATION: prompt, from which you can connect to another computer on the DataKit network or to an outgoing modem pool, etc). But if the UNIX system is connected to the DataKit network through the special DataKit interface board, then SET LINE to a DataKit pseudodevice (such as /dev/dk031t) will not work (you must use the DataKit "dk" or "dkcu" program instead). In some BSD-based UNIX C-Kermit versions, SET LINE to a port that has nothing plugged in to it with SET CARRIER ON will hang the program (as it should), but it can't be interrupted with Ctrl-C. The interrupt trap is correctly armed, but apparently the UNIX open() call cannot be interrupted in this case. When SET CARRIER is OFF or AUTO, the SET LINE will eventually return, but then the program hangs (uninterruptibly) when the EXIT or QUIT command (or, presumably, another SET LINE command) is given. The latter is probably because of the attempt to hang up the modem. (In edit 169, a timeout alarm was placed around this operation.) With SET DIAL HANGUP OFF in effect, the DIAL command might work only once, but not again on the same device. In that case, give a SET LINE command with no arguments to close the device, and then another SET LINE command for the desired device. Or rebuild your version of Kermit with the -DCLSOPN compile-time switch (see ckuins.doc). The DIAL command says "To cancel: Type your interrupt character (normally Ctrl-C)." This is just one example of where program messages and documentation assume your interrupt character is Ctrl-C. But it might be something else. In most (but not necessarily all) cases, the character referred to is the one that generates the SIGINT signal. If Ctrl-C doesn't act as an interrupt character for you, type the Unix command "stty -a" or "stty all" or "stty everything" to see what your interrupt character is. (Kermit could be made to find out what the interrupt character is, but this would require a lot of system-dependent coding and #ifdefs, and a new routine and interface between the system-dependent and system-independent parts of the program.) In general, the hangup operation on a serial communication device is prone to failure. C-Kermit tries to support many, many different kinds of computers, and there seems to be no portable method for hanging up a modem connection (i.e. turning off the RS-232 DTR signal and then turning it back on again). If HANGUP, DIAL, and/or Ctrl-\H do not work for you, and you are a programmer, look at the tthang() function in ckutio.c and see if you can add code to make it work correctly for your system, and send the code to the address above. (NOTE: This problem has been largely sidestepped as of edit 188, in which Kermit first attempts to hang up the modem by "escaping back" via +++ and then giving the modem's hangup command, e.g. ATH0, when DIAL MODEM-HANGUP is ON, which is the default setting.) Even when Kermit's modem-control software is configured correctly for your computer, it can only work right if your modem is also configured to assert the CD signal when it is connected to the remote modem and to hang up the connection when your computer drops the DTR signal. So before deciding Kermit doesn't work with your modem, check your modem configuration AND the cable (if any) connecting your modem to the computer -- it should be a straight-through modem cable conducting the signals FG, SG, TD, RD, RTS, CTS, DSR, DTR, CD, and RI. Many UNIX systems keep aliases for dialout devices; for example, /dev/acu might be an alias for /dev/tty00. But most of these UNIX systems also use UUCP lockfile conventions that do not take this aliasing into account, so if one user assigns (e.g.) /dev/acu, then another user can still assign the same device by referring to its other name. This is not a Kermit problem -- Kermit must follow the lockfile conventions used by the vendor-supplied software (cu, tip, uucp). The SET FLOW-CONTROL KEEP option should be given *before* any communication (dialing, terminal emulation, file transfer, INPUT/OUTPUT/TRANSMIT, etc) is attempted, if you want C-Kermit to use all of the device's preexisting flow-control related settings. The default flow-control setting is XON/XOFF, and it will take effect when the first communication-related command is given, and a subsequent SET FLOW KEEP command will not necessarily know how to restore *all* of the device's original flow-control settings. (8) HARDWARE FLOW CONTROL SET FLOW RTS/CTS is available in UNIX C-Kermit only when the underlying operating system provides an Application Program Interface (API) for turning this feature on and off under program control, which turns out to be a rather rare feature among UNIX systems. To see if your UNIX C-Kermit version supports hardware flow control, type "set flow ?" at the C-Kermit prompt, and look for "rts/cts" among the options. Other common situations include: 1. The API is available, so "set flow rts/cts" appears as a valid C-Kermit command, but it doesn't do anything because the device driver (part of the operating system) was never coded to do hardware flow control. This is common among System V R4 implementations (details below). 2. The API is not available, so "set flow rts/cts" does NOT appear as a valid C-Kermit command, but you can still get RTS/CTS flow control by selecting a specially named device in your SET LINE command. Examples: NeXTSTEP: /dev/cufa instead of /dev/cua, /dev/cufb instead of /dev/cub (68040 only; "man zs" for further info). IRIX: /dev/ttyf2 instead of /dev/ttyd2 or /dev/ttym2 ("man 7 serial"). 3. The API is available, doesn't work, but a workaround as in (2) can be used. 4. The API is available, but Kermit doesn't know about it. In these cases, you can usually use an stty command to enable RTS/CTS on the device, e.g. "stty crtscts" or "stty ctsflow", "stty rtsflow", before starting Kermit, and then tell Kermit to SET FLOW KEEP. 5. No API and no special device drivers. Hardware flow control is completely unavailable. System V R4 based UNIXes are supposed to supply a file, which gives Kermit the necessary interface to command the terminal driver to enable/disable hardware flow control. Unfortunately, but predictably, many implementations of SVR4 whimsically place this file in /usr/include/sys rather than /usr/include (where SVID clearly specifies it should be; see SVID, Third Edition, V1, termiox(BA_DEV). Thus if you build C-Kermit with any of the makefile entries that contain -DTERMIOX or -DSTERMIOX (the latter to select ), C-Kermit will have "set flow rts/cts" and possibly other hardware flow-control related commands. BUT... That does not necessarily mean that they will work. In some cases, the underlying functions are simply not coded into the operating system. (9) TERMINAL CONNECTION AND KEY MAPPING UNIX C-Kermit's SET KEY command currently can not be used with keys that generate "wide" scan codes or multibyte sequences, such as workstation function or arrow keys, because UNIX C-Kermit does not have direct access to the keyboard. More about this in CKCKER.BWR. However, many UNIX workstations and/or console drivers provide their own key mapping feature. With xterm, for example, you can use 'xmodmap' ("man xmodmap" for details); here is an xterm mapping to map the Sun keyboard to DEC VT200 values for use with VT-terminal oriented applications like VMS EVE: keycode 101=KP_0 keycode 119=KP_1 keycode 120=KP_2 keycode 121=KP_3 keycode 98=KP_4 keycode 99=KP_5 keycode 100=KP_6 keycode 75=KP_7 keycode 76=KP_8 keycode 77=KP_9 keycode 52=KP_F1 keycode 53=KP_F2 keycode 54=KP_F3 keycode 57=KP_Decimal keycode 28=Left keycode 29=Right keycode 30=KP_Separator keycode 105=KP_F4 keycode 78=KP_Subtract keycode 8=Left keycode 10=Right keycode 32=Up keycode 33=Down keycode 97=KP_Enter Users of Linux consoles can use loadkeys ("man dumpkeys loadkeys keytables" for details. The format used by loadkeys is compatible with that used by Xmodmap, although it is not definitely certain that the keycodes are compatible for different keyboard types (e.g. Sun vs HP vs PC, etc). UNIX GNU EMACS includes a "kermit" library that allows Kermit connections to be made to other computers from within an EMACS window. As of June 1994, there is also a Kermit file transfer library for GNU EMACS. (10) FILE TRANSFER UNIX C-Kermit does not reject incoming files on the basis of size. There appears to be no good (reliable, portable) way to determine in advance how much disk space is available, either on the device, or (when quotas are involved) to the user. File transfer will fail if the incoming file is bigger than your ULIMIT. Use the UNIX ulimit command to examine or change your ULIMIT (the number is in 512-byte blocks, i.e. 0.5K). UNIX C-Kermit discards all carriage returns from incoming files when in text mode. If C-Kermit is receiving a file on a dialup connection and the connection hangs up, the SIGHUP signal is delivered to the top-level shell, which kills all processes (including Kermit and any of its subforks) and closes all open files, including the file that was being received. Even if you have told Kermit to SET FILE INCOMPLETE DISCARD, the partially received file is kept. See comments in ckutio.c (search for SIGHUP) for details. If you SET FILE DISPLAY FULLSCREEN, and C-Kermit complains "Sorry, terminal type not supported", it means that the terminal library (termcap or termlib) that C-Kermit was built with does not know about a terminal whose name is the current value of your TERM environment variable. If this happens, EXIT from C-Kermit and set a UNIX terminal type from among the supported values that is also supported by your terminal emulator, or else have an entry for your terminal type added to the system termcap and/or terminfo database. If you attempt to suspend C-Kermit during local-mode file transfer and then continue it in the background (via bg), it will block for "tty output" if you are using the FULLSCREEN file transfer display. This is apparently a problem with curses. Moving a local-mode file transfer back and forth between foreground and background works correctly, however, with the SERIAL, CRT, or NONE file transfer displays. If C-Kermit's command parser no longer echoes, or otherwise acts strangely, after returning from a file transfer with the fullscreen (curses) display, and your version of UNIX is based on AT&T System V, then try rebuilding your version of C-Kermit with -DCK_NEWTERM. Similarly if it echoes doubly, which might even happen during a subsequent CONNECT session. If rebuilding with -DCK_NEWTERM doesn't fix it, then there is something very strange about your systems curses library, and you should probably not use it. Tell C-Kermit to SET FILE DISPLAY CRT or anything else other than FULLSCREEN, or rebuild without -DCK_CURSES, and without linking with (termlib and) curses. It has been observed on a couple platforms -- e.g. BSDI and QNX -- that the curses display works properly only once. The second and subsequent times, the display is a mess. The reason is unknown, the cure is unknown. See the comments in screenc() in ckuusx.c. In one other case (one of the Linux distributions), a cure was obtained by linking to a different curses library (ncurses rather than curses). Reportedly, when using "MSEND *" from a 14-character filename UNIX system to another system (e.g. BSD) that allows longer names, with SET FILE NAMES LITERAL, any files with 14-character names will have a space added to the end of the name on the receiving machine (this *should* be fixed in 6.0). Optimum file transfer performance is a matter of tuning parameters like packet length, window size, control-character unprefixing, and on serial connections, ensuring there is an effective flow control method, preferably hardware (such as RTS/CTS). However, a fully-configured C-Kermit program can be slower than a minimally configured one simply because of its size. A command-line-only version that is stripped of every conceivable feature not affecting file transfer (such as "sunos41m" for the Sun or "dellsys5r4m" for Dell) can move files faster than a full-featured one. Thus, it might make sense to keep a minimal version available as well as a full-featured one. See the files ckuins.doc and ckccfg.doc as well as the makefile for how to do this. A fairly substantial reduction in size and a noticeable improvement in speed can be obtained simply by rebuilding C-Kermit without the debugging feature: make KFLAGS=-DNODEBUG See ckccfg.doc for more detailed information about configuration. (11) EXTERNAL FILE TRANSFER PROTOCOLS UNIX C-Kermit can be used in conjunction with other communications software in various ways. C-Kermit can be invoked from another communications program as an "external protocol", and C-Kermit can also invoke other communication software to perform external protocols. This sort of operation makes sense only when you are dialing out from your UNIX system. If the UNIX system is the one you have dialed in to, you don't need any of these tricks. Just run the desired software on your UNIX system instead of Kermit. When dialing out from a UNIX system, the difficulty is getting two programs to share the same communication device in spite of the UNIX UUCP lockfile mechanism, which would normally prevent any sharing, and preventing the external protocol from closing (and therefore hanging up) the device when it exits back to the program that invoked it. (This section deleted; see ckcker.upd.) "pcomm" is a general-purpose terminal program that provides file transfer capabilities itself (X- and YMODEM variations) and the ability to call on external programs to do file transfers (ZMODEM and Kermit, for example). You can tell pcomm the command to send or receive a file with an external protocol: send receive ZMODEM sz rz Kermit kermit -s kermit -r pcomm runs external programs for file transfer by making stdin and stdout point to the modem port, and then exec-ing "/bin/sh -c xxx" (where xxx is the appropriate command). However, C-Kermit does not treat stdin and stdout as the communication device unless you instruct it: send receive Kermit kermit -l 0 -s kermit -l 0 -r The "-l 0" option means to use file descriptor 0 for the communication device. In general, any program can pass any open file descriptor to C-Kermit for the communication device in the "-l" command-line option. When Kermit is given a number as the argument to the "-l" option, it simply uses it as a file descriptor, and it does not attempt to close it upon exit. Here's another example, for Seyon (a Linux communication program). First try the technique above. If that works, fine; otherwise... If Seyon does not give you a way to access and pass along the file descriptor, but it starts up the Kermit program with its standard i/o redirected to its (Seyon's) communications file descriptor, you can also experiment with the following method, which worked here in brief tests on SunOS. Instead of having Seyon use "kermit -r" or "kermit -s filename" as its Kermit protocol commands, use something like this (examples assume C-Kermit 6.0): For serial connections: kermit -YqQl 0 -r <-- to receive kermit -YqQl 0 -s filename(s) <-- to send one or more files For Telnet connections: kermit -YqQF 0 -r <-- to receive kermit -YqQF 0 -s filename(s) <-- to send one or more files Command line options: Y - skip executing the init file Q - use fast file transfer settings l 0 - transfer files using file descriptor 0 for a serial connection F 0 - transfer files using file descriptor 0 for a Telnet connection q - quiet - no messages r - receive s - send (11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT (This section is obsolete, but not totally useless. See section 8 of CKCKER.UPD.) After you have opened a communication link with C-Kermit's SET LINE (SET PORT) or SET HOST (TELNET) command, C-Kermit makes its file descriptor available to you in the \v(ttyfd) variable so you can make it available to other programs that you RUN from C-Kermit. Here, for example, C-Kermit runs itself as an external protocol: C-Kermit>set modem type hayes C-Kermit>set line /dev/acu C-Kermit>set speed 2400 C-Kermit>dial 7654321 Call complete. C-Kermit>echo \v(ttyfd) 3 C-Kermit>run kermit -l \v(ttyfd) Other programs that accept open file descriptors on the command line can be started in the same way. You can also use your shell's i/o redirection facilities to assign C-Kermit's open file descriptor (ttyfd) to stdin or stdout. For example, old versions of the UNIX ZMODEM programs, sz and rz, when invoked as external protocols, expect to find the communication device assigned to stdin and stdout with no option for specifying any other file descriptor on the sz or rz command line. However, you can still invoke sz and rz as exterior protocols from C-Kermit if your current shell ($SHELL variable) is ksh (the Korn shell) or bash (the Bourne-Again shell), which allows assignment of arbitrary file descriptors to stdin and stdout: C-Kermit> run rz <&\v(ttyfd) >&\v(ttyfd) or: C-Kermit> run sz oofa.zip <&\v(ttyfd) >&\v(ttyfd) In version 5A(190) and later, you can use C-Kermit's REDIRECT command, if it is available in your version of C-Kermit, to accomplish the same thing without going through the shell: C-Kermit> redirect rz or: C-Kermit> redirect sz oofa.zip A complete set of rz,sz,rb,sb,rx,sx macros for UNIX C-Kermit is defined in the file ckurzsz.ini. It automatically chooses the best redirection method. (11.3) USING C-KERMIT WITH TERM The "term" program provides an error-corrected, multiplexed connection between two UNIX systems, allowing you to run multiple applications over a single connection, for example several terminal windows and a file transfer simultaneously. Term depends on a communications application (such as C-Kermit) to make the connection and then redirect it to term's standard i/o. The advantages of using C-Kermit rather than other communication programs for this include: . C-Kermit's script language lets you automate the entire process. . With C-Kermit's REDIRECT command, term sessions are not limited to serial connections, but can work over network connections (TCP/IP, X.25) too. Here is an example showing how to set up a term session between two UNIX systems with with C-Kermit (assuming the connection has already been made by C-Kermit, e.g. by dialing up): C-Kermit> connect login: xxx Password: xxx $ exec term -r -s 38400 -A ^\c (escape back) C-Kermit>redirect term -s 38400 -A & C-Kermit>push $ Now you can run term clients such as trsh and tupload at the local shell prompt. (12) MISCELLANEOUS If C-Kermit has problems creating files in writable directories when it is installed setuid or setgid on BSD-based versions of UNIX such as NeXTSTEP 3.0, it probably needs to be rebuilt with the -DSW_ACC_ID comilation switch (see ckuins.doc). Reportedly, when coming into a Sequent UNIX (DYNIX) system through an X.25 connection, Kermit doesn't work right because the Sequent's FIONREAD ioctl returns incorrect data. To work around, use the 1-character-at-a-time version of myread() in ckutio.c (i.e. undefine MYREAD in ckutio.c and rebuild the program). ------------------------------ USER REPORTS - Date: Thu, 12 Mar 92 1:59:25 MEZ From: Walter Mecky Subject: Help.Unix.sw To: svr4@pcsbst.pcs.com, source@usl.com PRODUCT: Unix RELEASE: Dell SVR4 V2.1 (is USL V3.0) MACHINE: AT-386 PATHNAME: /usr/lib/libc.so.1 /usr/ccs/lib/libc.a ABSTRACT: Function ttyname() does not close its file descriptor DESCRIPTION: ttyname(3C) opens /dev but never closes it. So if it is called often enough the open(2) in ttyname() fails. Because the broken ttyname() is in the shared lib too all programs using it can fail if they call it often enough. One important program is uucico which calls ttyname for every file it transfers. Here is a little test program if your system has the bug: #include #include main() { int i = 0; while (ttyname(0) != NULL) i++; perror("ttyname"); printf("i=%d\n", i); } If this program runs longer than some seconds you don't have the bug. WORKAROUND: None FIX: Very easy if you have source code. Another user reports some more explicit symptoms and recoveries: > What happens is when invoking ckermit we get one of the following > error messages: > You must set line > Not a tty > No more processes. > One of the following three actions clears the peoblem: > shutdown -y -g0 -i6 > kill -9 the ttymon with the highest PID > Invoke sysadm and disable then enable the line you want to use. > Turning off respawn of sac -t 300 and going to getty's and uugetty's > does not help. > > Also C-Kermit reports "?timed out closing /dev/ttyxx". > If this happens all is well. ------------------------------ (Note: the following problem also occurs on SGI and probably many other UNIX systems): From: James Spath To: Info-Kermit-Request@cunixf.cc.columbia.edu Date: Wed, 9 Sep 1992 20:20:28 -0400 Subject: C-Kermit vs uugetty (or init) on Sperry 5000 We have sucessfully compiled the above release on a Unisys/Sperry 5000/95. We used the sys5r3 option, rather than sys5r2 since we have VR3 running on our system. In order to allow dialout access to non-superusers, we had to do "chmod 666 /dev/tty###", where it had been -rw--w--w- (owned by uucp), and to do "chmod +w /usr/spool/locks". We have done text and binary file transfers through local and remote connections. The problem concerning uucp ownership and permissions is worse than I thought at first. Apparently init or uugetty changes the file permissions after each session. So I wrote the following C program to open a set of requested tty lines. I run this for any required outgoing line prior to a Kermit session. ------ cut here ------- /* opentty.c -- force allow read on tty lines for modem i/o */ /* idea from: restrict.c -- Systsem 5 Admin book Thomas/Farrow p. 605 */ /* /jes jim spath {spath@jhunix.hcj.jhu.edu } */ /* 08-Sep-92 NO COPYRIGHT. */ /* this must be suid to open other tty lines */ /* #define DEBUG */ #define TTY "/dev/tty" #define LOK "/usr/spool/locks/LCK..tty" #include /* allowable lines: */ #define TOTAL_LINES 3 static char allowable[TOTAL_LINES][4] = { "200", "201", "300" }; static int total=TOTAL_LINES; int allow; /* states: */ #define TTY_UNDEF 0 #define TTY_LOCK 1 #define TTY_OKAY 2 main(argc, argv) int argc; char *argv[]; { char device[512]; char lockdev[512]; int i; if (argc == 1) { fprintf(stderr, "usage: open 200 [...]\n"); } while (--argc > 0 && (*++argv) != NULL ) { #ifdef DEBUG fprintf(stderr, "TRYING: %s%s\n", TTY, *argv); #endif sprintf(device, "%s%s", TTY, *argv); sprintf(lockdev, "%s%s", LOK, *argv); allow = TTY_UNDEF; i = 0; while (i <= total) { /* look at all defined lines */ #ifdef DEBUG fprintf(stderr, "LOCKFILE? %s?\n", lockdev); #endif if (access(lockdev, 00) == 0) { allow=TTY_LOCK; break; } #ifdef DEBUG fprintf(stderr, "DOES:%s==%s?\n", allowable[i], *argv); #endif if (strcmp(allowable[i], *argv) == 0) allow=TTY_OKAY; i++; } #ifdef DEBUG fprintf(stderr, "allow=%d\n", allow); #endif switch (allow) { case TTY_UNDEF: fprintf (stderr, "open: not allowed on %s\n", *argv); break; case TTY_LOCK: fprintf (stderr, "open: device locked: %s\n", lockdev); break; case TTY_OKAY: /* attempt to change mode on device */ if (chmod (device, 00666) < 0) fprintf (stderr, "open: cannot chmod on %s\n", device); break; default: fprintf (stderr, "open: FAULT\n"); } } exit (0); } ------------------------------ (End of CKUKER.BWR)