CKUBWR.TXT "Beware File" for C-Kermit Version 7.0 -*- text -*- C-KERMIT FOR UNIX As of C-Kermit version: 7.0.197 This file last updated: 8 February 2000 Authors: Frank da Cruz and Christine M. Gianone, Columbia University. Copyright (C) 1985, 2000, Trustees of Columbia University in the City of New York. All rights reserved. See the C-Kermit COPYING.TXT file or the copyright text in the ckcmai.c module for disclaimer and permissions. 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, unresolved reports, etc, that apply to all UNIX variations, as well as to specific ones like HP-UX, AIX, Solaris, SunOS, Unixware, NeXTSTEP, etc etc. This file should be read in conjunction with the system-independent C-Kermit beware file, ckcbwr.txt, which contains similar information, but applying to all versions of C-Kermit (VMS, OS/2, AOS/VS, VOS, etc, as well as to UNIX). CONTENTS (0) DOCUMENTATION AND TECHNICAL SUPPORT (0.1) THE C-KERMIT USER MANUAL (0.2) TECHNICAL SUPPORT (0.3) THE YEAR 2000 (0.4) THE EURO SYMBOL (1) IMPORTANT FILES (2) BINARIES (3) NOTES ON SPECIFIC UNIX VERSIONS (3.0) C-KERMIT ON PC-BASED UNIXES (3.1) C-KERMIT AND AIX (3.2) C-KERMIT AND HP-UX 3.2.0. Common Problems 3.2.1. Building C-Kermit on HP-UX 3.2.2. Performance 3.2.3. Dialing Out and UUCP Lockfiles in HP-UX 3.2.4. HP-UX 5.00 3.2.5. HP-UX 8.00 3.2.6. HP-UX 9.00 AND LATER 3.2.7. HP-UX 10.10 AND LATER 3.2.8. HP-UX and X.25 (3.3) C-KERMIT AND LINUX 3.3.1. Problems Building C-Kermit for Linux 3.3.2. Problems with Serial Devices in Linux 3.3.3. Terminal Emulation in Linux 3.3.4. Dates and Times 3.3.5. Startup Errors (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 (3.16) C-KERMIT AND DG/UX (3.17) C-KERMIT AND SEQUENT DYNIX (3.18) C-KERMIT AND {FREE,OPEN,NET}BSD (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) SECURITY (13) MISCELLANEOUS USER REPORTS (14) THIRD-PARTY DRIVERS (0) DOCUMENTATION AND TECHNICAL SUPPORT (0.1) THE C-KERMIT USER MANUAL 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 $44.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) Or visit the Kermit website at http://www.columbia.edu/kermit/. 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. If you do not have the manual, please purchase it. It explains how to use C-Kermit, from getting started through advanced use and scripting, and sales of the manual are the primary source of funding for C-Kermit development and support. New features added since "Using C-Kermit", 2nd Ed, was published are documented in the ckermit2.txt file, which should be used as a supplement to the manual until the 3rd edition is published. (0.2) TECHNICAL SUPPORT Please consult the manual, plus the ckcbwr.txt file and this file itself, before submitting questions, reporting problems, etc, to: E-Mail: kermit-support@columbia.edu Web: http://www.columbia.edu/kermit/support.html 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 Telephone support is also available: +1 212 854-5126, cost: $25.00 per call, payable via Visa or MC. (0.3) THE YEAR 2000 The UNIX version of C-Kermit, release 6.0 and later, is "Year 2000 compliant", but only if the underlying operating system is too. Contact your UNIX operating system vendor to find out which operating system versions, patches, hardware, and/or updates are required. As of C-Kermit 6.0, post-millenium file dates are recognized, transmitted, received, and reproduced correctly during the file transfer process in C-Kermit's File Attribute packets. If post-millenium dates are not processed correctly on the other end, file transfer will still take place, but the modification or creation date of the received file might be incorrect. The only exception would be if the "file collision update" feature is being used to prevent unnecessary transfer of files that have not changed since the last time a transfer took place; in this case, a file might be transferred unnecessarily, or it might not be transferred when it should have been. Correct operation of the update feature depends on both Kermit programs having the correct date and time. Of secondary importance are the time stamps in the transaction and/or debug logs, and the date-related script programming constructs, such as \v(date), \v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time) and \v(ntime), insofar as they might be affected by the date. The \v(ndate) is a numeric-format date of the form yyyymmdd, suitable for both lexical and numeric comparison and sorting: e.g. 19970208 or 20011231. If the underlying operating system returns the correct date information, these variables will have the proper values. If not, then scripts that make decisions based on these variables might not operate correctly. Most date-related code is based upon the C Library asctime() string, which always has a four-digit year. In UNIX, the one bit of code in C-Kermit that is an exception to this rule is several calls to localtime(), which returns a pointer to a tm struct, in which the year is presumed to be expressed as "years since 1900". The code depends on this assumption. Any platforms that violate it will need special coding. As of this writing, no such platforms are known. Command and script programming functions that deal with dates use C-Kermit specific code that always uses full years. (0.4) THE EURO SYMBOL C-Kermit 7.0 and later support Unicode (ISO 10646), ISO 8859-15 Latin Alphabet 9, PC Code Page 858, Windows Code Pages 1250 and 1251, and perhaps other character sets, that encode the Euro symbol, and can translate among them as long as no intermediate character-set is involved that does not include the Euro. (1) IMPORTANT FILES In addition to the published documentation, the following files are useful in troubleshooting: ckaaaa.txt: Overview, file naming conventions, list of files, etc. ckuins.txt: Installation instructions for UNIX C-Kermit. ckccfg.txt: C-Kermit program configuration information. ckcbwr.txt: C-Kermit "beware file" for all platforms. ckubwr.txt: C-Kermit "beware file" for UNIX (this file). ckcplm.txt: C-Kermit program logic manual. ckermit2.txt: User documentation for features added since 6.0.192, and since the 2nd Edition of "Using C-Kermit" was published. ckcXXX.txt: Program edit history for edit XXX, e.g. ckc196.txt. ckuker.mak: (or makefile) Makefile for UNIX C-Kermit. ck[cuw]*.[chw]: Source code for UNIX C-Kermit. Note that all of the *.txt files are renamed from their pre-7.0 names due to Microsoft's usurpation of traditional text filetypes like .hlp and .doc for its own purposes. (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, because as soon as you update the libraries on your system, they no longer match the ones referenced in the binary, and the binary refuses to load when you run it, in which case you'll see error messages similar to: Could not load program kermit Member shr4.o not found or file not an archive Could not load library libcurses.a[shr4.o] Error was: No such file or directory (These samples are from AIX.) To avoid this problem, we try to build C-Kermit with statically linked libraries whenever we can, but many of the binaries are contributed from elsewhere (after all, we don't have several hundred different machines in-house to build them on), and in any case some platforms do not even offer the option of static linking. 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. Sometimes even the system-or-library patch/ECO level makes a difference. A particularly insidious problem occurs when a binary was built on a version of the OS that has patches from the vendor (e.g. to libraries); in most cases you won't be able to run such a binary on an unpatched version of the same platform. 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 find somebody who will build one for you. (3) NOTES ON SPECIFIC UNIX VERSIONS The following sections apply to specific UNIX versions. One thread that runs through many of them, and implicitly perhaps through all, concerns the problems that occur when trying to dial out on a serial device that is (also) enabled for dialing in. The "solutions" to this problem are many, varied, diverse, and usually gross, involving configuring the device for bidirectional use. This is done in a highly system-dependent and often obscure manner, and the effects (good or evil) are also highly system- dependent. Many examples are given in the system-specific sections below. An important point to keep in mind is that C-Kermit is a CROSS-PLATFORM, PORTABLE program. It was not designed specifically and only for your particular UNIX version, or for that matter, for UNIX in particular at all. It also runs on VMS, AOS/VS, VOS, and many other non-UNIX platforms. All the UNIX versions of C-Kermit share common i/o modules, with compile-time #ifdef constructions used to account for the differences among the many UNIX products and releases. If you think that C-Kermit is behaving badly, or missing something, on your particular UNIX version, you might be right -- we can't claim to be expert in 700+ different platforms. If you're a programmer, take a look at the source code and send us your suggested fixes or changes. Or else just send us a report about what seems to be wrong (see the TECHNICAL SUPPORT section above for details). (3.0) C-KERMIT ON PC-BASED UNIXES PCs are not the best platform for real operating systems like UNIX. The architecture suffers from numerous deficiencies, not the least of which is the stiflingly small number of hardware interrupts (either 7 or 15, most of which are preallocated). Thus adding devices, using multiple serial ports, etc, is always a challenge and usually a nightmare. The free-for-all nature of the PC market and the lack of standards combined with the diversity of UNIX OS versions makes it difficult to find drivers for any particular device on any particular version of UNIX. Of special interest to Kermit users is the fact that there is no standard provision in the PC architecture for more than 2 communication (serial) ports. COM3 and COM4 (or higher) will not work unless you (a) find out the hardware address and interrupt for each, (b) find out how to provide your UNIX version with this information, and (c) actually set up the configuration in the UNIX startup files (or whatever other method is used). Watch out for interrupt conflicts, and don't expect to be able to use more than two serial ports at the same time. Here is a typical tale from a Linux user (Fred Smith) about installing a third serial port: "...problems can come from a number of causes. The one I fought with for some time, and finally conquered, was that my modem is on an add-in serial port, cua3/IRQ5. By default IRQ5 has a very low priority, and does not get enough service in times when the system is busy to prevent losing data. This in turn causes many resends. There are two 'fixes' that I know of, one is to relax hard disk interrupt hogging by using the correct parameter to hdparm, but I don't like that one because the hdparm man page indicates it is risky to use. The other one, the one I used, was to get 'irqtune' and use it to give IRQ5 the highest priority instead of nearly the lowest. Completely cured the problem." To complicate matters, the PC platform is becoming increasingly and inexorably Windows-oriented. More and more add-on devices are "Windows only" -- meaning they are incomplete and rely on proprietary Windows-based software drivers to do the jobs that you would expect the device itself to do. PCMCIA or "Plug-n-Play" devices are rarely supported on PC-based UNIX versions such as SCO; Winmodems, Winprinters, and the like are not supported at all on any UNIX to our knowledge (except Lucent has released a Linux-only driver for one of its PCI "software" modems). The self-proclaimed Microsoft PC 97 (or later) standard will probably only make matters worse since its only purpose to ensure that PCs are "optimized to run Windows 95 and Windows NT 4.0 and future versions of these operating systems". With the exception noted (the Lucent modem), drivers for "Win" devices are available only for Windows, since the Windows market dwarfs that of any particular UNIX brand, and for that matter all UNIXes (or for that matter, all non-Windows operating systems) combined. If your version of UNIX (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular device, then C-Kermit can't use it either. C-Kermit, like any UNIX application, must access all devices through drivers and not directly. Don't waste time thinking that you, or anybody else, could write a Linux (or other UNIX) driver for a Winmodem or other "Win" device. First of all, these devices generally require realtime control, but since UNIX (unlike Windows) is a true multitasking system, realtime device control is not possible outside the kernel. Second, the specifications for these devices are secret and proprietary, and each one (and each version of each one) is potentially different. Third, a Winmodem driver would be enormously complex; it would take years to write and debug, by which time it would be obsolete. Before you buy a new PC or add-on equipment, especially serial ports, internal modems, or printers, make sure they are compatible with your version of UNIX. This is becoming an ever-greater challenge; only a huge company like Microsoft can afford to be constantly cranking out and/or verifying drivers for the thousands of video boards, sound cards, network adapters, SCSI adapters, buses, etc, that spew forth in an uncontrolled manner from all corners of the world on a daily basis. With very few exceptions, makers of PCs assemble the various components and then verify them only with Windows, which they must do since they are, no doubt, preloading the PC with Windows. To find a modern PC that is capable of running a variety of non-Windows operating systems (e.g. Linux, SCO OpenServer, Unixware, and Solaris) is a formidable challenge requiring careful study of each vendor's "compatibility lists" and precise attention to exact component model numbers and revision levels. Modems: External modems are recommended. Internal PC modems (even when they are not Winmodems, which is increasingly unlikely in new PCs) are always trouble, especially in UNIX. Even when they work for dialing out, they might not work for dialing in, etc. Problems that occur when using an internal modem can almost always be eliminated by switching to an external one. Even when an internal modem is not a Winmodem or Plug-n-Play, it is often a no-name model of unknown quality -- not the sort of thing you want sitting directly on your computer's bus. (Even if it does not cause hardware problems, it probably came without a command list, so no UNIX software will know how to control it.) For more about UNIX compatible modems, see: http://www.o2.net/~gromitkc/winmodem.html Multiple modems: Remember that PCs, even now -- 2 decades after the PC was first introduced -- are not (in general) capable of supporting more than 2 serial devices. Here's a short success story from a recent newsgroup posting: "I have a Diamond SupraSonic II dual modem in my machine. What I had to end up doing is buying a PS/2 mouse and port and install it. Had to get rid of my serial mouse. I also had to disable PnP in my computer bios. I was having IRQ conflicts between my serial mouse and "com 3". Both modems work fine for me. My first modem is ttyS0 and my second is ttyS1." Special third-party multiport boards such as DigiBoard are available for certain UNIX platforms (typically SCO, maybe Linux) that come with special platform-specific drivers. Character sets: PCs generally have PC code pages such as CP437 or CP850, and these are often used by PC-based UNIX operating systems, particularly on the console. These are supported directly by C-Kermit's SET FILE CHARACTER-SET and SET TERMINAL CHARACTER-SET commands. Some PC-based UNIX versions, such as recent Red Hat Linux releases, might also support Microsoft Windows code pages such as CP1252, or even Latin Alphabet 1 itself (perhaps displayed with CP437 glyphs). Certain Windows code pages are not supported directly by C-Kermit, but since they are ISO Latin Alphabets with nonstandard "extensions" in the C1 control range, you can substitute the corresponding Latin alphabet (or other character set) in any C-Kermit character-set related commands: Windows Code Page Substitution CP 1004 Latin-1 CP 1051 HP Roman-8 Other Windows code pages are mostly (or totally) incompatible with their Latin Alphabet counterparts (e.g. CP1250 and Latin-2), but several of these are supported by C-Kermit 7.0 (1250, 1251, and 1252). Finally, note that as a real operating system, UNIX (unlike Windows) does not provide the intimate connection to the PC keyboard, screen, and mouse that you might expect. UNIX applications can not "see" the keyboard, and therefore can not be programmed to understand F-keys, Editing keys, Alt-key combinations, and the like. This is because (a) UNIX is a portable operating system, not only for PCs; and (b) UNIX sessions can come from anywhere, not just the PC's keyboard and screen. (3.1) C-KERMIT AND AIX For additional information see the AIX FAQ: http://www.emerson.emory.edu/services/aix-faq/ http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html http://aixpdslib.seas.ucla.edu/ ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1 ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix and/or read the comp.unix.aix newsgroup. C-Kermit won't be able to "set line /dev/tty0" (or any other dialout device) if you haven't installed "cu" or "uucp" on your system, because installing these is what creates the UUCP lockfile directory. If SET LINE commands always result in "Sorry, access to lock denied", even when C-Kermit has been given the same owner, group, and permissions as cu: -r-sr-xr-x 1 uucp uucp 67216 Jul 27 1999 cu and even when you run it as root, then you must go back and install "cu" from your AIX installation media. Streaming transfers into AIX 4.2 or 4.3 (through the AIX Telnet server) have been observed to fail, when exactly the same kind of transfers into AIX 4.1 work without incident. The error reported by AIX is "interrupted system call". Streaming transfers work perfectly, however, if the AIX Telnet server is removed from the picture (e.g, by using "set host * 3000" on AIX, or by using Rlogin instead of Telnet). They also work perfectly if the Telnet connection is forced into binary mode (C-Kermit command "set telopt requested requested"). In case of file-transfer failure on a Telnet connection to AIX 4.2 or 4.3, tell AIX C-Kermit to "set streaming off" and/or tell the file sender to prefix all control characters ("set prefixing all"). Also be sure that the AIX C-Kermit on the remote end has "set flow none" (which is the default). About AIX version numbers: "uname -a" tells the two-digit version number, such as 3.2 or 4.1. The three-digit form can be seen with the "oslevel" command (this information is unavailable at the API level and is reportedly obtained by scanning the installed patch list). Supposedly all three-digit versions within the same two-digit version (e.g. 4.3.1, 4.3.2) are binary compatible; i.e. a binary built on any one of them should run on all others, but this is not verified. IMPORTANT: Do NOT try to run AIX 3.x C-Kermit binaries on AIX 4.x (or vice versa). Obtain -- or build -- the C-Kermit binary that is appropriate for your AIX version. In general, it is always better to build from source code. According to IBM's "From Strength to Strength" document (21 April 1998), in AIX 4.2 and later "Async supports speeds on native serial ports up to 115.2kbps". However, no API is documented to achieve serial speeds higher than 38400 bps. Apparently the way to do this -- which might or might not work only on the IBM 128-port multiplexer -- is: cxma-stty fastbaud /dev/tty0 which, according to "man cxma-stty": fastbaud Alters the baud rate table, so 50 baud becomes 57600 baud. -fastbaud Restores the baud rate table, so 57600 baud becomes 50 baud. Presumably (but not certainly) this extrapolates to 110 "baud" becomes 76800 bps, and 150 becomes 115200 bps. So to use high serial speeds in AIX 4.2 or 4.3, the trick would be to give the "cxma-stty fastbaud" command for the desired tty device before starting Kermit, and then use "set speed 50", "set speed 110", or "set speed 150" to select 56700, 76800, or 115200 bps. It is not known whether cxma-stty requires privilege. According to one report, "Further investigation with IBM seems to indicate that the only hardware capable of doing this is the 128-port multiplexor with one (or more) of the 16 port breakout cables (Enhanced Remote Async Node 16-Port EIA-232). We are looking at about CDN$4,000 in hardware just to hang a 56kb modem on there. Of course, we can then hang 15 more, if we want. This hardware combo is described to be good to 230.4kbps." Another report says (quote from AIX newsgroup, March 1999): The machine type and the adapter determine the speed that one can actually run at. The older microchannel machines have much slower crystal frequencies and may not go beyond 76,800. A feature put into AIX 421 allows one to key in non-POSIX baud rates and if the uart can support that speed, it will get set. this applies also to 43p's and beyond. 115200 is the max for the 43P's native serial port. As crytal frequencies continue to increase, the built-in serial ports speeds will improve. To use 'uucp' or 'ate' at the higher baud rates, configure the port for the desired speed, but set the speed of uucp or ate to 50. Any non-POSIX speeds set in the ttys configuration will the be used. In the case of the 128-port adapters or the ISA 8-port or PCI 8-port adapter, there are only a few higher baud rates. a. Change the port to enable high baud rates: B50 for 57600 B75 for 76800 B110 for 115200 B200 for 230000 b. chdev -l ttyX -a fastbaud=enable For the 128 ports original style rans, only 57600 bps is supported. For the new enhanced RANs, up to 230Kbps is supported. (end quote) Note that some RS/6000s (e.g. the IBM PowerServer 320) have nonstandard rectangular 10-pin serial ports; the DB-25 connector is NOT a serial port; it is a parallel printer port. IBM cables are required for the serial ports, (The IBM RT PC also had rectangular serial ports -- perhaps the same as these, perhaps different.) If you dial in to AIX through a modem that is connected directly to an AIX port (e.g. on the 128-port multiplexer) and find that data is lost, especially when uploading files to the AIX system (and system error logs report buffer overruns on the port): 1. Make sure the port and modem are BOTH configured for hardware (RTS/CTS) flow control. The port is configured somewhere in the system configuration, outside of Kermit. 2. Tell C-Kermit to "set flow keep"; experimentation shows that SET FLOW RTS/CTS has no effect when used in remote mode (i.e. on /dev/tty, as opposed to a specify port device). Several people have reported that C-Kermit (version unspecified) causes AIX 4.2 (or later) to "freeze" or "hang" or "halt". No further details are known at this time. However: 1. No user-mode application should ever be able to make AIX or any other version of UNIX freeze, hang, or halt; if it does, this indicates a serious bug in AIX, which should be reported immediately to IBM. 2. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support and other AIX bugs are available from IBM at: http://service.software.ibm.com/rs6000/ Downloads -> Software Fixes -> Download FixDist gets an application for looking up known problems. Other people have reported that after upgrading AIX from 4.1 to 4.2, the "ttys hang" when they try to use Kermit. Again, so far no further details are available. However, others report that C-Kermit 6.0 works fine on both AIX 4.2 and 4.3 if it is rebuilt from source code. Still others report that the original C-Kermit 6.0 binaries, built under AIX 4.1, work perfectly in AIX 4.2 and 4.3. More recently, people have reported various kinds of problems running a C-Kermit binary built under AIX 4.1 or 4.2 on AIX 4.3. There has been some speculation on the newsgroups about a new round binary incompatibility between AIX 4.3 and earlier versions -- some even suggest renumbered syscalls, but that seems unlikely. Example: a user in Germany reported that the C-Kermit 6.0 AIX 4.1 binary would crash during file transfer when run on AIX 4.2, but the problems disappeared when running a binary that was built on AIX 4.2. C-Kermit 6.0.192 and earlier were built by default without "BIGBUFOK" defined for AIX, and this limits the maximum size of macros, etc. In particular, it affects the alphanumeric page macro (TAPMSG) distributed with C-Kermit 6.0. BIGBUFOK should be defined, and it is in C-Kermit 6.1 and later. In the meantime use: make clean ; make aix??? KFLAGS=-DBIGBUFOK Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports does not work unless the port number is in the /etc/services file; it's not clear from the report whether this is a problem with AIX Telnet (in which case it would not affect Kermit), or with the sockets library (in which case it would). The purported fix is IBM APAR IX61523. 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 a shell-script wrapper for Kermit 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 and later.) The commands for turning getty off and on (respectively) are /usr/sbin/pdisable and /usr/sbin/penable. 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). This should not be an issue in C-Kermit 7.0 or later, which now calls the AIX ttlock() family of library functions to create, check, and remove lockfiles. (But it is not known which versions of AIX prior to 4.1 have working ttlock() functions; for example, the functions are present in AIX 3.2 but do not seem to work). C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to another 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 seems to be removed in AIX 3.2 and later. 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 anything 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) About AIX versions and hardware platforms (from the AIX FAQ): If you are using IBM's xlc (cc) compiler, the default is to use the common instruction set, so the same binary will run on both RS/6000 and PowerPC. The option -mcpu=common makes GCC use the common instruction set. Please note that (unlike xlc) this is *not* the default with GCC on AIX. A couple of other gotcha's: Use shared libraries. The C runtime can and does change as IBM introduces patches. Also this avoids "Netscape syndrome." They bound AIX 3 libraries into their browser. Although AIX 3 binaries will run on AIX 4, the AIX 3 libraries aren't totally compatible. AIX 4.2 changed the C runtime radically. AIX 4.2 binaries won't run on AIX 4.1 or 3.anything. AIX 3 binaries run on AIX 4.1 and AIX 4.2. Of course, the moment you take any of this as gospel, you'll get into big trouble, but my own experience has pretty much jibed with the above. (end quote) "Is AIX Year 2000 Compliant?" According to a comp.unix.aix newsgroup posting from IBM Austin, version 4.2 is; earlier versions such as 4.1.x and 3.2.5 require PTFs (which, as of Jan 1997, have not yet been issued). Here is a sample configuration for setting up an xterm keyboard for VT220 or higher terminal emulation on AIX, courtesy of Bruce Momjian, Drexel Hill, PA. Xterm can be started like this: xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220 \ -title vt220 -tn xterm-220 "$@" & --------------------------------------------------------------------------- XTerm*VT100.Translations: #override \n\ Home: string(0x1b) string("[3~") \n \ End: string(0x1b) string("[4~") \n vt220*VT100.Translations: #override \n\ Shift F1: string("[23~") \n \ Shift F2: string("[24~") \n \ Shift F3: string("[25~") \n \ Shift F4: string("[26~") \n \ Shift F5: string("~") \n \ Shift F6: string("[31~") \n \ Shift F7: string("[31~") \n \ Shift F8: string("[32~") \n \ Shift F9: string("[33~") \n \ Shift F10: string("[34~") \n \ Shift F11: string("[28~") \n \ Shift F12: string("[29~") \n \ Print: string(0x1b) string("[32~") \n\ Cancel: string(0x1b) string("[33~") \n\ Pause: string(0x1b) string("[34~") \n\ Insert: string(0x1b) string("[2~") \n\ Delete: string(0x1b) string("[3~") \n\ Home: string(0x1b) string("[1~") \n\ End: string(0x1b) string("[4~") \n\ Prior: string(0x1b) string("[5~") \n\ Next: string(0x1b) string("[6~") \n\ BackSpace: string(0x7f) \n\ Num_Lock: string(0x1b) string("OP") \n\ KP_Divide: string(0x1b) string("Ol") \n\ KP_Multiply: string(0x1b) string("Om") \n\ KP_Subtract: string(0x1b) string("OS") \n\ KP_Add: string(0x1b) string("OM") \n\ KP_Enter: string(0x1b) string("OM") \n\ KP_Decimal: string(0x1b) string("On") \n\ KP_0: string(0x1b) string("Op") \n\ KP_1: string(0x1b) string("Oq") \n\ KP_2: string(0x1b) string("Or") \n\ KP_3: string(0x1b) string("Os") \n\ KP_4: string(0x1b) string("Ot") \n\ KP_5: string(0x1b) string("Ou") \n\ KP_6: string(0x1b) string("Ov") \n\ KP_7: string(0x1b) string("Ow") \n\ KP_8: string(0x1b) string("Ox") \n\ KP_9: string(0x1b) string("Oy") \n ! Up: string(0x1b) string("[A") \n\ ! Down: string(0x1b) string("[B") \n\ ! Right: string(0x1b) string("[C") \n\ ! Left: string(0x1b) string("[D") \n\ *visualBell: true *saveLines: 1000 *cursesemul: true *scrollKey: true *scrollBar: true (3.2) C-KERMIT AND HP-UX For further information, read the comp.sys.hp.hpux newsgroup. 3.2.0. Common Problems The following sequence: set line /dev/cua0p0 ; or other device set speed 19200 ; or other normal speed produces the message "?Unsupported line speed". This means the port is not configured for dialout. Go into SAM and configure the port for dialout. Some HP workstations have a BREAK/RESET key. If you hit this key while C-Kermit is running, it might kill or suspend the C-Kermit process. C-Kermit arms itself against these signals, but evidently the BREAK/RESET key is -- at least in some circumstances, on certain HP-UX versions -- too powerful to be caught. (Some report that the first BREAK/RESET shows up as SIGINT and is caught by C-Kermit's *former* SIGINT handler even when SIGINT is currently set to SIG_IGN; the second kills Kermit; other reports suggest the first BREAK/RESET sends a SIGTSTP (suspend) signal to Kermit, which it catches and suspends itself.) You can tell C-Kermit to ignore suspend signals with SET SUSPEND OFF. You can tell C-Kermit to ignore SIGINT with SET COMMAND INTERRUPTION OFF. It is not known whether these commands also grant immunity to the BREAK/RESET key (one report states that with SET SUSPEND OFF, the BREAK/RESET key is ignored the first four times, but kills Kermit the 5th time). In any case: 1. If this key is mapped to SIGINT or SIGTSTP, C-Kermit catches or ignores it, depending on which mode (CONNECT, command, etc) Kermit is in. 2. If it causes HP-UX to kill C-Kermit, there is nothing C-Kermit can do to prevent it. When HP-UX is on the remote end of the connection, it is essential that HP-UX C-Kermit be configured for Xon/Xoff flow control (this is the default, but in case you change it and then experience file-transfer failures, this is a likely reason). 3.2.1. Building C-Kermit on 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. In versions 6.1 and 7.0 the problem has spread to other modules. 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. This problem is handled by compiling the modules that tickle it without optimization; the new C-Kermit makefile takes care of this, and shows how to do it in case the same thing begins happening with other modules. 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. The optimizing compiler might complain about "some optimizations skipped" on certain modules, due to lack of space available to the optimizer. You can 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 :-) In the C-Kermit 7.0 makefile, all HP-UX entries automatically skip optimization of problematic modules. 3.2.2. 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. C-Kermit 6.0 was used; the situation is slightly better using C-Kermit 7.0's streaming feature. 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, packet length 4096, parity none, control prefixing "cautious", using only local disks on each machine -- no NFS. In the C-Kermit 6.0 (ACK/NAK) case, the window size was 20; in the streaming case there is no window size. The test file was C-Kermit executable, transferred in binary mode. Conditions were relatively poor: the Sun and the local net heavily loaded; the HP system is old, slow, and memory-constrained. C-Kermit 6.0... C-Kermit 7.0... Local Remote ACK/NAK........ Streaming...... Client Server Send Receive Send Receive Sun HP 36 18 64 18 HP HP 25 15 37 16 HP Sun 77 83 118 92 Sun Sun 60 60 153 158 So whenever HP is the remote we have poor 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 little effect. . Telling the client to make a binary-mode connection (SET TELNET BINARY REQUESTED, which successfully negotiates a binary connection) has no effect on throughput. 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: C-Kermit 6.0... C-Kermit 7.0... Local Remote ACK/NAK........ Streaming...... Client Server Send Receive Send Receive Sun HP 77 67 106 139 HP HP 50 50 64 62 HP Sun 57 85 155 105 Sun Sun 57 50 321 314 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 little Kermit can do improve matters, since the telnet server and pty driver are between the two Kermits, and neither Kermit program can have any influence over them (except putting the Telnet connection in binary mode, but that doesn't help). (The numbers for the HP-HP transfers are lower than the others since both Kermit processes are running on the same slow CPU.) 3.2.3. Dialing Out and UUCP Lockfiles in HP-UX 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 began to change. The older names looked like "/dev/cua00", "/dev/tty01", etc (sometimes with only one digit). The newer names have two digits with the letter "p" in between. HP-UX 8.xx and earlier have the older form, HP-UX 10.00 and later have the newer form. HP-UX 9.xx has the newer form on Series 800 machines, and the older form on other hardware models. The situation is summarized in the following table: Converged HP-UX Serial I/O Filenames : TTY Mux Naming --------------------------------------------------------------------- General meaning Old Form S800 9.0 Convio 10.0 --------------------------------------------------------------------- tty* hardwired ports tty ttyp ttyp

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

