CKUKER.BWR "Beware File" for C-Kermit Version 5A -*- text -*- Applies to 5A(179). Last update: Sat Feb 8 21:33:53 1992 Authors: Frank da Cruz, Christine M. Gianone, Columbia University. Copyright (C) 1985, 1992, Trustees of Columbia University in the City of New York. Permission is granted to any individual or institution to use this software as long as it is not sold for profit. This copyright notice must be retained. This software may not be included in commercial products without written permission of Columbia University. Report problems, suggestions, fixes, etc, to Frank da Cruz: Internet: fdc@watsun.cc.columbia.edu (or) fdc@columbia.edu BITNET/EARN: FDCCU@CUVMA Columbia University Center for Computing Activities 612 West 115th Street, New York, NY 10025 USA FILES Draft user documentation is in ckuker.doc (ckuker.ps is the Postscript version), with Scribe text formatter source in ckuhdr.mss and ckuker.mss. File naming conventions are listed in ckaaaa.hlp. UNIX installation instructions are in the make file (makefile or ckuker.mak), with further details in ckuins.doc. The VAX/VMS version is built with the file CKVKER.COM (just type @ckvker to build the VMS version). If you have trouble building or installing the program, or if the program you have built behaves in a bizarre fashion, BE SURE TO READ CKUINS.DOC as well as the rest of this file. Program function and variable definitions are in ckaplm.doc (for programmers only). A brief list of changes since version 4E is in ckuker.ann, and a long and detailed narrative (my diary) is in ckuker.upd (a very big file). INTRODUCTION The major goal at this stage is to make the program run on each kind of computer it claims to support, meaning that it should be compilable and linkable, it should fit in memory, and it should able to do i/o successfully in both remote and local modes. Therefore the first priority is to get the system-dependent aspects of the program in shape for as many different systems as possible. Modem control, lock files, and so forth are the big item here; this is the area where UNIX systems differ so dramatically from each other. A great deal of effort went into rationalizing the system-dependent teminal i/o functions in ckutio.c, but the results need to be thoroughly tested. Does Kermit interlock correctly with UUCP-family programs (cu, tip, uucp, etc)? Can you dial out? Can you CONNECT? Can you escape back and reconnect? Can you hang up? Can you connect to a modem without saying SET MODEM first? (See new SET CARRIER command). Once you pass these hurdles, can you transfer files? UNIX MAKEFILE The makefile is quite long, and at least two versions of Unix, SCO Xenix/286 and 2.x BSD, cannot cope with its length. An attempt to "make sco286" gives the message "Make: Cannot alloc mem for env.. Stop". Solution: edit away some or all of the nonrelevant material from the makefile. (A separate version of the makefile is provided for BSD 2.x: ckubs2.mak.) Some make programs reportedly cannot handle continued lines (lines ending in backslash (\). If you have a problem with the makefile, try editing the makefile to join the continued lines (remove the backslashes and the following linefeed). Other makefile troubles may occur because tabs in the makefile have somehow been converted to spaces. Spaces and tabs are distinct in makefiles. If the makefile entry for your version of C-Kermit does not include -DDYNAMIC, try adding it. This should make the program image smaller, and it will allow you to use much longer packets and bigger window sizes. If this works on your system, please notify the author at the address above. If the makefile entry for your version of C-Kermit does not include TCP/IP support, but your UNIX system does support TCP/IP using the Berkeley sockets library, or some variation of it, try adding -DTCPSOCKET to your makefile entry. If it "almost works", there are some other switches you can add to force recognition of the various slightly-incompatible TCP/IP implementations (-DWOLLONGONG, -DEXCELAN, etc). CHECK YOUR CONFIGURATION! (These comments apply mainly to the UNIX version...) Make sure your version of C-Kermit was built using the most appropriate makefile entry. See the comments at the top of the makefile. Then look for additional comments in the makefile entry itself. Version 5A of C-Kermit is much bigger than previous releases, and this might cause compilation, linking, or execution problems. If necessary, see section 1 of ckuins.doc for hints on reducing its size. If wildcard expansion doesn't work (try "send *?" at the C-Kermit> prompt -- Kermit should list all the files in the current directory), your Kermit version was probably configured wrong. See Section 3 in ckuins.doc. In the meantime, try SET WILDCARD-EXPANSION SHELL as a workaround (but also read about it in the user manual - there are pitfalls). If typing Ctrl-C (or whatever your UNIX interrupt character is) to interrupt a command causes the program to exit or crash rather than returning you to the C-Kermit> prompt, the program probably needs to be built differently (find the bug and fix it, or add -DNOCCTRAP to your makefile entry and rebuild the program). See section 5 of ckuins.doc. If typing Ctrl-Z (or whatever your UNIX suspend character is) to put C-Kermit in the background hangs your UNIX job, the most likely explanation is that you are attempting to use Kermit's job control feature under a shell (such as the Bourne shell) that does not support job control, even though the underlying version of UNIX does support it. More about this below. If you get "access denied" or similar messages in response to SET LINE, read sections 6 and 7 of ckuins.doc. If you run Kermit interactively, but there is no prompt at all, that means C-Kermit incorrectly deduced that it was running in the background. The test is in conint() in ckutio.c. If you can fix it for your system, please send in the fix. Otherwise, you can force C-Kermit to foreground mode by starting it with the -z command line option, as in "kermit -z", or giving the interactive command SET BACKGROUND OFF. This behavior has been reported on MIPS and Convex implementations. KNOWN BUGS AND LIMITATIONS C-Kermit does not work correctly on certain UNIX workstations in certain environments: - On the NeXT when invoked directly from NeXTstep. You must invoke Kermit from a "terminal", Stuart, or xterm window. - 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. - On a remote UNIX system, when used through the GNU "screen" program. In this case, terminal connections to the remote UNIX system work, but attempts to transfer files fail because the screen optimization done by this package interferes with Kermit's packets. The problem on the NeXT is that 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 Browser, 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 & 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. 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 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. System V R4 versions of C-Kermit built with TCP/IP networking, there seems to be a problem establishing TCP (set host) connections when you give an IP hostname. The name is resolved without complaint, but when you CONNECT, all you get is a dead screen. If you use an IP host number instead, connections work right. VMS SPECIFICS VMS-style command-line editing (arrow keys, etc) is not supported. Kermit does not use the VMS F$PARSE facility -- it has its own command parser that lacks certain features of F$PARSE (arrow-key editing, command recall, etc) but has many other features that F$PARSE lacks: "?"-help, keyword and filename completion, variables, macros, etc, similar to DCL. Ctrl-C and Ctrl-Y don't yet work right in all cases. Anyone building the VMS version with TGV MultiNet support under VAX C 3.1 will get an error message about conficting definitions of time_t. This is because of a conflict between DEC's and MultiNet's caused because DEC changed the definition between VAX C 3.0 and 3.1. Kermit can't do anything about this... (because CKVTIO.C #includes , which itself includes ). The warning is not fatal. Some problems reported with line terminators in VFC-format files. Various problems with flow control and with 8-bit i/o vs parity. These are being worked on. It is possible to SET LINE to an LTA (LAT) device, but correct operation is reportedly dependent on the version of DECserver code and the VMS version, and which patches have been applied. Correct operation has been verified for DECserver 200 software V3.1-37 and VMS V5.4-3, unpatched. If Kermit cannot successfully SET LINE to an LTA device, get out of Kermit and try SET HOST /DTE to the same device. If it doesn't work, then it's a DECserver and/or VMS problem, not a Kermit problem. Another problem sometimes reported with SET LINE LTAxxx connections is that the line seems to be stuck after being used once. Nobody else can use it until the port is logged out on the DECserver. Most likely the modem and/or DS200 aren't configured or wired to properly close the virtual connection when the call is terminated. This can be checked with LATmaster: $ mcr latcp LAT Control Program, Version 5.4-3 LATCP> sho port Port Name Port Type Status Remote Target (Node/Port/Service) _LTA104: Application Inactive LT2006/PORT_8/ LATCP> sho port lta104:/full Local Port Name: _LTA104: Local Port Type: Application (Queued) Local Port State: Inactive Connected Link: Target Port Name: PORT_8 Actual Port Name: Target Node Name: LT2006 Actual Node Name: Target Service Name: Actual Service Name: LATCP> EXIT If the port shows as "Active", then it's a DEC LAT bug or a wiring problem. COMMUNICATIONS AND DIALING 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. 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 (but it gives the full 8 bits if the proprietary RDP protocol is used). For Berkeley-UNIX-based systems, 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. DIAL might not work. If it doesn't, 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. Or don't use the DIAL command at all; CONNECT to the modem and dial interactively, or write a script program to dial the modem. 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. The DIAL command does not always seem to wait the full announced interval for the call to complete. Probably something to do with alarms stomping over each other. Try SET DIAL TIMEOUT to increase the interval. The DIAL command says to "Type your interrupt character (normally ^C) to cancel the dialing." 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. In Unix, type the Unix command "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. (On a similar note, Kermit could find out what your erase, line-delete, word-delete, etc, characters are and use them in the command parser instead of hardwired DEC-style editing characters. This is on the list of things to do.) 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.) 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. Similarly, on the RS/6000 (and possibly others) if you SET LINE to a device that has nothing connected to it, then CONNECT, you can't escape back -- C-Kermit never even gets to see the characters you type, even if you SET CARRIER OFF. This is a mystery, because there are two separate forks going. The fork reading from the port might block, but that shouldn't stop the keyboard-reading fork from getting your escape character.... 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. Reportedly, all versions of IBM AIX use the same (undocumented) lockfile conventions as RTAIX. If this is true, the "makes" for PS/2 AIX, AIX/370, and RS/6000 will have to be changed to use the RTAIX convention (it may be sufficient to simply add -DRTAIX to the make entry). 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. 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 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. Certain UNIX systems, such as SCO Xenix, 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). Similarly, NeXT computers use different names for the same communication device depending on whether RTS/CTS flow control is to be used (e.g. /dev/cufa for RTS/CTS, /dev/cua for no RTS/CTS). 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. Under BSD UNIX versions, it takes a long time to complete operations that involve changing TTY modes. This is because the BSD stty calls do not wait for pending i/o to complete first, and so Kermit must sleep before invoking these functions. System V versions don't have this problem. INPUT, OUTPUT, SCRIPT, and similar commands do not work on a SunLink X.25 connection if a CONNECT command has not already been given, or the circuit has not been initialized by some other means. TCP/IP CONNECTIONS If you connect to a remote host and don't see any greeting or login prompt, type carriage return or linefeed (Ctrl-J) to wake it up. If you have trouble transferring files over a TCP/IP connection, give the command: set parity space and try again. If that doesn't work, also try a shorter packet length. THE C-KERMIT COMMAND PARSER . There is no command recall or retry. . VMS-style command-line editing (arrow keys, etc) is not supported. . EMACS- or VI-style command line editing is not supported either. . Typeahead is presently not allowed. . Editing key are hardwired (Ctrl-U, Ctrl-W, etc). The restriction against typeahead is not deliberate, it's a bug that has resisted fixing for many years. If you type a macro name without a preceding DO, then a space (and then any other text at all), the command parser will allow you to delete into the prompt if you type backspaces, DELs, Ctrl-W's, or Ctrl-U. If you enter printable characters into a command with the backslash quoting mechanism, for example "echo why\?", backspaces, DELs, Ctrl-W's, or Ctrl-U will not erase all the way back to the prompt. To see the real results of command editing in the above two circumstances, type Ctrl-R. If you quote special characters in a filename (e.g. in the SEND command), filename completion may appear to work incorrectly. For example, if you have a file whose name is a*b (the name really contains an asterisk), and you type send a\\*, the "b" will not appear, nor will Ctrl-R redisplay the completed name correctly. But internally the file name is recognized anyway. The INPUT command (for some unknown reason) does not recognize characters that arrived into the system's input buffer before the INPUT command was issued. In the UNIX version (perhaps BSD-based UNIX only), if your .kermrc file contains a SET PARITY EVEN command and a SERVER command, the Kermit protocol won't work. Apparently the terminal modes aren't being set correctly in this case. TERMINAL EMULATION Most versions of C-Kermit (UNIX, VMS, OS-9, Amiga) do not emulate any kind of terminal (the OS/2 and Macintosh versions are exceptions). Rather, they act more or less as a "transparent pipe", passing the characters you type during a CONNECT session to the remote host, and sending the characters received from the remote host to your screen. Whatever is controlling your keyboard and screen provides the specific terminal emulation: a real terminal, a PC running a terminal emulator, etc, or (in the case of a self-contained workstation) your console driver, a terminal window, xterm, etc. There are several exceptions to the "transparent pipe" rule: - During a TELNET ("set host") session, C-Kermit itself executes the TELNET protocol and performs TELNET negotiations itself. - If you have changed your keyboard mapping using SET KEY, C-Kermit replaces the characters you type with the characters or strings you have mapped them to. - If you SET your TERMINAL CHARACTER-SET to anything besides TRANSPARENT, C-Kermit translates your keystrokes (after applying any SET KEY definitions) before sending them to the remote host, and translates the characters received from the remote host before sending them to your screen. - If your remote and/or local TERMINAL CHARACTER-SET is an ISO 646 7-bit national replacement character set, such as German, French, Italian, Swedish, etc, or Short KOI used for Cyrillic, C-Kermit's CONNECT command automatically skips over ANSI escape sequences to avoid translating their characters. Only ANSI/ISO standard (VT200/300-like) escape sequence formats are supported for this purpose, no proprietary schemes like H-P, Televideo, Tektronix, etc. FILE TRANSFER Some communication software, notably a certain popular commercial package, claim to implement sliding windows, but do not do so correctly. If sliding window transfers fail, set C-Kermit's window size to the smallest one that works, for example: SET WINDOW 1 The UNIX version of C-Kermit discards carriage returns when receiving files in text mode. Thus, "bare" carriage returns (sometimes used to achieve overstriking) are lost. SET FILE COLLISION BACKUP is now the default. This means: - If you send the same file lots of times, there will be many backup files. There is no automatic mechanism within Kermit to delete them, no notion of a "version retention count", etc. - If a file arrives that has the same name as directory, the file transfer fails. Send the file with another name, or use SET FILE COLLISION RENAME. When C-Kermit is receiving files from another Kermit program that has been given the MAIL or REMOTE PRINT command, C-Kermit follows the current filename collision action. This can be disconcerting if the action was (for example) BACKUP, because the existing file will be renamed, and the new file will be mailed (or printed) and then deleted. Kermit cannot temporarily change to RENAME because the file collision action occurs when the filename packet is received, and the PRINT or MAIL disposition only comes later, in the Attribute packet. (NOTE: a fix is in the works, at least for UNIX, which pipes the incoming file to the mail or print program.) SCRIPT PROGRAMMING INPUT and REINPUT caseless string comparisons do not work for non-ASCII (international) characters. Workaround: SET INPUT CASE OBSERVE. Certain operations, like INPUT, are flaky on the NeXT with NeXTstep 2.0. Maybe this has something to do with the tty device driver? (The release notes for NeXTstep 2.1 include the words: "More robust serial port driver.") GOTO can be used sort of like switch/case. For example, if you know that the value of \%a is 1, 2, or 3, you can "goto \%a" provided you have labels :1, :2, and :3. What it missing, however, is a way to trap failing GOTOs, similar to the "default:" clause of a C switch() statement. You can't use END or RETURN statements in FOR, WHILE, and XIF commands (you can use them, but they won't do what you expect). MISCELLANEOUS The ERROR command does not work, don't use it! (It was removed in edit 166.) 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. There have been reports of file transfer failures on SUN 3 systems when using long packets are 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 (UNIX) 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 or smaller window size, or use "nice" to increase Kermit's priority, or remove other active processes before running Kermit. ------------------------------ USER REPORTS - Date: Wed, 6 Jun 90 23:51:10 PDT From: dunlap@apl-em.apl.washington.edu (John Dunlap) To: fdc@watsun.cc.columbia.edu Subject: Re: C-Kermit 5A Edit 144 I should mention that I have discovered a bug in C-Kermit using HP-UX version 5.21 on the HP-9000 series 500 computers. This bug seems to have been present at least as far back as version 095. 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. This may be why some people are saying that Kermit won't work for them on the series 800 HP computers -- the 27140 6 port modem mux is used on that computer while the 27140 8 port mux cannot be used. One of these months I may be able to test this a bit more, but for the time being I just moved my terminal port to the 8 port mux! ------------------------------ Date: Tue, 16 Oct 90 23:35:26 -0400 From: wbader@scarecrow.csee.lehigh.edu (William Bader) To: fdc@watsun.cc.columbia.edu Subject: ckermit 159 notes The changes to the update file mentioned something about putting alarms on some io calls to prevent flow control deadlocks. Device drivers in Xenix (and possibly other ports of versions of AT&T Unix V.2 and V.3) have a higher priority than signals, which means that an alarm (or any signal including SIGKILL!) will not always interrupt a dead-locked read. When you turn off flow control on Xenix, there is a short window where an incoming ^S can get accepted, but no ^Q can be sent because flow control was turned off slightly after the ^S. [ckermit 4C would sometimes hang for this reason, and we could kill the shell to use that terminal, but the kermit process itself would become a zombie.] It might be possible (although not portable) to use select(). ------------------------------