-*- text -*- CKUKER.BWR "Beware File" for C-Kermit Version 5A 8 May 91 Applies to 5A(171). 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 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 ckasys.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 one version of Unix, SCO Xenix/286, cannot cope with its length. An attempt to "make sco286" gives the message "Make: Cannot alloc mem for env.. Stop". Solution: edit away or comment out some or all of the other entries from the makefile. Other versions of SCO Xenix (SCO UNIX/386 3.2.0, SCO Senix 2.3.x) apparently do not tolerate continued lines in their makefile entries. If you encounter problems building these versions, edit the makefile to join the continued lines. Other makefile troubles may occur because tabs in the makefile have somehow been converted to spaces. Spaces and tabs are distinct in makefiles. 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. Version 5A of C-Kermit is much bigger than previous releases, and this may cause compilation, linking, or execution problems. See section 1 of ckuins.doc for hints. If wildcard expansion doesn't work (as in "send *" at the C-Kermit> prompt), 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 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 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. 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 should allow you to use much longer packets and bigger window sizes. If this works ok on your system, please notify the author at the address above. KNOWN BUGS AND LIMITATIONS C-Kermit does not work on certain UNIX workstations in certain environments: - On the NeXT when invoked directly from NeXTstep. You must invoke Kermit from a terminal or xterm window. - On a SUN SparcStation in an Open Windows window. You must invoke Kermit in a terminal emulation window (xterm, crttool, vttool). - On a remote SUN, when used through the GNU "screen" program. In this case, terminal connections to the SUN 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 NeXTstop pops up for 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. Solution, launch it from a shell script that puts it in the desired kind of window. 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. 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. Reportedly, on SCO UNIX 3.2.2, which has POSIX job control, sending a break during CONNECT (Ctrl-\B) causes Kermit to receive a SIGTTOU signal (i.e. "background process wants to do terminal output"), which suspends it (Kermit does not catch this signal). fg'ing Kermit just causes it to be immediately suspended again. VMS SPECIFICS Serial device i/o on VAX/VMS is not reliable yet; flow control is not done properly, buffer overruns and BYTLIM quota violations are common, especially when receiving files. This is an area of continuing development. For now, avoid very long packets or big window sizes. *** In fact, avoid all window sizes greater than 1 -- using sliding windows can make the program AND YOUR VMS JOB disappear! *** (this happens when entering VMS from an Ethernet/Telnet terminal server via CMU TCP/IP telnet daemon -- might not happen at all with real terminals, other TCP/IP implementations, LAT connections, etc...) VMS-style command-line editing (arrow keys, etc) is not supported. Ctrl-C and Ctrl-Y don't yet work right in all cases for VAX/VMS C-Kermit. 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 3.0 and 3.1. Kermit can't do anything about this... (because CKVTIO.C #includes , which itself includes ). The warning is not fatal. COMMUNICATIONS AND DIALING 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). To be more specific... On Berkeley-based Unix implementations that support PASS8 mode, Kermit uses this mode for file transfer because it allows 8-bit data and Xon/Xoff flow control at the same time. Unfortunately, the ioctl's that are used to put the terminal in this mode do not necessarily get propogated to the terminal server. Kermit thinks it has an 8-bit connection, but the terminal server (or host telnet server) is chopping off 8th bits. In 4F and earlier, Kermit just put the terminal into rawmode, and this worked ok with terminal servers, but without flow control, transfers failed frequently. A half-decent solution would be to put the terminal in rawmode if it's a pty, and use pass8 mode if it's a real tty. But there is no reliable and portable way to find out if the controlling terminal is a pty or a real tty. So if file transfer through a terminal server doesn't work, "set parity space". 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; write a script program to dial the modem. 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 may 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. On certain AT&T systems configured with AT&T modems and running vanilla AT&T UNIX, 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. 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.) 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). 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. 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 DTR RS-232 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 correctly if your modem is also configured correctly 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. Under BSD UNIX versions, it takes a long time 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. 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 not allowed. 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. FILENAME COLLISIONS 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. SCRIPT PROGRAMMING INPUT and REINPUT caseless string comparisons do not work for non-ASCII (international) characters. 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 is removed from 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. Reportedly, REMOTE DIR sent to a C-Kermit server built under System V R4 does not work (but "REMOTE HOST /bin/ls -l *" does work). ------------------------------ 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(). ------------------------------