diag:ttydp diag:ttydp

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

diag:cuap --------------------------------------------------------------------- cul* dial-out cul culp 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 should 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 should be 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: /var/spool/locks (HP-UX 10.00 and later) /usr/spool/uucp (HP-UX 9.xx and earlier) 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 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 (in HP-UX 10.00 and later) by the letter "p" (lowercase), followed by another string of decimal digits (the port number on the interface), e.g.: "0p0", "0p1", "1p0", etc (HP-UX 10.00 and later) "0p0", "0p1", "1p0", etc (HP-UX 9.xx on Series 800) "00", "01", "10", "0", etc (HP-UX 9.xx not on Series 800) "00", "01", "10", "0", etc (HP-UX 8.xx and earlier) Then a normal serial device (driver) name consists of a prefix ("tty", "ttyd", "cua", "cul", or possibly "cuad" or "culd") 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 /dev/cuad0p0 LCK..cuad0p0 LCK..ttyd0p0 /dev/culd0p0 LCK..culd0p0 LCK..ttyd0p0 LCK.. (none) (* = Dialin device, should not be used.) In other words, if the device name begins with "cu", a second lockfile for the "ttyd" device, same unit, is created, which should prevent dialin access on that device. The 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 C-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 LCK..cul2p3 LCK..cuad2p3 LCK..culd2p3 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 six messages are printed telling the user which "stale lockfiles" are being removed. When the "set line" command succeeds in HP-UX 10.00 and later, C-Kermit also creates a UNIX System V R4 "advisory lock" as a further precaution (but not guarantee) against any other process obtaining access to the device while you are using it. 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. The behavior of cu and other communication programs under these conditions should be the same. 3.2.4. HP-UX 5.00 The HP-UX 5.00 version of C-Kermit does not include the fullscreen file-transfer because of problems with the curses library. If HP-UX 5.21 with Wollongong TCP/IP is on the remote end of a Telnet connection, streaming transfers to HP-UX invariably fail. Workaround: SET STREAMING OFF. Packets longer than about 1000 should not be used. Transfers from these systems, however, can use streaming and/or longer packets. 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." (This report predates C-Kermit 6.0 and might no longer apply.) 3.2.5. HP-UX 8.00 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. And this report just in: "On HP-UX 8 DON'T install 'tty patch' PHKL_4656, install PHKL_3047 instead! Yesterday I tried this latest tty patch PHKL_4656 and had terrible problems. This patch should fix RTS/CTS problems. With text transver all looks nice. But when I switched over to binary files the serial interface returned only rubish to C-Kermit. All sorts of protocol, CRC and packed errors I had. After several tests and after uninstalling that patch, all transvers worked fine. MB's of data without any errors. So keep your fingers away from that patch. If anybody needs the PHKL_3047 patch I have it here. It is no longer availabel from HP's patch base." 3.2.6. HP-UX 9.00 AND LATER HP-UX 9.00 and 9.01 need patch PHNE_10572 (note: this replaces 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". (There are also equivalent patches for s700 9.03 9.05 9.07 (PHNE_10573) and s800 9.00 9.04 (PHNE_10416). When C-Kermit is in server mode, it might have trouble executing REMOTE HOST commands. This problem happens under HP-UX 9.00 (Motorola) and HP-UX 9.01 (RISC) IF the C-Shell is the login shell AND with the C-Shell Revision 70.15. Best thing is to install HP's Patch PHCO_4919 for Series 300/400 and PHCO_5015 for the Series 700/800. PHCO_5015 is called "s700_800 9.X cumulative csh(1) patch with memory leak fix" which works for HP-UX 9.00, 9.01, 9.03, 9.04, 9.05 and 9.07. At least you need C-Shell Revision 72.12! 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. 3.2.7. HP-UX 10.10 AND LATER C-Kermit is included as part of the HP-UX operating system by contract between Hewlett Packard and Columbia University for all HP-UX releases 10.00 and later. Each level of HP-UX 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 / 11.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.01, 10.10, 10.20, 10.30, or 11.00. If there is a version mismatch, HP-UX (not Kermit) is very likely to do something like "Invalid version for shared lib /usr/lib/libc.1, IOT trap (core dumped)" during program load. 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.2.8. HP-UX and X.25 Although C-Kermit presently does not include built-in support for HP-UX X.25 (as it does for the Sun and IBM X.25 products), it can still be used to make X.25 connections as follows: start Kermit and then telnet to localhost. After logging back in, start padem as you would normally do to connect over X.25. Padem acts as a pipe between Kermit and X.25. In C-Kermit 7.0, you might also be able to avoid the "telnet localhost" step by using: C-Kermit> pty padem

This will work if padem uses standard i/o (see Section 2.7 of ckermit2.txt). (3.3) C-KERMIT AND LINUX For further information, read the comp.os.linux.misc, comp.os.linux.answers, and other Linux-oriented newsgroups, and: The Linux Document Project (LDP): . http://sunsite.unc.edu/LDP/ The Linux FAQ: . http://sunsite.unc.edu/LDP/FAQ/Linux-FAQ.html The Linux HOWTOs (especially the Serial HOWTO): . http://sunsite.unc.edu/LDP/HOWTO/Serial-HOWTO.html . ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO . ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO . http://sunsite.unc.edu/LDP/HOWTO/ . http://sunsite.unc.edu/LDP/hmirrors.html Also see general comments on PC-based UNIXes in Section 3.0. Did you know: DECnet is available for Linux? See: http://linux.dreamtime.org/decnet/ (But there is no support for it in C-Kermit -- anybody interested in adding it, please let me know.) Before proceeding, let's handle the two most frequently asked question in the Linux newsgroups: 1. Neither C-Kermit not any other Linux application can use Winmodems (with one exception). See section 3.0 for details. 2. "Why does it take such a long time to make a telnet connection to (or from) my Linux PC?" (this applies to C-Kermit or to regular Telnet). Most telnet servers these days perform reverse DNS lookups on the client (for security and/or logging reasons). If the Telnet client cannot be found by the local DNS server, the DNS request goes out to the Internet at large, and this can take quite some time. The solution to this problem is to make sure that both client and host are registered in DNS. C-Kermit itself performs reverse DNS lookups unless you tell it not to. This is to allow C-Kermit to let you know which host it is actually connected to in case you have made a connection to a "host pool" (multihomed host). You can disable C-Kermit's reverse DNS lookup with SET TCP REVERSE-DNS-LOOKUP OFF. 3.3.1. Problems Building C-Kermit for Linux Modern Linux distributions like Red Hat give you a choice at installation whether to include "developer tools". Obviously, you can't build C-Kermit or any other C program from source code if you have not installed the developer tools. Note that you might also have to choose (separately) to install the "curses" or "ncurses" terminal control library -- it is possible to install the C compiler and linker, but omit the (n)curses library and headers. If curses is not installed, you will not be able to build a version of C-Kermit that supports the fullscreen file-transfer display, in which case you'll need to use the "linuxnc" makefile target (nc = No Curses) or else install ncurses before building. 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? Other vexing questions involve libc5 vs libc6 vs glibc vs glibc2 (C libraries), gcc vs egcs vs lcc (compilers), plus using or avoiding features that were added in a certain version of Linux or a library or a distribution, and are not available in others. Linux C-Kermit, like all other UNIX C-Kermit versions, was built traditionally with curses.h and the curses library. However, this library was evidently so buggy (users reported that, after doing a file transfer using the fullscreen display, "screen scrolling locks up" and the cursor "is stuck on the bottom of the screen", etc), that a new curses library, called ncurses, was developed to replace it. C-Kermit, as of version 6.1, uses ncurses rather than curses. After modern practice, ncurses is dynamically linked, rather than linked into the executable. This means a certain relationship must obtain between the version number referenced in the executable and the version number of the library. But there are evidently several different numbering systems for libncurses.so -- e.g. 1.9.9e is another "name" for 3.0 -- but the program loader doesn't know that and so won't run the program. Also the library and/or terminfo database might be in a different place on the target system (e.g. /usr/share/terminfo) than it was on the build system (e.g. /usr/lib/terminfo). Solution: Create the appropriate symbolic links and/or rebuild C-Kermit yourself from source code, and if you have additional trouble, come back and read the rest of this section. Of course static linking is also a possibility, but this makes the executable MUCH bigger and introduces new problems of its own. From the March 1999 Kermit newsgroup traffic: : When I start Kermit (under Redhat Linux 5.2), it complains about not : being able to recognise my terminal type - I've tried all the obvious : terminal types - which ones can I use? Or can I get it to recognise : xterm? : Assuming that you can use full screen programs, this looks identical to the problem introduced by RedHat with 5.1. They moved the curses library, and didn't [ leave a link from the old location to the new one ]: To fix: cd /usr/share; ln -s terminfo ../lib The termcap library is no longer referenced in the Linux target in the makefile, since its functions are supposedly incorporated into the ncurses and curses libraries. However, should any termcap-related entry points come up undefined at link time (_tgetent, _tgoto, _tputs, etc), it might be necessary to add -ltermcap back to LIBS. But then you might find that the termcap library is not in /usr/lib after all, but has been moved to /usr/lib/termcap/, in which case you'll need to make a symlink, or do something like: "LIBS = -L/usr/lib/curses -lcurses -L/usr/lib/termcap -ltermcap" Different UUCP lockfile conventions are used by different Linux versions and/or distributions. In C-Kermit 6.0 and later, "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. One user reported problems building C-Kermit under Linux 2.0.30/Slackware 96, errors like: /usr/include/linux/socket.h:77: warning: `PF_AAL5' redefined /usr/local/include/socketbits.h:68: warning: this is the location of the previous definition ckutio.c:4679: `TIOCGSERIAL' undeclared (first use this function) ckutio.c:4685: `TIOCSSERIAL' undeclared (first use this function) ckutio.c:6092: warning: passing arg 3 of `select' from incompatible pointer type etc etc. Diagnosis: These were caused by installing some other package, which created files in /usr/local/include. Cure: rm -rf /usr/local/include, and start over. Reportedly, building C-Kermit 6.0 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. (Also, C-Kermit 6.1 and later should be OK since we no longer include kernel header files.) 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. (This problem is evidently fixed in more recent gcc releases.) 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). There is evidently a minor problem with GCC (version unknown) on (64-bit) Alpha platforms, in which it complains: warning: cast to pointer from integer of different size whenever it encounters a legitimate trinary expression like: integer ? "string1" : "string2" (The "integer" can also be an integer-valued expression.) These warnings appear to be harmless. 3.3.2. Problems with Serial Devices in Linux Also see: "man setserial", "man irqtune". And: Sections 3.0, 6, 7, and 8 of this document. Don't expect it to be easy. Queries like the following are posted to the Linux newsgroups almost daily: Problem of a major kind with my Compaq Presario 1805 in the sense that the pnpdump doesn't find the modem and the configuration tells me that the modem is busy when I set everything by hand! I have , kernel 2.0.35. Using the Compaq tells me that the modem (which is internal) is on COM2, with the usual IRQ and port numbers. Running various Windows diagnostics show me AT-style commands exchanged so I have no reason to beleive that it is a Winmodem. Also, the diagnostics under Win98 tell me that I am talking to an NS 16550AN. [Editor's note: This does not necessarily mean it isn't a Winmodem.] Under Linux, no joy trying to talk to the modem on /dev/cua1 whether via. minicom, kppp, or chat. kppp at least tells me that tcgetattr() failed. Usage of setserial ("setserial /dev/cua1 port 0x2F8 irq 3 autoconfig" followed by "setserial -g /dev/cua1") tells me that the uart is 'unknown'. I have tried setting the UART manullay via. setserial to 16550A, 16550, and the other one (8550?) (I didn't try 16540). None of these manual settings resulted in any success. A look at past articles leads me to investigate PNP issues by calling pnpdump but pnpdump returns "no boards found". I have looked around on my BIOS (Phoenix) and there is not much evidence of it being PNP aware. However for what it calls "Serial port A", it offers a choice of Auto, Disabled or Manual settings (currently set to Auto), but using the BIOS interface I tried to change to 'manual' and saw the default settings offered to be were 0x3F8 and IRQ 4 (COM1). The BIOS menus did not give me any chance to configure COM2 or any "modem". I ended up not saving any BIOS changes in the course of my investigations. Can anybody suggest something else for me to try? (end quotes) Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the like (see cautions in Section 3.0). Linux supports Plug-n-Play devices to some degree via the isapnp and pnpdump programs; read the man pages for them. (If you don't have them, look on your installation CD for isapnptool or download it from sunsite or a sunsite mirror or other politically correct location). Even when you have a real serial port, always be wary of interrupt conflicts and similar PC hardware configuration issues: a PC is not a real computer like other UNIX workstations -- it is generally pieced together from whatever random components were the best bargain on the commodity market the week it was built. Once it's assembled and boxed, not even the manufacturer will remember what it's made of or how it was put together because they've moved on to a new model. Their job is to get it (barely) working with Windows; for Linux and other OS's you are on your own. "set line /dev/modem" or "set line /dev/ttyS2", etc, results in an error, "/dev/modem is not a tty". Cause unknown, but obviously a driver issue, not a Kermit one (Kermit uses "isatty()" to check that the device is a tty, so it knows it will be able to issue all the tty-related ioctl's on it, like setting the speed & flow control). Try a different name (i.e. driver) for the same port, e.g. "set line /dev/cua2" or whatever. "set modem type xxx" (where xxx is the name of a modem) followed by "set line /dev/modem" or "set line /dev/ttyS2", etc, hangs (but can be interrupted with Ctrl-C). Experimentation shows that if the modem is configured to always assert carrier (&C0) the same command does not hang. Again, a driver issue. Use /dev/cua2 (or whatever) instead. (Or not -- hopefully none of these symptoms occur in C-Kermit 7.0.) "set line /dev/cua0" reports "Device is busy", but "set line /dev/ttyS0" works OK. In short: If the cua device doesn't work, try the corresponding ttyS device. If the ttyS device doesn't work, try the corresponding cua device -- but note that Linux developers do not recommend this, and are phasing out the cua devices. From /usr/doc/faq/howto/Serial-HOWTO: 12.4. What's The Real Difference Between The /dev/cuaN And /dev/ttySN Devices? The only difference is the way that the devices are opened. The dialin devices /dev/ttySN are opened in blocking mode, until CD is asserted (ie someone connects). So, when someone wants to use the /dev/cuaN device, there is no conflict with a program watching the /dev/ttySN device (unless someone is connected of course). The multiple /dev entries, allow operation of the same physical device with different operating characteristics. It also allows standard getty programs to coexist with any other serial program, without the getty being retrofitted with locking of some sort. It's especially useful since standard Unix kernel file locking, and UUCP locking are both advisory and not mandatory. It was discovered during development of C-Kermit 6.1 that rebuilding C-Kermit with -DNOCOTFMC (No Close/Open To Force Mode Change) made the aforementioned problem with /dev/ttyS0 go away. It is not yet clear, however, what its affect might be on the /dev/cua* devices. As of 19 March 1998, this option has been added to the CFLAGS in the makefile entries for Linux ("make linux"). Note that the cua device is now "deprecated", and new editions of Linux will phase it out in favor of the ttyS device. See: http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html One user reported that C-Kermit 7.0, when built with egcs 1.1.2 and run on Linux 2.2.6 with glibc 2.1 (hardware unknown but probably a PC) dumps core when given a "set line /dev/ttyS1" command. When rebuilt with gcc, it works fine. 3.3.3. Terminal Emulation in Linux Run C-Kermit in the regular console screen, which provides Linux Console "emulation" via the "console" termcap entry, or under X-Windows in an xterm window, which gives VTxxx emulation. An xterm that includes color ANSI and VT220 emulation is available with Xfree86: http://www.clark.net/pub/dickey/xterm/xterm.faq.html Before starting C-Kermit in an xterm window, you might need to tell the xterm window's shell to "stty sane". 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 (if it doesn't already), 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. Console-mode keys are mapped separately using loadkeys, and different keycodes are used. Find out what they are with showkey. 3.3.4. Dates and Times If C-Kermit's date-time (e.g. as shown by its DATE command) differs from the system's date and time: a. Make sure the libc to which Kermit is linked is set to GMT or is not set to any time zone. Watch out for mixed libc5/libc6 systems; each must be set indpendently. b. If you have changed your TZ environment variable, make sure it is exported. This is normally done in /etc/profile or /etc/TZ. 3.3.5. Startup Errors C-Kermit 7.0 should work on all versions of Linux current through December 1999, provided it was built on the same version you have (just get the source code and "make linux"). This is no guarantee that binaries built for 7.0 release will not stop working at a later date, since Linux tends to change out from under its applications, just as it did under C-Kermit 6.0 (libc/glibc, curses/ncurses, etc). Since the Red Hat 5.1 release (circa August 1998), there have been numerous reports of prebuilt Linux executables, and particularly the Kermit RPM for Red Hat Linux, not working; either it won't start at all, or it gives error messages about "terminal type unknown" and refuses to initialize its curses support. The following is from the Kermit newsgroup: From: rchandra@hal9000.buf.servtech.com () Newsgroups: comp.protocols.kermit.misc Subject: Red Hat Linux/Intel 5.1 and ncurses: suggestions Date: 22 Aug 1998 15:54:46 GMT Organization: Verio New York Keywords: RedHat RPM 5.1 Several factors can influence whether "linux" is recognized as a terminal type on many Linux systems. 1.) Your program, or the libraries it linked with (if statically linked), or the libraries it dynamically links with at runtime, are looking for an entry in /etc/termcap that isn't there. (not likely, but possible...I believe but am not certain that this is a very old practice in very old [n]curses library implementations to use a single file for all terminal descriptions.) 2.) Your program, or the libraries...are looking for a terminfo file that just plain isn't there. (also not so likely, since many people in other recent message threads said that other programs work OK). 3.) Your program, or the libraries...are looking for a terminfo file that is stored at a pathname that isn't expected by your program, the libraries--and so on. I forgot if I read this in the errata Web page or where exactly I discovered this (Netscape install? Acrobat install?), but it may just be that one libc (let's say for sake of argument, libc5, but I don't know this to be true) expects your terminfo to be in /usr/share/terminfo, and the other (let's say libc6/glibc) expects /usr/lib/terminfo. I remember that the specific instructions in this bugfix/workaround were to do the following or equivalent: cd /usr/lib ln -s ../share/terminfo ./terminfo - or - ln -s /usr/share/terminfo /usr/lib/terminfo So what this says is that the terminfo database/directory structure can be accessed by either path. When something goes to reference /usr/lib/terminfo, the symlink redirects it to essentially /usr/share/terminfo, which is where it really resides on your system. I personally prefer wherever possible to use relative symlinks, because they still hold, more often than break, across mount points, particularly NFS mounts, where the directory structure may be different on the different systems. (end quote) Evidently the terminfo file moved between Red Hat 5.0 and 5.1, but Red Hat did not include a link to let applications built prior to 5.1 find it. Users report that installing the link fixes the problem. (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 See also: The comp.os.qnx newsgroup. 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 later, and verified to work in both 16-bit and 32-bit versions. The 16-bit version was dropped in C-Kermit 7.0 since it can no longer be built successfully (after stripping most most features, I succeeded in getting it to compile and link without complaint, but the executable just beeps when you run it); for 16-bit QNX 4.2x, use C-Kermit 6.0 or earlier. The 32-bit version (and the 16-bit version prior to C-Kermit 7.0) support most of C-Kermit's advanced features including TCP/IP, high serial speeds, hardware flow-control, modem-signal awareness, curses support, etc. BUG: In C-Kermit 6.0 and earlier on QNX 4.22 and earlier, the fullscreen file transfer display worked fine the first time, but was fractured on subsequent file transfers. Cause and cure unknown. In C-Kermit 7.0 and QNX 4.25, this no longer occurs. It is not known if it would occur in C-Kermit 7.0 on earlier QNX versions. 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.txt and make the necessary changes to the makefile entry (e.g. add -DHDBUUCP). QNX does, however, allow a program to get the device open count. This can not be a reliable form of locking unless all applications do it, so by default, Kermit uses this information only for printing a warning message such as: C-Kermit>set line /dev/ser1 WARNING - "/dev/ser1" looks busy... However, if you want to use it as a lock, you can do so with: SET QNX-PORT-LOCK { ON, OFF } This is OFF by default; if you set in ON, C-Kermit will fail to open any dialout device when its open count indicates that another process has it open. SHOW COMM (in QNX only) displays the setting, and if you have a port open, it also shows the open count. (3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER See also: . The comp.unix.sco.* newsgroups. . http://www.sco.com/Support/ssl.html . Section 3.10 below for Unixware . The FAQ at ftp://rtfm.mit.edu/pub/usenet/news.answers/sco/newsgroups-faq (which only covers newsgroups and mailing lists). There is a general SCO FAQ, but I'm not sure where to find it. It is posted to the newsgroups from time to time. Also see general comments on PC-based UNIXes in Section 3.0. Old Xenix versions... Did you know: Xenix 3.0 is *older* than Xenix 2.0? There is all sorts of confusion among SCO versions, particularly when third- party communications boards and drivers are installed, regarding lockfile naming conventions, as well as basic functionality. As far as lockfiles go, 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 :-) On the other hand, certain functions that might not (do not) work right or at all when using SCO drivers (e.g. high serial speeds, hardware flow control, and/or reading of modem signals) might work right when using third-party drivers. (Example: hardware flow control works, reportedly, only on uppercase device like tty1A -- not tty1a -- and only when CLOCAL is clear when using the SCO sio driver, but there are no such restrictions in, e.g., Digiboard drivers). SCO OpenServer (all versions up to and included 5.0.5) do not support the reading of modem signals. Thus "show comm" does not list modem signals, and C-Kermit does not automatically pop back to its prompt when the modem hangs up the connection (drops CD). The ioctl() call for this is simply not implmented, at least not in the standard drivers. One user reports that he can't transfer large files with C-Kermit under SCO OSR5.0.0 and 5.0.4 -- after the first 5K, everything falls apart. Same thing without Kermit -- e.g. with ftp over a PPP connection. Later, he said that replacing SCO's SIO driver with FAS, an alternative communications driver, made the problem go away: ftp://ftp.fu-berlin.de/pub/unix/driver/fas Other users often make similar observations regarding Digi and other 3rd party drivers. With regard to bidirectional serial ports on OpenServer 5.0.4, the following advice appeared on an SCO related newsgroup : "No amount of configuration information is going to help you on 5.0.4 unless it includes the kludge for the primary problem. With almost every modem, the 5.0.4 getty will barf messages and may or may not connect. There are 2 solutions and only one works on 5.0.4. Get the atdialer binary from a 5.0.0 system and substitute it for the native 5.0.4 atdialer. The other solution is to upgrade to 5.0.5. And, most of all, on any OpenServer products, do NOT run the badly broken Modem Manager. Configure the modems in the time honored way that dates back to Xenix." Hardware flow control is available in C-Kermit when the underlying SCO version supports it. Note that Xenix 2.3.0 and later claims to support RTSFLOW and CTSFLOW, but this is not modern bidirectional hardware flow control; rather it implements the original RS-232 meanings of these signals for unidirectional half-duplex line access: If both RTSFLOW and CTSFLOW bits are set, Xenix asserts RTS when it wants to send data and waits for CTS assertion before it actually starts sending data (also, reportedly, even this is broken in Xenix 2.3.0 and 2.3.1). 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 If a tty device is listed as an ACU in /usr/lib/uucp/Devices and is enabled, getty resets the ownership and permissions to uucp.uucp 640 every time the device is released. If you want to use the device only for dialout, and you want to specify other owners or permissions, you should disable it in /usr/lib/uucp/Devices; this will prevent getty from doing things to it. You should also changes the device's file modes in /etc/conf/node.d/sio by changing fields 5-7 for the desired device(s); this determines how the devices are set if you relink the kernel. SCO systems tend to use different names (i.e. drivers) 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). 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. One SCO user of C-Kermit 5A(190) reported that only one copy of Kermit can run at a time when a Stallion Technologies multiport boards are installed. Cause, cure, and present status unknown (see Section 14 of this file for more info regarding Stallion). Prior to SCO OpenServer 5.0.4, the highest serial port speed supported by SCO was 38400. However, in some SCO versions (e.g. OSR5) it is possible to map rarely-used lower speeds (like 600 and 1800) to higher ones like 57600 and 115200. To find out how, go to http://www.sco.com/ and search for "115200". In OSR5.0.4, serial speeds up to 921600 are supported through the POSIX interface; C-Kermit 6.1.193 or later, when built for OSR5.0.4, supports these speeds, but you might be able to run this binary on earlier releases to get the high serial speeds, depending on various factors, described by Bela Lubkin of SCO: Serial speeds under SCO Unix / Open Desktop / OpenServer ======================================================== Third party drivers (intelligent serial boards) may provide any speeds they desire; most support up to 115.2Kbps. SCO's "sio" driver, which is used to drive standard serial ports with 8250/16450/16550 and similar UARTs, was limited to 38400bps in older releases. Support for rates through 115.2Kbps was added in the following releases: SCO OpenServer Release 5.0.0 (requires supplement "rs40b") SCO OpenServer Release 5.0.2 (requires supplement "rs40a" or "rs40b") SCO OpenServer Release 5.0.4 or later SCO Internet FastStart Release 1.0.0 or later SCO supplements are at ftp://ftp.sco.com/; the "rs40" series are under directory /Supplements/internet (end quote) Reportedly, if you have a script that makes a TCP/IP SET HOST (e.g. Telnet) connection to SCO 3.2v4.2 with TCP/IP 1.2.1, and then does the following: script $ exit hangup this causes a pseudoterminal (pty) to be consumed on the SCO system; if you do it enough times, it will run out of ptys. An "exit" command is being sent to the SCO shell, and a HANGUP command is executed locally, so the chances are good that both sides are trying to close the connection at once, perhaps inducing a race condition in which the remote pty is not released. It was speculated that this would be fixed by applying SLS net382e, but it did not. Meanwhile, the workaround is to insert a "pause" between the SCRIPT and HANGUP commands. (The situation with later SCO releases is not known.) SCO UNIX and OpenServer allow their console and/or terminal drivers to be configured to translate character sets for you. DON'T DO THIS WHEN USING KERMIT! First of all, you don't need it -- Kermit itself already does this for you. And second, it will (a) probably ruin the formatting of your screens (depending on which emulation you are using); and (b) interfere with all sorts of other things -- legibility of non-ASCII text on the terminal screen, file transfer, etc. Use: mapchan -n to turn off this feature. Note that there is a multitude of SCO entries in the makefile, many of them exhibiting an unusually large number of compiler options. Some people actually understand all of this. Reportedly, things are settling down with SCO OpenServer 5.x and Unixware 7 -- the SCO UDK compiler is said to generate binaries that will run on either platform, by default, automatically. When using gcc or egcs, on the other hand, differences persist, plus issues regarding the type of binary that is generated (COFF, ELF, etc), and where and how it can run. All of this could stand further clarification by SCO experts. (3.7) C-KERMIT AND SOLARIS See also: The comp.unix.solaris newsgroup http://access1.sun.com/ http://docs.sun.com/ http://www.sunhelp.com/ http://www.wins.uva.nl/pub/solaris/solaris2/ http://www.wins.uva.nl/cgi-bin/sfaq.cgi ftp://ftp.wins.uva.nl/pub/solaris And about serial communications in particular, see "Celeste's Tutorial on Solaris 2.x Modems and Terminals": http://www.stokely.com/ In particular: http://www.stokely.com/unix.sysadm.resources/faqs.sun.html For PC-based Solaris, also see general comments on PC-based UNIXes in Section 3.0. Don't expect Solaris or any other kind of UNIX to work right on a PC until you resolve all interrupt conflicts. Don't expect to be able to use COM3 or COM4 (or even COM2) until you have configured their addresses and interrupts. Even then your serial port can't be used -- or at least won't work right -- until it is enabled in Solaris. For example, you get a message like "SERIAL: Operation would block" when attempting to dial. This probably indicates that the serial port has not been enabled for use with modems. You'll need to follow the instructions in your system setup or management manual, such as (e.g.) the Desktop SPARC Sun System & Network Manager's Guide, which should contain a section "Setting up Modem Software"; read it and follow the instructions. These might (or might not) include running a program called "eeprom", editing some system configuration file (such as, for example: /platform/i86pc/kernel/drv/asy.conf and then doing a configuration reboot, or running some other programs like drvconfig and devlinks. "man eeprom" for details. Also, on certain Sun models like IPC, the serial port hardware might need to have a jumper changed to make it an RS-232 port rather than RS-423. Some users report difficulties dialing out with C-Kermit on serial port when using the /dev/cua/a name -- session seems to become stuck, can't escape back, etc -- but when using the /dev/term/a name for the *same* device, everything works fine. Explanation: unknown, but probably due to improper configuration of the port; again, see the materials referenced above. Reportedly, if you start C-Kermit and "set line" to a port that has a modem connected to it that is not turned on, and then "set flow rts/cts", there might be some (unspecified) difficulties closing the device (Solaris version not specified). 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 structure 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 were all fixed in C-Kermit 6.0. 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 fix with the Serial Port Manager; I just delete the service 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 For additional information, see "Celeste's Tutorial on SunOS 4.1.3+ Modems and Terminals": http://www.stokely.com/ For FAQs, etc, from Sun, see: http://access1.sun.com/ 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. Also, on certain Sun models like IPC, the serial port hardware might need to have a jumper changed to make it an RS-232 port rather than RS-423. 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 See also: The comp.unix.ultrix and comp.sys.dec newsgroups. There is no hardware flow control in Ultrix. That's not a Kermit deficiency, but an Ultrix one. When sending files to C-Kermit on a Telnet connection to a remote Ultrix system, you must SET PREFIXING ALL (or at least prefix more control characters than are selected by SET PREFIXING CAUTIOUS). 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 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. The maximum serial speed on the DECstation 5000 is normally 19200, but various tricks are available (outside Kermit) to enable higher rates. For example, on the 5000/200, 19200 can be remapped (somehow, something to do with "a bit in the SIR", whatever that is) to 38400, but in software you must still refer to this speed as 19200; you can't have 19200 and 38400 available at the same time. 19200, reportedly, is also the highest speed supported by Ultrix, but NetBSD reportedly supports speeds up to 57600 on the DECstation, although whether and how well this works is another question. In any case, given the lack of hardware flow control in Ultrix, high serial speeds are problematic at best. (3.10) C-KERMIT AND UNIXWARE See also: http://www.zenez.com/cgi-bin/scouw7faq/faq.pl comp.unix.unixware.misc comp.unix.sco.misc Also see general comments on PC-based UNIXes in Section 3.0. Note that in Unixware 2.0 and later, the preferred serial device names (drivers) are /dev/term/00 (etc), rather than /dev/tty00 (etc). Also note the following correspondence of device names and driver characteristics: New name Old name Description /dev/term/00 /dev/tty00 ??? /dev/term/00h /dev/tty00h Modem signals and hardware flow control /dev/term/00m /dev/tty00m Modem signals(?) /dev/term/00s /dev/tty00s Modem signals and software flow control /dev/term/00t /dev/tty00t ??? Lockfile names use device inode.major.minor numbers, e.g.: /var/spool/locks/LK.7679.003.005 The minor number varies according to the device name suffix (none, h, m, s, or t). Only the inode and major number are compared, and thus all of the different names for the same physical device (e.g. all of those shown in the table above) interlock effectively. Prior to UnixWare 7, serial speeds higher than 38400 are not supported. In UnixWare 7, we also support 57600 and 115200, plus some unexpected ones like 14400, 28800, and 76800, by virtue of a strange new interface, evidently peculiar to UnixWare 7, discovered while digging through the header files: tcsetspeed(). Access to this interface is allowed only in POSIX builds, and thus the UnixWare 7 version of C-Kermit is POSIX-based, unlike C-Kermit for Unixware 1.x and 2.x (since the earlier UnixWare versions did not support high serial speeds, period). HOWEVER, turning on POSIX features engages all of the "#if (!_POSIX_SOURCE)" clauses in the UnixWare header files, which in turn prevent us from having modem signals, access to the hardware flow control APIs, select(), etc -- in short, all the other things we need in communications software, especially when high speeds are used. Oh the irony. And so C-Kermit must be shamelessly butchered -- as it has been so many times before -- to allow us to have the needed features from the POSIX and non-POSIX worlds. See the UNIXWAREPOSIX sections of ckutio.c. Meanwhile the tcsetspeed() function allows any number at all (any long, 0 or positive) as an argument and succeeds if the number is a legal bit rate for the serial device, and fails otherwise. There is no list anywhere of legal speeds. Thus the SET SPEED keyword table ("set speed ?" to see it) is hardwired based on trial and error with all known serial speeds, the maximum being 115200. However, to allow for the possibility that other speeds might be allowed in the future (or with different port drivers), the SET SPEED command for UnixWare 7 only allows you to specify any number at all; a warning is printed if the number is not in the list, but the number is accepted anyway; the command succeeds if tcsetspeed() accepts the number, and fails otherwise. Old business: Using C-Kermit 6.0 on the UnixWare 1.1 Application Server, one user reported 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 and (reportedly) 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 C-Kermit 7.0 is too big to be built on Tandy Xenix, even in a minimum configuration; version 6.0 is the last one that fits. In C-Kermit 6.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) Before you can use a serial port on a new Digital Unix system, you must run uucpsetup to enable or configure the port. Evidently the /dev/tty00 and 01 devices that appear in the configuration are not usable; uucpsetup turns them into /dev/ttyd00 and 01, which are. Note that uucpsetup and other uucp-family programs are quite primitive -- they only know about speeds up to 9600 bps and their selection of modems dates from the early 1980s. None of this affects Kermit, though -- with C-Kermit, you can use speeds up to 115200 bps (at least in DU4.0 and later) and modern modems with hardware flow control and all the rest. 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). Reportedly, there is some bizarre behavior when trying to use a version of C-Kermit built on Digital Unix 4.0 on another, possibly due to differing OS or library revision levels; for example, the inability to connect to certain TCP/IP hosts. Solution: rebuild C-Kermit from source code on the system where you will be using it. Digital UNIX tgetstr() causes a segmentation fault. C-Kermit 7.0 includes #ifdefs to avoid calling this routine in Digital UNIX. As a result, the SCREEN commands always send ANSI escape sequences -- even though curses knows your actual terminal type. (3.14) C-KERMIT AND SGI IRIX See also: The comp.sys.sgi.misc and .admin newsgroups. The SGI FAQ: http://www-viz.tamu.edu/~sgi-faq/ ftp://viz.tamu.edu/pub/sgi/faq/ About IRIX version numbers: "uname -a" tells the "two-digit" version number, such as "5.3" or "6.5". The three-digit form can be seen with "uname -R". (this information is unavailable at the simple API level). Supposedly all three-digit versions within the same two-digit version (e.g. 6.5.2, 6.5.3) are binary compatible; i.e. a binary built on any one of them should run on all others. The "m" suffix denotes just patches; the "f" suffix indicates that features were added. SGI did not supply an API for hardware flow control prior to IRIX 5.2. C-Kermit 6.1 and higher for IRIX 5.2 and higher supports hardware flow control in the normal way, via "set flow rts/cts". For hardware flow control on earlier IRIX and/or C-Kermit versions, use the ttyf* (modem control AND hardware flow control) devices and not the ttyd* (direct) or ttym* (modem control but no hardware 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. Serial speeds higher than 38400 are available in IRIX 6.2 and later, on O-class machines (e.g. Origin, Octane) only, and are supported by C-Kermit 6.1 and later. Commands such as "set speed 115200" may be given on other models (e.g. Iris, Indy, Indigo) but will fail because the OS reports an invalid speed for the device. Experimentation with both IRIX 5.3 and 6.2 shows that when logged in to IRIX via Telnet, that remote-mode C-Kermit can't send files if the packet length is greater than 4096; the Telnet server evidently has this restriction (or bug), since there is no problem sending long packets on serial or rlogin connections. However, it can receive files with no problem if the packet length is greater than 4096. As a workaround, the FAST macro for IRIX includes "set send packet-length 4000". IRIX 6.5.1 does not have this problem, so evidently it was fixed some time after IRIX 6.2. Tests show file-transfer speeds are better (not worse) with 8K packets than with 4K packets from IRIX 6.5.1. 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. 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. Also see notes about IRIX 3.x in ckcuins.txt. (3.15) C-KERMIT AND THE BEBOX See also: The comp.sys.be newsgroup. The BeBox has been discontinued and BeOS repositioned for PC platforms. The POSIX parts of BeOS are not finished, nor is the sockets library, therefore a fully functional version of C-Kermit is not possible. In version 6.0 of C-Kermit, written for BeOS DR7, it was possible 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) C-Kermit does not work on BeOS DR8 because of changes in the underlying APIs. Unfortunately not enough changes were made to allow the regular POSIX-based C-Kermit to work either. Note: the lack of a fork() service requires the select()-based CONNECT module, but there is no select(). There is a select() in DR8, but it doesn't work. C-Kermit 7.0 has been built for BeOS 4.5 and it works in remote mode. It does not include networking support since the APIs are still not there. It is not known if dialing out works, but probably not. (3.16) C-KERMIT AND DG/UX Somebody downloaded the C-Kermit 6.0 binary built under DG/UX 5.40 and ran it under DG/UX 5.4R3.10 -- it worked OK except that file dates for incoming files were all written as 1 Jan 1970. Cause and cure unknown. Workaround: SET ATTRIBUTE DATE OFF. Better: Use a version of C-Kermit built under and for DG/UX 5.4R3.10. (3.17) C-KERMIT AND SEQUENT DYNIX 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). This is unsatisfying because two versions of the program would be needed -- one for use over X.25, and the other for serial and TCP/IP connections. (3.18) C-KERMIT AND {FREE,OPEN,NET}BSD Some NebBSD users have reported difficulty escaping back from CONNECT mode, usually when running NetBSD on non-PC hardware. Probably a keyboard issue. NetBSD users have also reported that C-Kermit doesn't pop back to the prompt if the modem drops carrier. This needs to be checked out & fixed if possible. (All the above seems to work properly in C-Kermit 7.0.) FreeBSD 4.0 appear to break C-Kermit due to an apparent bug introduced into ncurses, namely that initscr() changes the buffering of the console, but endwin() does not restore it. Therefore, when Kermit puts up the fullscreen file-transfer display, subsequent commands are no longer echoed and any features that depend on character-by-character processing of commands (editing, completion, menus, etc) don't work. To avoid the problem, SET TRANSFER DISPLAY to anything but FULLSCREEN. (Or try setting the environment variable NCURSES_NO_SETBUF to some value.) (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 an NFS-mounted 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: replaced by: HP-UX 10.20 libc PHCO_8764 PHCO_14891/PHCO_16723 HP-UX 10.10 libc PHCO_8763 PHCO_14254/PHCO_16722 HP-UX 9.x libc PHCO_7747 S700 PHCO_13095 HP-UX 9.x libc PHCO_6779 S800 PHCO_11162 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.txt) 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. The same can apply to any other environment in which the user's session is captured, monitored, recorded, or manipulated. Examples include the 'script' program (for making a typescript of a session), the Computronics PEEK package and pksh (at least versions of it prior to 1.9K), and so on. 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.txt). 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, of which the first 14 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 FLOW RTS/CTS and SET DIAL SPEED-MATCHING OFF. The situation is similar, but different, in System V. SVID Third Edition lists the same speeds, 0 through 38400. Some 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. Linux has a "setserial" command that can do it, etc. More modern UNIXes support POSIX-based speed setting, in which the selection of speeds is not limited by a 4-bit field. C-Kermit 6.1 incorporates a new mechanism for finding out (at compile time) which serial speeds are supported by the operating system that does not involve editing of source code by hand; on systems like Solaris 5.1, IRIX 6.2, and SCO OSR5.0.4, "set speed ?" will list speeds up to 460800 or 921600. In C-Kermit 7.0: 1. If a symbol for a particular speed (say B230400 for 230400 bps) appears in whatever header file defines acceptable serial speeds (e.g. or or , etc), the corresponding speed will appear in C-Kermit's "set speed ?" list. 2. The fact that a given speed is listed in the header files and appears in C-Kermit's list does not mean the driver will accept it. For example, a computer might have some standard serial ports plus some add-on ones with different drivers that accept a different repertoire of speeds. 3. The fact that a given speed is accepted by the driver does not guarantee the underlying hardware can accept it. When Kermit is given a "set speed" command for a particular device, the underlying system service is called to set the speed; its return code is checked and the SET SPEED command fails if the return code indicates failure. Regardless of the system service return status, the device's speed is then read back and if it does not match the speed that was requested, an error message is printed and the command fails. Even when the command succeeds, this does not guarantee successful operation at a particular speed, especially a high one. That depends on electricity, information theory, etc. How long is the cable, what is its capacitance, how well is it shielded, etc, not to mention that every connection has two ends and its success depends on both of them. (With the obvious caveats about internal modems, is the cable really connected, interrupt conflicts, etc etc etc). Note, in particular, that there is a certain threshold above which modems can not "autobaud" -- i.e. detect the serial interface speed when you type AT (or whatever else the modem's recognition sequence might be). Such modems need to be engaged at a lower speed (say 2400 or 9600 or even 115200 -- any speed below their autobaud threshold) and then must be given a modem-specific command (which can be found in the modem manual) to change their interface speed to the desired higher speed, and then the software must also be told to change to the new, higher speed. For additional information, read the section TERMINAL SPEEDS in ckuins.txt, plus any platform-specific notes in Section (3) above. (7) COMMUNICATIONS AND DIALING If you SET LINE to a serial port modem-control device that has nothing plugged in to it, or has a modem connected that is powered off, and you have not given a prior SET MODEM TYPE or SET CARRIER-WATCH OFF command, the SET LINE command is likely to hang. In most cases, you can Ctrl-C out. If not, you'll have to kill C-Kermit from another terminal. Similarly, if you give a SET MODEM TYPE HAYES (or USR, or any other modem type besides DIRECT, NONE, or UNKNOWN) and then SET LINE to an empty port, the subsequent close (implicit or explicit) is liable to hang or even crash (through no fault of Kermit's -- the hanging or crashing is inside a system call such as cfsetospeed() or close()). The SET CARRIER-WATCH 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 or, failing that, if C-Kermit can obtain the modem signals from the device driver (you can tell by giving a "set line" command to a serial device, and then a "show communications" command -- if modem signals are not listed, C-Kermit won't be able to detect carrier loss, the WAIT command will not work, etc). Of course, the device itself (e.g. modem) must be configured appropriately and the cables convey the carrier and other needed signals, etc. If you dial out from UNIX system, but then notice a lot of weird character strings being stuck into your session at random times (especially if they look like +++ATQ0H0 or login banners or prompts), that means that getty is also trying to control the same device. You'll need to dial out on a device that is not waiting for a login, or else disable getty on the device. In version 7.0, C-Kermit makes a lot of explicit checks for the Carrier Detect signal, and so catches hung-up connections much better than 6.0 and earlier. However, it still can not be guaranteed to catch every ever CD on-to-off transition. For example, when the HP-UX version of C-Kermit is in CONNECT mode on a dialed connection and CARRIER-WATCH ON or AUTO, and you turn off the modem, HP-UX is stuck in a read() that never returns. (C-Kermit does not pop back to its prompt automatically, but you can still escape back.) If, on the other hand, you log out from the remote system, and it hangs up, and CD drops on the local modem, C-Kermit detects this and pops back to the prompt as it should. (Evidently there can be a difference between CD and DSR turning off at the same time, versus CD turning off while DSR stays on; experimentation with &S0/&S1/&S2 on your modem might produce the desired results). 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 ckermit2.txt file about this. 4. Use C-Kermit new EXEC /REDIRECT command, also described in ckermit2.txt. 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.txt. 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.txt). 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 is not a terminal emulator. Refer to page 147 of "Using C-Kermit", 2nd Edition: "Most versions of C-Kermit -- UNIX, VMS, AOS/VS, VOS, etc -- provide terminal connection without emulation. These versions act as a 'semitransparent pipe' between the remote computer and your terminal, terminal emulator, console driver, or window, which in turn emulates (or is) a specific kind of terminal." The environment in which you run C-Kermit is up to you. If you are an X Windows user, you should be aware of an alternative to xterm that supports VT220 emulation, from Thomas E. Dickey: http://www.clark.net/pub/dickey/xterm/xterm.faq.html 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. 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). (10) FILE TRANSFER Suppose you start C-Kermit with a command-line argument to send or receive a file (e.g. "kermit -r") and then type Ctrl-\c immediately afterwards to escape back and initiate the other end of the transfer, BUT your local Kermit's escape character is not Ctrl-\. In this case, the local Kermit passes the Ctrl-\ to the remote system, and if this is UNIX, Ctrl-\ is likely to be its SIGQUIT character, which causes the current program to halt and dump core. Well, just about the first thing C-Kermit does when it starts is to disable the SIGQUIT signal. However, it is still possible for SIGQUIT to cause Kermit to quit and dump core if it is delivered while Kermit is being loaded or started, before the signal can be disabled. There's nothing Kermit itself can do about this, but you can prevent it from happening by disabling SIGQUIT in your UNIX session. The command is usually something like: stty quit undef 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 or other limits are involved) to the user. File transfer can 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). The exact effect of the ulimit depends on the particular UNIX version, and to some extent probably also on the shell. "man ulimit" for details, or read the man page for the shell you are using. UNIX C-Kermit discards all carriage returns from incoming files when in text mode. 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 compilation switch (see ckuins.txt). 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, but you want to have the fullscreen file transfer display, 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, BRIEF, 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 the curses library for your version of UNIX includes the newterm() function, 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 system's curses library, and you should probably not use it. Tell C-Kermit to SET FILE DISPLAY CRT or anything else other than FULLSCREEN, and/or rebuild without -DCK_CURSES, and without linking with (termlib and) curses. Note: In C-Kermit 7.0 this problem seems to have escalated, and -DCK_NEWTERM had to be added to many builds that previously worked without it: Linux, AIX 4.1, DG/UX, etc. In the Linux case, it is obviously because of changes in the (n)curses library; the cause in the other cases is not known. 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). C-Kermit creates backup-file names (such as "oofa.txt.~1~") based on its knowledge of the maximum filename length on the platform where it is running, which is learned at compile time, based on MAXNAMLEN or equivalent symbols from the system header files. But suppose C-Kermit is receiving files on a UNIX platform that supports long filenames, but the incoming files are being stored on an NFS-mounted file system that supports only short names. NFS maps the external system to the local APIs, so C-Kermit has no way of knowing that long names will be truncated. Or that C-Kermit is running on a version of UNIX that supports both long-name and short-name file systems simultaneously (such as HP-UX 7.00). This can cause unexpected behavior when creating backup files, or worse. For example, you are sending a group of files whose names are differentiated only by characters past the point at which they would be truncated, each file will overwrite the previous one upon arrival. 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.txt and ckccfg.txt 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.txt 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 "Using C-Kermit", 2nd Ed, Chapter 14.) "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 Chapter 14 of "Using C-Kermit", 2nd Edition). 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 Note: the following section dates from circa 1994. Since then, evidently, "slirp" has supplanted "term", and reportedly, unlike term, slirp can be used transparently to the application: http://blitzen.canberra.edu.au/resources 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 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 ; or "suspend" $ Now you can run term clients such as trsh and tupload at the local shell prompt. (12) SECURITY We receive constant requests for versions of C-Kermit that use all sorts of security mechanisms: SOCKS, SSL, SSH, SSLeay, TSL, PCT, SRP, etc etc. Well... (a) C-Kermit can be linked with a SOCKS library if you have one; see ckccfg.txt, section 8.1.1. (b) Most of the others require export or import licenses, carry source-code restrictions, and/or are patented. HOWEVER... (c) C-Kermit 7.0 includes support for Kerberos; see kerberos.txt for details. (d) It also has a new feature to let it be used "over" secure clients like SSL Telnet, SRP Telnet, etc. See ckermit2.txt Sections 2.7 and 2.14 for details. (13) MISCELLANEOUS 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 successfully 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 -- System 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); } ------------------------------ (14) THIRD-PARTY DRIVERS UNIX versions, especially those for PCs (SCO, Unixware, etc) might be augmented by third-party communication-board drivers from Digiboard, Stallion, etc. These can sometimes complicate matters for Kermit considerably since Kermit has no way of knowing that it is going through a possibly nonstandard driver. Various examples are listed in the earlier sections of this file; search for Stallion, Digiboard, etc. Additionally: . The Stallion Technologies EasyConnection serial board driver does not always report the state of DSR as low. From Stallion (October 1997): "Unfortunately, this is a bug in our driver. We have implemented all of the other TIOMC functions, eg DTR, DCD, RTS and CTS, but not DSR. Our driver should report the actual state of DSR on those of our cards that have a DSR signal. That the driver always reports DSR as not asserted (0), is a bug in the driver. The driver should be either reporting the state of DSR correctly on those cards that support DSR or as always asserted (1) on those cards that do not have a DSR signal. This will be fixed in a future version of our drivers; at this time I cannot say when this will be." And later, "As far as I can tell, we don't support the termios/termiox ioctls that relate specifically to DSR and RI; all the rest are supported. This will, as I mentioned earlier, be fixed in the next release of our ATA software." - World Wide Escalation Support, Stallion Technologies, Toowong QLD, support@stallion.oz.au. Later (December 1997, from the same source): . We have now released a new version of the ATA software, version 5.4.0. This version fixes the problem with the states of the DSR and RI signals and how they were being reported by the driver. This is the problem that you reported in October. The DSR signal is reported correctly on those cards that support the DSR signal, such as the early revision of the EasyIO card and the EasyConnection 8D4 panel, and as always asserted on those cards that do not support the DSR signal in the hardware. The new driver is available from our Web site, www.stallion.com, in the /drivers/ata5/UnixWare directory. (End of CKUBWR.TXT)