X-Git-Url: http://erislabs.net/gitweb/?a=blobdiff_plain;f=ckubwr.txt;fp=ckubwr.txt;h=0000000000000000000000000000000000000000;hb=31e271107096d1ffa97b7d0c15222b8bd5e69f74;hp=4b0d38766665add50bb576f64036cf8b8d96ecdc;hpb=8d5a97cca5dc3d41681e7a2dd709ac0ea93e73c5;p=ckermit.git diff --git a/ckubwr.txt b/ckubwr.txt deleted file mode 100644 index 4b0d387..0000000 --- a/ckubwr.txt +++ /dev/null @@ -1,5330 +0,0 @@ - - C-Kermit 8.0 Unix Hints and Tips - - Frank da Cruz - [1]The Kermit Project, [2]Columbia University - - As of: C-Kermit 8.0.211 10 April 2004 - This page last updated: Fri Apr 16 16:13:14 2004 (New York USA Time) - - IF YOU ARE READING A PLAIN-TEXT version of this document, note it - is a plain-text dump of a Web page. You can visit the original (and - possibly more up-to-date) Web page here: - - [3]http://www.columbia.edu/kermit/ckubwr.html - - Since the material in this file has been accumulating since 1985, - some (much) of it might be dated. [4]Feedback from experts on - particular OS's and platforms is always welcome. - - [ [5]C-Kermit ] [ [6]Installation Instructions ] [ [7]TUTORIAL ] - ________________________________________________________________________ - - CONTENTS - - 1. [8]INTRODUCTION - 2. [9]PREBUILT C-KERMIT BINARIES - 3. [10]PLATFORM-SPECIFIC NOTES - 4. [11]GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS - 5. [12]INITIALIZATION AND COMMAND FILES - 6. [13]COMMUNICATION SPEED SELECTION - 7. [14]COMMUNICATIONS AND DIALING - 8. [15]HARDWARE FLOW CONTROL - 9. [16]TERMINAL CONNECTION AND KEY MAPPING - 10. [17]FILE TRANSFER - 11. [18]EXTERNAL FILE TRANSFER PROTOCOLS - 12. [19]SECURITY - 13. [20]MISCELLANEOUS USER REPORTS - 14. [21]THIRD-PARTY DRIVERS - - Quick Links: [ [22]Linux ] [ [23]*BSD ] [[24]Mac OS X] [ [25]AIX ] [ - [26]HP-UX ] [ [27]Solaris ] [ [28]SCO ] [ [29]DEC/Compaq ] - ________________________________________________________________________ - - 1. INTRODUCTION - - [ [30]Top ] [ [31]Contents ] [ [32]Next ] - - SECTION CONTENTS - - 1.1. [33]Documentation - 1.2. [34]Technical Support - 1.3. [35]The Year 2000 - 1.4. [36]The Euro - - THIS IS WHAT USED TO BE CALLED the "beware file" for the Unix version - of C-Kermit, previously distributed as ckubwr.txt and, before that, as - ckuker.bwr, after the fashion of old Digital Equipment Corporation - (DEC) software releases that came with release notes (describing what - had changed) and a "beware file" listing known bugs, limitations, - "non-goals", and things to watch out for. The C-Kermit beware file has - been accumulating since 1985, and it applies to many different - hardware platforms and operating systems, and many versions of them, - so it is quite large. Prior to C-Kermit 8.0, it was distributed only - in plain-text format. Now it is available as a Web document with - links, internal cross references, and so on, to make it easier to use. - - This document applies to Unix C-Kermit in general, as well as to - specific Unix variations like [37]Linux, [38]AIX, [39]HP-UX, - [40]Solaris, and so on, and should be read in conjunction with the - [41]platform-independent C-Kermit beware file, which contains similar - information, but applying to all versions of C-Kermit (VMS, Windows, - OS/2, AOS/VS, VOS, etc, as well as to Unix). - - There is much in this document that is (only) of historical interest. - The navigation links should help you skip directly to the sections - that are relevant to you. Numerous offsite Web links are supposed to - lead to further information but, as you know, Web links go stale - frequently and without warning. If you can supply additional, - corrected, updated, or better Web links, please feel free to [42]let - us know. - - 1.1. Documentation - - [ [43]Top ] [ [44]Contents ] [ [45]Next ] - - C-Kermit 6.0 is documented in the book [46]Using C-Kermit, Second - Edition, by Frank da Cruz and Christine M. Gianone, Digital Press, - Burlington, MA, USA, ISBN 1-55558-164-1 (1997), 622 pages. This - remains the definitive C-Kermit documentation. Until the third edition - is published (sorry, there is no firm timeframe for this), please also - refer to: - - [47]Supplement to Using C-Kermit, Second Edition, For C-Kermit 7.0 - Thorough documentation of features new to version 7.0. - - [48]Supplement to Using C-Kermit, Second Edition, For C-Kermit 8.0 - Thorough documentation of features new to version 8.0. - - 1.2. Technical Support - - [ [49]Top ] [ [50]Contents ] [ [51]Section Contents ] [ [52]Next ] [ - [53]Previous ] - - For information on how to get technical support, please visit: - - [54]http://www.columbia.edu/kermit/support.html - - 1.3. The Year 2000 - - [ [55]Top ] [ [56]Contents ] [ [57]Section Contents ] [ [58]Next ] [ - [59]Previous ] - - 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. - (Quite a few old Unixes are still in operation in the new millenium, - but with their date set 28 years in the past so at least the non-year - parts of the calendar are correct.) - - As of C-Kermit 6.0 (6 September 1996), 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 still takes 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. - - 1.4. The Euro - - [ [60]Top ] [ [61]Contents ] [ [62]Section Contents ] [ [63]Previous ] - - 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. - ________________________________________________________________________ - - 2. PREBUILT C-KERMIT BINARIES - - [ [64]Top ] [ [65]Contents ] [ [66]Next ] [ [67]Previous ] - - 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 - might refuse 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 this is - increasingly impossible as shared libraries become the norm. - - 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 Solaris 8 on Solaris 2.6. - Sometimes even the OS-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 many 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 computer - 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 - - [ [68]Top ] [ [69]Contents ] [ [70]Next ] [ [71]Previous ] - - SECTION CONTENTS - - 3.0. [72]C-KERMIT ON PC-BASED UNIXES - 3.1. [73]C-KERMIT AND AIX - 3.2. [74]C-KERMIT AND HP-UX - 3.3. [75]C-KERMIT AND LINUX - 3.4. [76]C-KERMIT AND NEXTSTEP - 3.5. [77]C-KERMIT AND QNX - 3.6. [78]C-KERMIT AND SCO - 3.7. [79]C-KERMIT AND SOLARIS - 3.8. [80]C-KERMIT AND SUNOS - 3.9. [81]C-KERMIT AND ULTRIX - 3.10. [82]C-KERMIT AND UNIXWARE - 3.11. [83]C-KERMIT AND APOLLO SR10 - 3.12. [84]C-KERMIT AND TANDY XENIX 3.0 - 3.13. [85]C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX) - 3.14. [86]C-KERMIT AND SGI IRIX - 3.15. [87]C-KERMIT AND THE BEBOX - 3.16. [88]C-KERMIT AND DG/UX - 3.17. [89]C-KERMIT AND SEQUENT DYNIX - 3.18. [90]C-KERMIT AND {FREE,OPEN,NET}BSD - 3.19. [91]C-KERMIT AND MAC OS X - 3.20. [92]C-KERMIT AND COHERENT - - The following sections apply to specific Unix versions. Most of them - contain references to FAQs (Frequently Asked Questions), but these - tend to be ephemeral. For possibly more current information see: - - [93]http://www.faqs.org - [94]http://aplawrence.com/Unixart/newtounix.html - - 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 OS-dependent and often obscure manner, and the - effects (good or evil) are also highly dependent on the particular OS - (and getty variety, etc). Many examples are given in the - [95]OS-specific sections below. - - An important point to keep in mind is that C-Kermit is a - cross-platform, portable software 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 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 hundreds of different OS / version / - hardware / library combinations. If you're a programmer, take a look - at the source code and [96]send us your suggested fixes or changes. Or - else just [97]send us a report about what seems to be wrong and we'll - see what we can do. - ________________________________________________________________________ - - 3.0. C-KERMIT ON PC-BASED UNIXES - - [ [98]Top ] [ [99]Contents ] [ [100]Section Contents ] [ [101]Next ] - - Also see: [102]http://www.pcunix.com/. - - SECTION CONTENTS - - 3.0.1. [103]Interrupt Conflicts - 3.0.2. [104]Windows-Specific Hardware - 3.0.3. [105]Modems - 3.0.4. [106]Character Sets - 3.0.5. [107]Keyboard, Screen, and Mouse Access - 3.0.6. [108]Laptops - - 3.0.1. Interrupt Conflicts - - [ [109]Top ] [ [110]Contents ] [ [111]Section Contents ] [ [112]Next ] - - 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, many of which are preallocated). Thus adding devices, using - multiple serial ports, etc, is always a challenge and often a - nightmare. The free-for-all nature of the PC market and the lack of - standards combined with the diversity of Unix OS versions make 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, - especially when using a serial mouse, and don't expect to be able to - use more than two serial ports. - - The techniques for resolving interrupt conflicts are different for - each operating system (Linux, NetBSD, etc). In general, there is a - configuration file somewhere that lists COM ports, something like - this: - - com0 at isa? port 0x3f8 irq 4 # DOS COM1 - com1 at isa? port 0x2f8 irq 3 # DOS COM2 - - The address and IRQ values in this file must agree with the values in - the PC BIOS and with the ports themselves, and there must not be more - than one device with the same interrupt. Unfortunately, due to the - small number of available interrupts, installing new devices on a PC - almost always creates a conflict. 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. - - Here's another one from a newsgroup posting: - - After much hair pulling, I've discovered why my serial port won't - work. Apparently my [PC] has three serial devices (two comm ports - and an IR port), of which only two at a time can be active. I - looked in the BIOS setup and noticed that the IR port was - activated, but didn't realize at the time that this meant that COM2 - was thereby de-activated. I turned off the IR port and now the - serial port works as advertised. - ________________________________________________________________________ - - 3.0.2. Windows-Specific Hardware - - [ [113]Top ] [ [114]Contents ] [ [115]Section Contents ] [ [116]Next ] - [ [117]Previous ] - - 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, PCI, or "Plug-n-Play" devices are - rarely supported on PC-based Unix versions such as SCO; Winmodems, - Winprinters, and the like are not supported on any Unix variety (with - [118]a few exceptions). The self-proclaimed Microsoft PC 97 (or later) - standard only makes 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, perhaps a handful of - others by the time you read this), 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 - because Unix is a real operating system. - - 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 is a true multitasking operating 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. - - A more recent generation of PCs (circa 1999-2000) is marketed as - "Legacy Free". One can only speculate what that could mean. Most - likely it means it will ONLY run the very latest versions of Windows, - and is made exclusively of Winmodems, Winprinters, Winmemory, and - Win-CPU-fans (Legacy Free is a concept [119]pioneered by Microsoft). - - 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. - ________________________________________________________________________ - - 3.0.3. Modems - - [ [120]Top ] [ [121]Contents ] [ [122]Section Contents ] [ [123]Next ] - [ [124]Previous ] - - External modems are recommended: - - * They don't need any special drivers. - * You can use the lights and speaker to troubleshoot dialing. - * You can share them among all types of computers. - * You can easily turn them off and on when power-cycling seems - warranted. - * They are more likely to have manuals. - - 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: - - [125]http://www.idir.net/~gromitkc/winmodem.html - - Remember that PCs, even now -- more than two decades after they were - 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 [126]DigiBoard are available for certain Unix platforms - (typically SCO, maybe Linux) that come with special platform-specific - drivers. - ________________________________________________________________________ - - 3.0.4. Character Sets - - [ [127]Top ] [ [128]Contents ] [ [129]Section Contents ] [ [130]Next ] - [ [131]Previous ] - - 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). (And work is - in progress to support Unicode UTF8 in Linux.) - - 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), and - several of these are already supported by C-Kermit 7.0 and later - (1250, 1251, and 1252). - ________________________________________________________________________ - - 3.0.5. Keyboard, Screen, and Mouse Access - - [ [132]Top ] [ [133]Contents ] [ [134]Section Contents ] [ [135]Next ] - [ [136]Previous ] - - 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, Arrow keys, Alt-key combinations, and the like. This is - because: - - a. Unix is a portable operating system, not only for PCs; - b. Unix sessions can come from anywhere, not just the PC's own - keyboard and screen; and: - c. even though it might be possible for an application that actually - is running on the PC's keyboard and screen to access these devices - directly, there are no APIs (outside of X) for this. - ________________________________________________________________________ - - 3.0.6. Laptops - - [ [137]Top ] [ [138]Contents ] [ [139]Section Contents ] [ - [140]Previous ] - - (To be filled in . . .) - ________________________________________________________________________ - - 3.1. C-KERMIT AND AIX - - [ [141]Top ] [ [142]Contents ] [ [143]Section Contents ] [ [144]Next ] - [ [145]Previous ] - - SECTION CONTENTS - - 3.1.1. [146]AIX: General - 3.1.2. [147]AIX: Network Connections - 3.1.3. [148]AIX: Serial Connections - 3.1.4. [149]AIX: File Transfer - 3.1.5. [150]AIX: Xterm Key Map - - For additional information see: - * [151]http://www.emerson.emory.edu/services/aix-faq/ - * [152]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html - * [153]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/to - p.html - * [154]http://aixpdslib.seas.ucla.edu/ - * [155]http://www.rootvg.net (AIX history) - * [156]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1 - * [157]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/ - aix - - and/or read the [158]comp.unix.aix newsgroup. - ______________________________________________________________________ - - 3.1.1. AIX: General - - [ [159]Top ] [ [160]Contents ] [ [161]Section Contents ] [ [162]Next ] - - 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 who knows. Most AIX - advocates tell you that any AIX binary will run on any AIX version - greater than or equal to the one under which it was built, but - experience with C-Kermit suggests otherwise. It is always best to run - a binary built under your exact same AIX version, down to the third - decimal place, if possible. Ideally, build it from source code - yourself. Yes, this advice would be easier to follow if AIX came with - a C compiler. - ______________________________________________________________________ - - 3.1.2. AIX: Network Connections - - [ [163]Top ] [ [164]Contents ] [ [165]Section Contents ] [ [166]Next ] - [ [167]Previous ] - - File transfers into AIX 4.2 or 4.3 through the AIX Telnet or Rlogin - server have been observed to fail (or accumulate huge numbers of - correctable errors, or even disconnect the session), when exactly the - same kind of transfers into AIX 4.1 work without incident, as do such - transfers into all non-AIX platforms on the same kind of connections - (with a few exceptions noted elsewhere in this document). AIX 4.3.3 - seems to be particularly fragile in this regard; the weakness seems to - be in its pseudoterminal (pty) driver. High-speed streaming transfers - work perfectly, however, if the AIX Telnet server and pty driver are - removed from the picture; e.g, by using "set host * 3000" on AIX. - - The problem can be completely cured by replacing the IBM Telnet server - with [168]MIT's Kerberos Telnet server -- even if you don't actually - use the Kerberos part. Diagnosis: AIX pseudoterminals (which are - controlled by the Telnet server to give you a login terminal for your - session) have quirks that not even IBM knows about. The situation with - AIX 5.x is not known, but if it has the same problem, the same cure is - available. - - Meanwhile, the only remedy when going through the IBM Telnet server is - to cut back on Kermit's performance settings until you find a - combination that works: - - * SET STREAMING OFF - * SET WINDOW-SIZE small-number - * SET { SEND, RECEIVE } PACKET-LENGTH small-number - * SET PREFIXING { CAUTIOUS, ALL } - - In some cases, severe cutbacks are required, e.g. those implied by the - ROBUST command. Also be sure that the AIX C-Kermit on the remote end - has "set flow none" (which is the default). NOTE: Maybe this one can - also be addressed by starting AIX telnetd with the "-a" option. The - situation with SSH connections is not known, but almost certainly the - same. - - When these problems occur, the system error log contains: - - LABEL: TTY_TTYHOG - IDENTIFIER: 0873CF9F - Type: TEMP - Resource Name: pts/1 - - Description - TTYHOG OVER-RUN - - Failure Causes - EXCESSIVE LOAD ON PROCESSOR - - Recommended Actions - REDUCE SYSTEM LOAD. - REDUCE SERIAL PORT BAUD RATE - - Before leaving the topic of AIX pseudoterminals, it is very likely - that Kermit's PTY and SSH commands do not work well either, for the - same reason that Telnet connections into AIX don't work well. A brief - test with "pty rlogin somehost" got a perfectly usable terminal - (CONNECT) session, but file-transfer problems like those just - described. - - 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. - - 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. - ______________________________________________________________________ - - 3.1.3. AIX: Serial Connections - - [ [169]Top ] [ [170]Contents ] [ [171]Section Contents ] [ [172]Next ] - [ [173]Previous ] - - In AIX 3, 4, or 5, 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. - - 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. - - In AIX 2.2.1 on the RT PC with the 8-port multiplexer, SET SPEED 38400 - gives 9600 bps, but SET SPEED 19200 gives 19200 (on the built-in S1 - port). - - 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). - 3. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support - and other AIX bugs are available from IBM at: - [174]http://service.software.ibm.com/rs6000/ - Downloads -> Software Fixes -> Download FixDist gets an - application for looking up known problems. - - 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. - ______________________________________________________________________ - - 3.1.4. AIX: File Transfer - - [ [175]Top ] [ [176]Contents ] [ [177]Section Contents ] [ [178]Next ] - [ [179]Previous ] - - Evidently AIX 4.3 (I don't know about earlier versions) does not allow - open files to be overwritten. This can cause Kermit transfers to fail - when FILE COLLISION is OVERWRITE, where they might work on other Unix - varieties or earlier AIX versions. - - Transfer of binary -- and maybe even text -- files can fail in AIX if - the AIX terminal has particular port can have character-set - translation done for it by the tty driver. The following advice from a - knowledgeable AIX user: - - [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. - - On the same problem, another knowledgeable AIX user says: - - The way to get information on the NLS mapping under AIX (3.2.5 - anyway) is as follows. From the command line type: - - lsattr -l tty# -a imap -a omap -E -H - - Replace the tty number for the number sign above. This will give a - human readable output of the settings that looks like this; - - # lsattr -l tty2 -a imap -a omap -E -H - attribute value description user_settable - - imap none INPUT map file True - omap none OUTPUT map file True - - If you change the -H to a -O, you get output that can easily be - processed by another program or a shell script, for example: - - # lsattr -l tty2 -a imap -a omap -E -O - #imap:omap - none:none - - To change the settings from the command line, the chdev command is - used with the following syntax. - - chdev -l tty# -a imap='none' -a omap='none' - - Again substituting the appropriate tty port number for the number - sign, "none" being the value we want for C-Kermit. Of course, the - above can also be changed by using the SMIT utility and selecting - devices - tty. (...end quote) - ______________________________________________________________________ - - 3.1.5. AIX: Xterm Key Map - - [ [180]Top ] [ [181]Contents ] [ [182]Section Contents ] [ - [183]Previous ] - - 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("[K~") \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 - - [ [184]Top ] [ [185]Contents ] [ [186]Section Contents ] [ [187]Next ] - [ [188]Previous ] - - SECTION CONTENTS - - 3.2.0. [189]Common Problems - 3.2.1. [190]Building C-Kermit on HP-UX - 3.2.2. [191]File Transfer - 3.2.3. [192]Dialing Out and UUCP Lockfiles in HP-UX - 3.2.4. [193]Notes on Specific HP-UX Releases - 3.2.5. [194]HP-UX and X.25 - - REFERENCES - - For further information, read the [195]comp.sys.hp.hpux newsgroup. - - C-Kermit is included as part of the HP-UX operating system by contract - between Hewlett Packard and Columbia University for HP-UX 10.00 and - later. Each level of HP-UX includes a freshly built C-Kermit binary in - /bin/kermit, which should work correctly. Binaries built for regular - HP-UX may be used on Trusted HP-UX and vice-versa, except for use as - IKSD because of the different authentication methods. - - Note that HP does not update C-Kermit versions for any but its most - current HP-UX release. So, for example, HP-UX 10.20 has C-Kermit 6.0; - 11.00 has C-Kermit 7.0, and 11.22 has 8.0. Of course, as with all - software, older Kermit versions have bugs (such as buffer overflow - vulnerabilities) that are fixed in later versions. From time to time, - HP discovers one of these (long-ago fixed) bugs and issues a security - alert for the older OS's, recommending some draconian measure to avoid - the problem. The true fix in each situation is to install the current - release of C-Kermit. - - 3.2.0. Common Problems - - [ [196]Top ] [ [197]Contents ] [ [198]Section Contents ] [ [199]Next ] - - 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 - - [ [200]Top ] [ [201]Contents ] [ [202]Section Contents ] [ [203]Next ] - [ [204]Previous ] - - This section applies mainly to old (pre-10.20) HP-UX version on - old, slow, and/or memory-constrained hardware. - - 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 7.0 and 8.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 [205]makefile), but doing so - tends to make the compilations take a much longer time. For example, - the "hpux0100o+" makefile target 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 makefile, all HP-UX entries automatically skip optimization of - problematic modules. - ________________________________________________________________________ - - 3.2.2. File Transfer - - [ [206]Top ] [ [207]Contents ] [ [208]Section Contents ] [ [209]Next ] - [ [210]Previous ] - - Telnet connections into HP-UX versions up to and including 11.11 (and - possibly 11.20) tend not to lend themselves to file transfer due to - limitations, restrictions, and/or bugs in the HP-UX Telnet server - and/or pseudoterminal (pty) driver. - - In C-Kermit 6.0 (1996) an unexpected slowness was noted when - transferring files over local Ethernet connections when an HP-UX - system (9.05 or 10.00) was 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 - and HP-UX 10.20 on the far end. - - 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 (i.e. it is - infinite). 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 HP-UX C-Kermit as a TCP service: - - set host * 3000 - server - - and then from the client "set host xxx 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 33MHz CPU.) - - Matters seem to have deteriorated in HP-UX 11. Now file transfers over - Telnet connections fail completely, rather than just being slow. In - the following trial, a Telnet connection was made from Kermit 95 to - HP-UX 11.11 on an HP-9000/785/B2000 over local 10Mbps Ethernet running - C-Kermit 8.00 in server mode (under the HP-UX Telnet server): - - Text........ Binary...... - Stream Pktlen GET SEND GET SEND - On 4000 Fail Fail Fail Fail - Off 4000 Fail Fail Fail Fail - Off 2000 OK Fail OK Fail - On 2000 OK Fail OK Fail - On 3000 Fail Fail Fail Fail - On 2500 Fail Fail Fail Fail - On 2047 OK Fail OK Fail - On 2045 OK Fail OK Fail - Off 500 OK OK OK OK - On 500 OK Fail OK Fail - On 240 OK Fail OK Fail - - As you can see, downloads are problematic unless the receiver's Kermit - packet length is 2045 or less, but uploads work only with streaming - disabled and the packet length restricted to 500. To force file - transfers to work on this connection, the desktop Kermit must be told - to: - - set streaming off - set receive packet-length 2000 - set send packet-length 500 - - However, if a connection is made between the same two programs on the - same two computers over the same network, but this time a direct - socket-to-socket connection bypassing the HP-UX Telnet server and pty - driver (tell HP-UX C-Kermit to "set host /server * 3000 /raw"; tell - desktop client program to "set host blah 3000 /raw"), everything works - perfectly with the default Kermit settings (streaming, 4K packets, - liberal control-character unprefixing, 8-bit transparency, etc): - - Text........ Binary...... - Stream Pktlen GET SEND GET SEND - On 4000 OK OK OK OK - - And in this case, transfer rates were approximately 900,000 cps. To - verify that the behavior reported here is not caused by the new Kermit - release, the same experiment was performed on a Telnet connection from - the same PC over the same network to the old 715/33 running HP-UX - 10.20 and C-Kermit 8.00. Text and binary uploads and downloads worked - perfectly (albeit slowly) with all the default settings -- streaming, - 4K packets, etc. - ________________________________________________________________________ - - 3.2.3. Dialing Out and UUCP Lockfiles in HP-UX - - [ [211]Top ] [ [212]Contents ] [ [213]Section Contents ] [ [214]Next ] - [ [215]Previous ] - - HP workstations do not come with dialout devices configured; you have - to do it yourself (as root). First look in /dev to see what's there; - for example in HP-UX 10.00 or later: - - ls -l /dev/cua* - ls -l /dev/tty* - - If you find a tty0p0 device but no cua0p0, you'll need to creat one if - you want to dial out; the tty0p0 does not work for dialing out. It's - easy: start SAM; in the main Sam window, double-click on Peripheral - Device, then in the Peripheral Devices window, double-click on - Terminals and Modems. In the Terminals and Modems dialog, click on - Actions, then choose "Add modem" and fill in the blanks. For example: - Port number 0, speed 57600 (higher speeds tend not to work reliably), - "Use device for calling out", do NOT "Receive incoming calls" (unless - you know what you are doing), leave "CCITT modem" unchecked unless you - really have one, and do select "Use hardware flow control (RTS/CTS)". - Then click OK. This creates cua0p0 as well as cul0p0 and ttyd0p0 - - If the following sequence: - - set line /dev/cua0p0 ; or other device - set speed 115200 ; or other normal speed - - produces the message "?Unsupported line speed". This means either that - the port is not configured for dialout (go into SAM as described above - and make sure "Use device for calling out" is selected), or else that - speed you have given (such as 460800) is supported by the operating - system but not by the physical device (in which case, use a lower - speed like 57600). - - 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 (the Convio 10.0 column applies - to HP-UX 10 and 11). - - 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. - - Here, by the way, is a summary of the differences between the HP-UX - port driver types from John Pezzano of HP: - - There are three types of device files for each port. - - The ttydXXX device file is designed to work as follows: - - 1. The process that opens it does NOT get control of the port until - CD is asserted. This was intentional (over 15 years ago) to allow - getty to open the port but not control it until someone called in. - If a process wants to use the direct or callout device files - (ttyXXX and culXXX respectively), they will then get control and - getty would be blocked. This eliminated the need to use uugetty - (and its inherent problems with lock files) for modems. You can - see this demonstrated by the fact that "ps -ef" shows a ? in the - tty column for the getty process as getty does not have the port - yet. - 2. Once CD is asserted, the port is controlled by getty (or the - process handling an incoming call) if there was no process using - the port. The ? in the "ps" command now shows the port. At this - point, the port accepts data. - - Therefore you should use either the callout culXXX device file - (immediate control but no data until CD is asserted) or the direct - device file ttyXXX which gives immediate control and immediate data - and which ignores by default modem control signals. - - The ttydXXX device should be used only for callin and my - recommendation is to use it only for getty and uugetty. - ________________________________________________________________________ - - 3.2.4 Notes on Specific HP-UX Releases - - SECTION CONTENTS - - 3.2.4.1. [216]HP-UX 11 - 3.2.4.2. [217]HP-UX 10 - 3.2.4.3. [218]HP-UX 9 - 3.2.4.4. [219]HP-UX 8 - 3.2.4.5. [220]HP-UX 7 and Earlier - - 3.2.4.1. HP-UX 11 - - [ [221]Top ] [ [222]Contents ] [ [223]Section Contents ] [ [224]Next ] - - As noted in [225]Section 3.2.2, the HP-UX 11 Telnet server and/or - pseudoterminal driver are a serious impediment to file transfer over - Telnet connections into HP-UX. If you have a Telnet connection into - HP-UX 11, tell your desktop Kermit program to: - - set streaming off - set receive packet-length 2000 - set send packet-length 500 - - File transfer speeds over connections from HP-UX 11 (dialed or Telnet) - are not impeded whatsoever, and can go at whatever speed is allowed by - the connection and the Kermit partner on the far end. - - PA-RISC binaries for HP-UX 10.20 or later should run on any PA-RISC - system, S700 or S800, as long as the binary was not built under a - later HP-UX version than the host operating system. HP-UX 11.00 and - 11.11 are only for PA-RISC systems. HP-UX 11.20 is only for IA64 - (subsequent HP-UX releases will be for both PA-RISC and IA64). To - check binary compatibility, the following C-Kermit 8.0 binaries were - run successfully on an HP-9000/785 with HP-UX 11.11: - - * Model 7xx HP-UX 10.20 - * Model 8xx HP-UX 10.20 - * Model 7xx HP-UX 11.00 - * Model 8xx HP-UX 11.00 - * Model 7xx HP-UX 11.11 - * Model 8xx HP-UX 11.11 - - Binaries built under some of the earlier HP-UX releases, such as 9.05, - might also work, but only if built for the same hardware family (e.g. - s700). - ________________________________________________________________________ - - 3.2.4.2. HP-UX 10 - - [ [226]Top ] [ [227]Contents ] [ [228]Section Contents ] [ [229]Next ] - [ [230]Previous ] - - Beginning in HP-UX 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. HP-UX 11.20 and later, however, link with libcurses, as - libHcurses disappeared in 11.20. - ________________________________________________________________________ - - 3.2.4.3. HP-UX 9 - - [ [231]Top ] [ [232]Contents ] [ [233]Section Contents ] [ [234]Next ] - [ [235]Previous ] - - 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.4.4. HP-UX 8 - - [ [236]Top ] [ [237]Contents ] [ [238]Section Contents ] [ [239]Next ] - [ [240]Previous ] - - 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. - - One user reports: - - 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.4.5. HP-UX 7 and Earlier - - [ [241]Top ] [ [242]Contents ] [ [243]Section Contents ] [ - [244]Previous ] - - When transferring files into HP-UX 5 or 6 over a Telnet connection, - you must not use streaming, and you must not use a packet length - greater than 512. However, you can use streaming and longer packets - when sending files from HP-UX on a Telnet connection. In C-Kermit 8.0, - the default receive packet length for HP-UX 5 and 6 was changed to 500 - (but you can still increase it with SET RECEIVE PACKET-LENGTH if you - wish, e.g. for non-Telnet connections). Disable streaming with SET - STREAMING OFF. - - 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 and X.25 - - [ [245]Top ] [ [246]Contents ] [ [247]Section Contents ] [ - [248]Previous ] - - 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 address - - This works if padem uses standard i/o (who knows?). - ________________________________________________________________________ - - 3.3. C-KERMIT AND LINUX - - [ [249]Top ] [ [250]Contents ] [ [251]Section Contents ] [ [252]Next ] - [ [253]Previous ] - - SECTION CONTENTS - - 3.3.1. [254]Problems Building C-Kermit for Linux - 3.3.2. [255]Problems with Serial Devices in Linux - 3.3.3. [256]Terminal Emulation in Linux - 3.3.4. [257]Dates and Times - 3.3.5. [258]Startup Errors - 3.3.6. [259]The Fullscreen File Transfer Display - - REFERENCES - - For further information, read the [260]comp.os.linux.misc, - [261]comp.os.linux.answers, and other Linux-oriented newsgroups, and - see: - - The Linux Document Project (LDP) - [262]http://www.tldp.org/ - - The Linux FAQ - [263]http://www.tldp.org/FAQ/Linux-FAQ.html - - The Linux HOWTOs (especially the Serial HOWTO) - - [264]http://www.tldp.org/HOWTO/Serial-HOWTO.html - - [265]http://tldp.org/HOWTO/Modem-HOWTO.html - - [266]ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO - - [267]ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO - - [268]http://www.tldp.org/HOWTO/ - - [269]http://www.tldp.org/hmirrors.html - - Linux Vendor Tech Support Pages: - - [270]http://www.redhat.com/apps/support/ - - [271]http://www.debian.org/support - - [272]http://www.slackware.com/support/ - - [273]http://www.caldera.com/support/ - - [274]http://www.suse.com/support/ - - [275]http://www.mandrake.com/support/ - - [276]http://www.turbolinux.com/support/ - - Linux Winmodem Support - [277]http://www.linmodems.org/ - - Also see general comments on PC-based Unixes in [278]Section 3.0. - - What Linux version is it? -- "uname -a" supplies only kernel - information, but these days it's the distribution that matters: Red - Hat 7.3, Debian 2.2, Slackware 8.0, etc. Unfortunately there's no - consistent way to get the distribution version. Usually it's in a - distribution-specific file: - - Red Hat: /etc/issue or /etc/redhat-release - Debian: /etc/debian_version - Slackware: /etc/slackware-version (at least in later versions) - - Did you know: DECnet is available for Linux? See: - - [279]http://linux.dreamtime.org/decnet/ - - (But there is no support for it in C-Kermit -- anybody interested in - adding it, please [280]let us know). - - Before proceeding, let's handle the some of the most frequently asked - question in the Linux newsgroups: - - 1. Neither C-Kermit nor any other Linux application can use - Winmodems, except in the [281]rare cases where Linux drivers have - been written for them. See [282]Section 3.0.2 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 and 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's address cannot be found by the server's 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, and - that the registrations are exported. 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. (Any question that has the word "Telnet" in it...) The knee-jerk - reaction is "don't use Telnet, use SSH!" There's nothing wrong - with Telnet. In fact it's far superior to SSH as a protocol in - terms of features and extensibility, not to mention platform - neutrality. The issue lurking behind the knee-jerk reaction is - security. SSH is thought to be secure, whereas Telnet is thought - to be insecure. This is true for clear-text Telnet (because - passwords travel in the clear across the network), but apparently - few people realize that [283]secure Telnet clients and servers - have been available for years, and these are more secure than SSH - (for reasons explained [284]HERE. - 4. (Any question that has the word "FTP" in it...) The knee-jerk - reaction being "Don't use FTP, use SCP!" (or SFTP). Same answer as - above, but moreso. SCP and SFTP are not only not platform neutral, - they're diversity-hostile. They transfer files only in binary - mode, which mangles text files across different platforms, to the - same degree the platform's text-file record format and character - set differ. An extreme example would be an Variable-Block format - EBCDIC text file on an IBM mainframe, binary transfer of which to - Unix would do you little good indeed. FTP was designed with - diversity in mind and secure versions are available. - ________________________________________________________________________ - - 3.3.1. Problems Building C-Kermit for Linux - - [ [285]Top ] [ [286]Contents ] [ [287]Section Contents ] [ [288]Next ] - - 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. But to confuse matters, you - might also have to choose (separately) to install the "curses" or - "ncurses" terminal control library; thus 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. - - 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. As of - C-Kermit 8.0, these questions should be resolved by the "linux" - makefile target itself, which does a bit of looking around to see - what's what, and then sets the appropriate CFLAGS. - ________________________________________________________________________ - - 3.3.2. Problems with Serial Devices in Linux - - [ [289]Top ] [ [290]Contents ] [ [291]Section Contents ] [ [292]Next ] - [ [293]Previous ] - - Also see: "man setserial", "man irqtune". - And: [294]Sections 3.0, [295]6, [296]7, and [297]8 of this - document. - - NOTE: Red Hat Linux 7.2 and later include a new API that allows - serial-port arbitration by non-setuid/gid programs. This API has - not yet been added to C-Kermit. If C-Kermit is to be used for - dialing out on Red Hat 7.2 or later, it must still be installed as - described in in Sections [298]10 and [299]11 of the - [300]Installation Instructions. - - 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 - 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. - - You can also find out a fair amount about your PC's hardware - configuration in the text files in /proc, e.g.: - - -r--r--r-- 1 root 0 Sep 4 14:00 /proc/devices - -r--r--r-- 1 root 0 Sep 4 14:00 /proc/interrupts - -r--r--r-- 1 root 0 Sep 4 14:00 /proc/ioports - -r--r--r-- 1 root 0 Sep 4 14:00 /proc/pci - - From the directory listing they look like empty files, but in fact - they are text files that you "cat": - -$ cat /proc/pci - Bus 0, device 14, function 0: - Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 1). - IRQ 10. - I/O at 0x1050 [0x1057]. - -$ setserial -g /dev/ttyS4 -/dev/ttyS4, UART: 16550A, Port: 0x1050, IRQ: 10 - -$ cat /proc/ioports -1050-1057 : US Robotics/3Com 56K FaxModem Model 5610 - 1050-1057 : serial(auto) - -$ cat /proc/interrupts - CPU0 - 0: 7037515 XT-PIC timer - 1: 2 XT-PIC keyboard - 2: 0 XT-PIC cascade - 4: 0 XT-PIC serial - 8: 1 XT-PIC rtc - 9: 209811 XT-PIC usb-uhci, eth0 - 14: 282015 XT-PIC ide0 - 15: 6 XT-PIC ide1 - - Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the - like (see cautions in [301]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 du jour). - - PCI modems do not use standard COM port addresses. The I/O address and - IRQ are assigned by the BIOS. All you need to do to get one working, - find out the I/O address and interrupt number with (as root) "lspci -v - | more" and then give the resulting address and interrupt number to - setserial. - - 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. - - To find what serial ports were registered at the most recent system - boot, type (as root): "grep tty /var/log/dmesg". - - "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 occurs in C-Kermit 7.0 or later.) - - "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 7.0 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 (have phased) it out in favor of the ttyS device. See - (if it's still there): - - [302]http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html - - (no, of course it isn't; you'll have to use your imagination). 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. - - All versions of Linux seem to have the following deficiency: When a - modem call is hung up and CD drops, Kermit can no longer read the - modem signals; SHOW COMMUNICATIONS says "Modem signals not available". - The TIOCMGET ioctl() returns -1 with errno 5 ("I/O Error"). - - The Linux version of POSIX tcsendbreak(), which is used by C-Kermit to - send regular (275msec) and long (1.5sec) BREAK signals, appears to - ignore its argument (despite its description in the man page and info - topic), and always sends a regular 275msec BREAK. This has been - observed in Linux versions ranging from Debian 2.1 to Red Hat 7.1. - ________________________________________________________________________ - - 3.3.3. Terminal Emulation in Linux - - [ [303]Top ] [ [304]Contents ] [ [305]Section Contents ] [ [306]Next ] - [ [307]Previous ] - - C-Kermit is not a terminal emulator. For a brief explanation of why - not, see [308]Section 3.0.5. For a fuller explanation, [309]ClICK - HERE. - - In Unix, terminal emulation is supplied by the Window in which you run - Kermit: 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: - - [310]http://dickey.his.com/xterm/xterm.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 filename" 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. - - For a much more complete VT220/320 key mapping for [311]Xfree86 xterm, - [312]CLICK HERE. - ________________________________________________________________________ - - 3.3.4. Dates and Times - - [ [313]Top ] [ [314]Contents ] [ [315]Section Contents ] [ [316]Next ] - [ [317]Previous ] - - 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 - - [ [318]Top ] [ [319]Contents ] [ [320]Section Contents ] [ [321]Next ] - [ [322]Previous ] - - C-Kermit should work on all versions of Linux current through March - 2003, provided it was built on the same version you have, with the - same libraries and header files (just get the source code and "make - linux"). Binaries tend not to travel well from one Linux machine to - another, due to their many differences. There is no guarantee that a - particular C-Kermit binary will not stop working at a later date, - since Linux tends to change out from under its applications. If that - happens, rebuild C-Kermit from source. If something goes wrong with - the build process, look on the [323]C-Kermit website for a newer - version. If you have the latest version, then [324]report the problem - to us. - - Inability to transfer files in Red Hat 7.2: the typical symptom would - be if you start Kermit and tell it to RECEIVE, it fails right away - with "?/dev/tty: No such device or address" or "?Bad file descriptor". - One report says this is because of csh, and if you change your shell - to bash or other shell, it doesn't happen. Another report cite bugs in - Red Hat 7.2 Telnetd "very seldom (if ever) providing a controlling - tty, and lots of other people piled on saying they have the same - problem.") A third theory is that this happens only when Linux has - been installed without "virtual terminal support". - - A search of RedHat's errata pages shows a bug advisory (RHBA-2001-153) - issued 13 November 2001, but updated 6 December, about this same - symptom (but with tcsh and login.) Seems that login was not always - assigning a controlling TTY for the session, which would make most use - of "/dev/tty" somewhat less than useful. - - [325]http://www.redhat.com/support/errata/RHBA-2001-153.html - - Quoting: "Due to terminal handling problems in /bin/login, tcsh would - not find the controlling terminal correctly, and a shell in single - user mode would exhibit strange terminal input characteristics. This - update fixes both of these problems." - - 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 - [326]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. - - 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 reported that installing the link fixes the problem. - ________________________________________________________________________ - - 3.3.6. The Fullscreen File Transfer Display - - [ [327]Top ] [ [328]Contents ] [ [329]Section Contents ] [ - [330]Previous ] - - Starting with ncurses versions dated 1998-12-12 (about a year before - ncurses 5.0), ncurses sets the terminal for buffered i/o, but - unfortunately is not able to restore it upon exit from curses (via - endwin()). Thus after a file transfer that uses the fullscreen file - transfer display, the terminal no longer echos nor responds - immediately to Tab, ?, and other special command characters. The same - thing happens on other platforms that use ncurses, e.g. FreeBSD. - Workarounds: - - * Use SET XFER DISPLAY BRIEF, CRT, SERIAL, or NONE instead of - FULLSCREEN; or: - * Rebuild with KFLAGS=-DNONOSETBUF (C-Kermit 8.0) - - In Red Hat 7.1, when using C-Kermit in a Gnome terminal window, it was - noticed that when the fullscreen file transfer display exits (via - endwin()), the previous (pre-file-transfer-display) screen is - restored. Thus you can't look at the completed display to see what - happened. This is a evidently a new feature of xterm. I can only - speculate that initscreen() and endwin() must send some kind of - special escape sequences that command xterm to save and restore the - screen. To defeat this effect, tell Linux you have a vt100 or other - xterm-compatible terminal that is not actually an xterm, or else tell - Kermit to SET TRANSFER DISPLAY to something besides FULLSCREEN. - ________________________________________________________________________ - - 3.4. C-KERMIT AND NEXTSTEP - - [ [331]Top ] [ [332]Contents ] [ [333]Section Contents ] [ [334]Next ] - [ [335]Previous ] - - 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 NeXTSTEP serial-port 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 - - [ [336]Top ] [ [337]Contents ] [ [338]Section Contents ] [ [339]Next ] - [ [340]Previous ] - - See also: The [341]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, or else [342]G-Kermit. - - The 32-bit version (and the 16-bit version prior to C-Kermit 7.0) - supports 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 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 or later 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/sern 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 [343]UUCP - lockfile section of the [344]Installation Instructions 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. - - As of C-Kermit 8.0, C-Kermit's "open-count" form of line locking works - only in QNX4, not in QNX6 (this might change in a future C-Kermit - release). - ________________________________________________________________________ - - 3.6. C-KERMIT AND SCO - - [ [345]Top ] [ [346]Contents ] [ [347]Section Contents ] [ [348]Next ] - [ [349]Previous ] - - SECTION CONTENTS - -3.6.1. [350]SCO XENIX -3.6.2. [351]SCO UNIX and OSR5 -3.6.3. [352]Unixware -3.6.4. [353]Open UNIX 8 - - REFERENCES - - * The comp.unix.sco.* newsgroups. - * [354]Section 3.10 below for Unixware. - * The following FAQs: - - The comp.sco.misc FAQ: - [355]http://aplawrence.com/SCOFAQ/ - - Caldera (SCO) comp.unix.sco.programmer FAQ: - [356]http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl - - The UnixWare 7/OpenUNIX 8 FAQ: - [357]http://www.zenez.com/cgi-bin/scouw7faq/faq.pl - [358]http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl - - High Speed Modems for SCO Unix: - [359]http://pcunix.com/Unixart/modems.html - - The UnixWare FAQ - [360]http://www.freebird.org/faq/ - - The UnixWare 1.x and 2.0 Programmer FAQ - [361]http://www.freebird.org/faq/developer.html - - Caldera Support Knowledge Base - [362]http://support.caldera.com/caldera - - [363]http://stage.caldera.com/ta/ - Caldera (SCO) Technical Article Search Center - - [364]http://aplawrence.com/newtosco.html - New to SCO (Tony Lawrence) - - The same comments regarding terminal emulation and key mapping apply - to SCO operating systems as to all other Unixes. C-Kermit is not a - terminal emulator, and you can't use it to map F-keys, Arrow keys, - etc. The way to do this is with xmodmap (xterm) or loadkeys (console). - For a brief explanation, see [365]Section 3.0.5. For a fuller - explanation, [366]ClICK HERE. - - Also see general comments on PC-based Unixes in [367]Section 3.0. - - 3.6.1. SCO XENIX - - [ [368]Top ] [ [369]Contents ] [ [370]Section Contents ] [ [371]Next ] - - Old Xenix versions... Did you know: Xenix 3.0 is *older* than Xenix - 2.0? - - In Xenix 2.3.4 and probably other Xenix versions, momentarily dropping - DTR to hang up a modem does not work. DTR goes down but does not come - up again. Workaround: Use SET MODEM HANGUP-METHOD MODEM-COMMAND. - Anybody who would like to fix this is welcome to take a look at - tthang() in [372]ckutio.c. Also: modem signals can not be read in - Xenix, and the maximum serial speed is 38400. - - 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 :-) - - Xenix 2.3.0 and later claim 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). - ________________________________________________________________________ - - 3.6.2. SCO UNIX AND OSR5 - - [ [373]Top ] [ [374]Contents ] [ [375]Section Contents ] [ [376]Next ] - [ [377]Previous ] - - SCO systems tend to use different names (i.e. drivers) for the same - device. Typically /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). - - SCO OpenServer 5.0.5 and earlier 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. OSR5.0.6 attempts to - deal with modem signals but fails; however OSR5.0.6a appears to - function properly. - - Dialing is likely not to work well in SCO OpenServer 5.0.x because - many of the serial-port APIs simply do not operate when using the - standard drivers. For example, if DTR is dropped by the recommended - method (setting speed to 0 for half a seconds, then restoring the - speed), DTR and RTS go down but never come back up. When in doubt SET - MODEM HANGUP-METHOD MODEM-COMMAND or SET DIAL HANGUP OFF. - - 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., [378]Digiboard 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: - - [379]ftp://ftp.fu-berlin.de/pub/unix/driver/fas - - 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. - - 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 and - 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. - - 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 [380]Section - 14 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 - [381]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 using /bin/cc (NOT - the UDK, which hides the high-speed definitions from CPP), 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 [382]ftp://ftp.sco.com/; the "rs40" series are - under directory /Supplements/internet - - Kermit includes the high serial speeds in all OSR5 builds, but that - does not necessarily mean they work. For example, on our in-house - 5.0.5 system, SET SPEED 57600 or higher seems to succeed (no error - occurs) but when we read the speed back the driver says it is 50. - Similarly, 76800 becomes 75, and 115200 becomes 110. Testing shows the - resulting speed is indeed the low one we read back, not the high one - we asked for. Moral: Use speeds higher than 38400 with caution on SCO - OSR5. - - 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 (and Open UNIX 8 - and who knows what the next one will be -- Linux probably) -- 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.6.3. Unixware - - [ [383]Top ] [ [384]Contents ] [ [385]Section Contents ] [ [386]Next ] - [ [387]Previous ] - - Unixware changed hands several times before landing at SCO, and so has - its [388]own section in this document. (Briefly: AT&T UNIX Systems - Laboratories sold the rights to the UNIX name and to System V R4 (or - R5?) to Novell; later Novell spun its UNIX division off into a new - company called Univel, which eventually was bought by SCO, which later - was bought by Caldera, which later sort of semi-spun-off SCO...) - ________________________________________________________________________ - - 3.6.4. Open UNIX 8 - - [ [389]Top ] [ [390]Contents ] [ [391]Section Contents ] [ - [392]Previous ] - - SCO was bought by Caldera in 2000 or 2001 and evolved Unixware 7.1 - into Caldera Open UNIX 8.00. It's just like Unixware 7.1 as far as - Kermit is concerned (the Unixware 7.1 makefile target works for Open - UNIX 8.00, and in fact a Unixware 7.1 Kermit binary built on Unixware - 7.1 runs under OU8; a separate OU8 makefile target exists simply to - generate an appropriate program startup herald). Open Unix is now - defunct; subsequent releases are called UnixWare again (e.g. UnixWare - 7.1.3). - ________________________________________________________________________ - - 3.7. C-KERMIT AND SOLARIS - - [ [393]Top ] [ [394]Contents ] [ [395]Section Contents ] [ [396]Next ] - [ [397]Previous ] - - SECTION CONTENTS - -3.7.1. [398]Serial Port Configuration -3.7.2. [399]Serial Port Problems -3.7.3. [400]SunLink X.25 -3.7.4. [401]Sun Workstation Keyboard Mapping -3.7.5. [402]Solaris 2.4 and Earlier - - REFERENCES - - * The [403]comp.unix.solaris newsgroup - * [404]http://access1.sun.com/ - * [405]http://docs.sun.com/ - * [406]http://www.sunhelp.com/ - * [407]http://www.wins.uva.nl/pub/solaris/solaris2/ - * [408]http://www.wins.uva.nl/cgi-bin/sfaq.cgi - * [409]ftp://ftp.wins.uva.nl/pub/solaris - * [410]http://www.science.uva.nl/pub/solaris/solaris2.html - - And about serial communications in particular, see "Celeste's Tutorial - on Solaris 2.x Modems and Terminals": - - [411]http://www.stokely.com/ - - In particular: - - [412]http://www.stokely.com/unix.sysadm.resources/faqs.sun.html - - For PC-based Solaris, also see general comments on PC-based Unixes in - [413]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. - ________________________________________________________________________ - - 3.7.1. Serial Port Configuration - - [ [414]Top ] [ [415]Contents ] [ [416]Section Contents ] [ - [417]Section Contents ] [ [418]Next ] - - 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. - - eeprom applies only to real serial ports, not to "Spiff" devices - (serial port expander), in which case setup with Solaris' admintool is - required. - - Another command you might need to use is pmadm, e.g.: - - pmadm -d -p zsmon -s tty3 - pmadm -e -p zsmon -s tty3 - - You can use the following command to check if a process has the device - open: - - fuser -f /dev/term/3 - - In some cases, however (according to Sun support, May 2001) "It is - still possible that a zombie process has hold of the port EVEN IF - there is no lock file and the fuser command comes up empty. In that - case, the only way to resolve the problem is by rebooting." - - If you can't establish communication through a serial port to a device - that is not asserting CD (Carrier Detect), try setting the environment - variable "ttya-ignore-cd" to "true" (replace "ttya" with the port - name). - ________________________________________________________________________ - - 3.7.2. Serial Port Problems - - [ [419]Top ] [ [420]Contents ] [ [421]Section Contents ] [ [422]Next ] - [ [423]Previous ] - - Current advice from Sun is to always the /dev/cua/x devices for - dialing out, rather than the /dev/term/x. Nevertheless, if you have - trouble dialing out with one, try the other. - - 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 because the CTS signal is not coming in from the modem. - ________________________________________________________________________ - - 3.7.3. SunLink X.25 - - [ [424]Top ] [ [425]Contents ] [ [426]Section Contents ] [ [427]Next ] - [ [428]Previous ] - - 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. - ________________________________________________________________________ - - 3.7.4. Sun Workstation Keyboard Mapping - - [ [429]Top ] [ [430]Contents ] [ [431]Section Contents ] [ [432]Next ] - [ [433]Previous ] - - Hints for using a Sun workstation keyboard for VT emulation when - accessing VMS, from the [434]comp.os.vms newsgroup: - - 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. - ________________________________________________________________________ - - 3.7.5. Solaris PPP Connections - - [ [435]Top ] [ [436]Contents ] [ [437]Section Contents ] [ [438]Next ] - [ [439]Previous ] - - The following is a report from a user of C-Kermit 8.0 on Solaris 8 and - 9, who had complained that while Kermit file transfers worked - perfectly on direct (non-PPP) dialout connections, they failed - miserably on PPP connections. We suggested that the PPP dialer - probably was not setting the port and/or modem up in the same way that - Kermit did: - - I want to get back on this and tell you what the resolution was. - You pointed me in the direction of flow control, which turned out - to be the key. - - Some discussion on the comp.unix.solaris newsgroup led to some - comments from Greg Andrews about the need to use the uucp driver to - talk to the modem (/dev/cua/a). I had to remind Greg that no matter - what the manpages for the zs and se drivers say, the ppp that Sun - released with Solaris 8 7/01, and has in Solaris 9, is a setuid - root program, and simply trying to make a pppd call from user space - specifying /dev/cua/a would fail because of permissions. Greg - finally put the question to the ppp people, who came back with - information that is not laid out anywhere in the docs available for - Solaris users. Namely, put /dev/cua/a in one of the priviledged - options files in the /etc/ppp directory. That, plus resetting the - OBP ttya-ignore-cd flag (this is Sun hardware) to false, seems to - have solved the problems. - - While I note that I had installed Kermit suid to uucp to use - /dev/cua/a on this particular box, it seems to run fine through - /dev/term/a. Not so with pppd. - - With this change in place, I seem to be able to upload and download - through telnet run on Kermit with the maximum length packets. I - note that the window allocation display does show STREAMING, using - telnet. Running ssh on Kermit, I see the standard 1 of 30 windows - display, and note that there appears to be a buffer length limit - between 1000 and 2000 bytes. Run with 1000, and it's tick-tock, - solid as a rock. With 2000 I see timeout errors and RTS/CTS action - on the modem. - - Kermit's packet-length and other controls let you make adjustments - like this to get around whatever obstacles might be thrown up -- in - this case (running Kermit over ssh), the underling Solaris PTY driver. - ________________________________________________________________________ - - 3.7.6. Solaris 2.4 and Earlier - - [ [440]Top ] [ [441]Contents ] [ [442]Section Contents ] [ - [443]Previous ] - - 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. - - The rest of the problems in this section have to do with - bidirectional terminal ports and the Solaris Port Monitor. A bug in - C-Kermit 5A ticked a bug in Solaris. The C-Kermit bug was fixed in - version 6.0, and the Solaris bug was fixed in 2.4 (I think, or - maybe 2.5). - - 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: - - 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 blurry 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." - - 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 - ________________________________________________________________________ - - 3.8. C-KERMIT AND SUNOS - - [ [444]Top ] [ [445]Contents ] [ [446]Section Contents ] [ [447]Next ] - [ [448]Previous ] - - For additional information, see "Celeste's Tutorial on SunOS 4.1.3+ - Modems and Terminals": - - [449]http://www.stokely.com/ - - For FAQs, etc, from Sun, see: - * [450]http://access1.sun.com/ - - For history of Sun models and SunOS versions, see (should be all the - same): - * [451]http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt - * [452]ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref - * [453]ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref - - 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) was built and tested - successfully under SunOS 4.1.3b and SunLink X.25 7.00. - ________________________________________________________________________ - - 3.9. C-KERMIT AND ULTRIX - - [ [454]Top ] [ [455]Contents ] [ [456]Section Contents ] [ [457]Next ] - [ [458]Previous ] - - See also: The [459]comp.unix.ultrix and [460]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 - - [ [461]Top ] [ [462]Contents ] [ [463]Section Contents ] [ [464]Next ] - [ [465]Previous ] - - See also: - * The Freebird Project (Unixware software repository) - [466]http://www.freebird.org/ - * The UnixWare FAQ: [467]http://www.freebird.org/faq/ - * The following newsgroups: - + [468]comp.unix.unixware.misc - + [469]comp.unix.sco.misc. - - Also see general comments on PC-based Unixes in [470]Section 3.0. By - the way, this section is separate from the SCO (Caldera) section - because at the time this section was started, Unixware was owned by a - company called Univel. Later it was sold to Novell, and then to SCO. - Still later, SCO was sold to Caldera. - - In Unixware 2.0 and later, the preferred serial device names (drivers) - are /dev/term/00 (etc), rather than /dev/tty00 (etc). 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.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 device 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 - [471]ckutio.c. - - After the butchery, we wind up with Unixware 2.x having full - modem-signal capability, but politically-correct Unixware 7.x lacking - the ability to automatically detect a broken connection when carrier - drops. - - Meanwhile the Unixware 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. - - In C-Kermit 8.0 testing, it was noticed that the POSIX method for - hanging up the phone by dropping DTR (set speed 0, pause, restore - speed) did not actually drop DTR. The APIs do not return any error - indication, but nothing happens. I changed tthang() to skip the - special case I had made for Unixware and instead follow the normal - path: if TIOCSDTR is defined use that, otherwise blah blah... It turns - out TIOCSDTR *is* defined, and it works. - - So in Unixware (at least in 2.1.3) we can read modem signals, hangup - by toggling DTR, and so on, BUT... But once the remote hangs up and - Carrier drops, the API for reading modem signals ceases to function; - although the device is still open, the TIOCMGET ioctl always raises - errno 6 = ENXIO, "No such device or address". - - 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 - - [ [472]Top ] [ [473]Contents ] [ [474]Section Contents ] [ [475]Next ] - [ [476]Previous ] - - 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 - - [ [477]Top ] [ [478]Contents ] [ [479]Section Contents ] [ [480]Next ] - [ [481]Previous ] - - C-Kermit 7.0 was too big to be built on Tandy Xenix, even in a minimum - configuration; version 6.0 is the last one that fits. - - Reportedly, in C-Kermit 6.0, 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) (TRU64 UNIX) - - [ [482]Top ] [ [483]Contents ] [ [484]Section Contents ] [ [485]Next ] - [ [486]Previous ] - - While putting together and testing C-Kermit 8.0, it was discovered - that binaries built for one version of Tru64 Unix (e.g. 4.0G) might - exhibit very strange behavior if run on a different version of Tru64 - Unix (e.g. 5.1A). The typical symptom was that a section of the - initialization file would be skipped, notably locating the dialing - and/or network directory as well as finding and executing the - customization file, ~/.mykermrc. This problem also is reported to - occur on Tru64 Unix 5.0 (Rev 732) even when running a C-Kermit binary - that was built there. However, the Tru64 5.1A binary works correctly - on 5.0. Go figure. - - When making Telnet connections to a Digital Unix or Tru64 system, and - your Telnet client forwards your user name, the Telnet server - evidently stuffs the username into login's standard input, and you - see: - - login: ivan - Password: - - This is clearly going to play havoc with scripts that look for - "login:". Workaround (when Kermit is your Telnet client): SET LOGIN - USER to nothing, to prevent Kermit from sending your user ID. - - 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 one Digital Unix 4.0 system on another - one, 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 added - #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. - - Reportedy the Tru64 Unix 4.0E 1091 Telnet server does not tolerate - streaming transfers into itself, at least not when the sending Kermit - is on the same local network. Solution: tell one Kermit or the other - (or both) to "set streaming off". This might or might be the case with - earlier and/or later Tru64, Digital Unix, and OSF/1 releases. - ________________________________________________________________________ - - 3.14. C-KERMIT AND SGI IRIX - - [ [487]Top ] [ [488]Contents ] [ [489]Section Contents ] [ [490]Next ] - [ [491]Previous ] - - See also: - * The [492]comp.sys.sgi.misc and [493]comp.sys.sgi.admin newsgroups. - [494]The SGI website - * The SGI FAQ: - + [495]http://www-viz.tamu.edu/~sgi-faq/ - + [496]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. - - An IRIX binary built on lower MIPS model (Instruction Set - Architecture, ISA) can run on higher models, but not vice versa: - - MIPS1 R3000 and below - MIPS2 R4000 - MIPS3 R4x00 - MIPS4 R5000 and above - - Furthermore, there are different Application Binary Inferfaces (ABIs): - - COFF 32 bits, IRIX 5.3, 5.2, 5.1, 4.x and below - o32 ELF 32 bits, IRIX 5.3, 6.0 - 6.5 - N32 ELF 32 bits, IRIX 6.2 - 6.5 - N64 ELF 64 bits, IRIX 6.2 - 6.5 - - Thus a prebuilt IRIX binary works on a particular machine only if (a) - the machine's IRIX version (to one decimal place) is equal to or - greater than the version under which the binary was built; (b) the - machine's MIPS level is greater or equal to that of the binary; and - (c) the machine supports the ABI of the binary. If all three - conditions are not satisfied, of course, you can build a binary - yourself from source code since, unlike some other Unix vendors, SGI - does supply a C compiler and libraries. - - 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) and - tell Kermit to "set flow keep" and "set modem flow rts/cts". - - 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 7.0 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 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 the [497]C-Kermit for Unix - Installation Instructions. - - If you have problems making TCP/IP connections in versions of IRIX - built with GCC 2.95.2, see the bugs section of: - - [498]http://freeware.sgi.com/Installable/gcc-2.95.2.html. - - Reportedly, if you allow gcc to compile C-Kermit on Irix you should be - aware that there might be problems with some of the network code. The - specifics are at - [499]http://freeware.sgi.com/Installable/gcc-2.95.2.html; scroll down - to the "known bugs" section at the end of the document. - ________________________________________________________________________ - - 3.15. C-KERMIT AND THE BEBOX - - [ [500]Top ] [ [501]Contents ] [ [502]Section Contents ] [ [503]Next ] - [ [504]Previous ] - - See also: The [505]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 was built for BeOS 4.5 and 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. Be experts are - welcome to lend a hand. - ________________________________________________________________________ - - 3.16. C-KERMIT AND DG/UX - - [ [506]Top ] [ [507]Contents ] [ [508]Section Contents ] [ [509]Next ] - [ [510]Previous ] - - 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 - - [ [511]Top ] [ [512]Contents ] [ [513]Section Contents ] [ [514]Next ] - [ [515]Previous ] - - 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 - - [ [516]Top ] [ [517]Contents ] [ [518]Section Contents ] [ [519]Next ] - [ [520]Previous ] - - 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 and later.) - ________________________________________________________________________ - - 3.19. C-KERMIT AND MAC OS X (Rhapsody, Darwin, Jaguar, Panther) - - [ [521]Top ] [ [522]Contents ] [ [523]Section Contents ] [ [524]Next ] - [ [525]Previous ] - - Mac OS X is Apple's 4.4BSD Unix variety, closely related to FreeBSD, - but different. "uname -a" is singularly uninformative, as in Linux, - giving only the Darwin kernel version number. As far as I can tell, - there is no way to find out the Mac OS X version number, such as 10.3 - (in Linux you can find the distribution version in a - distribution-dependent file). Here are some points to be aware of: - - * The biggest gotcha for Kermit users is that Mac OS X does not - support serial ports and, as far as I can tell, doesn't support - its built-in modem either, for anything other than making Internet - connections. Macintoshes capable of running Mac OS X, such as the - G5, some without serial ports and without any APIs to support - them, and also without the UUCP family of programs (including cu), - nor any standard for serial-port lockfile directory. - * At least early versions of Mac OS X came without Curses, Termlib, - or Terminfo libraries. Later versions seem to have ncurses. Kermit - uses curses for its file-transfer display. See elsewhere about - curses-vs-ncurses confusion. - * In the HFS+ file system, filenames are case-folded. Thus - "makefile" and "Makefile" are the same file. The UFS file system - is, like normal Unix, case-sensitive. - * Files that are composed of a resource fork and a data fork... I - doubt that C-Kermit does anything useful with them. There is no - code in C-Kermit for traditional two-forked Macintosh files, but - it could be added if there is any demand. - * In case you want to transfer a traditional Macintosh text file (or - data fork of a file that is plain text), you can use these - C-Kermit commands: - -set file eol cr -set file character-set apple-quickdraw -send /text filename - - * File or pathnames that include spaces must be enclosed in either - doublequotes or curly braces in C-Kermit commands. - * Mac OS X has its own package format for applications, called - "fink". Various fink packages for C-Kermit are floating around - that are not standard releases. For example, there's a C-Kermit - 8.0.201 package in which C-Kermit was modifed (at least) to use a - UUCP lockfile directory that does not exist on vanilla Mac OS X - systems. - - Mac OS X and Serial Ports - - Apple is in the forefront of companies that believe serial ports have - no use in the modern world and so has simply eliminated all traces of - them from its machines and OS. But of course serial ports are still - needed to connect not only to external modems, but also to the control - ports of hubs, routers, terminal servers, PBXs, and similar devices, - not to mention barcode readers, POS systems and components, automated - factory-floor equipment, and scientific, medical, and lab equipment - (to name a few). Among workers in these areas, there is a need to add - serial ports back onto this platform, which is being filled by - third-party products such as the [526]Keyspan USB Serial Adapter. To - use the Keyspan device, you must install the accompanying device - drivers, which wind up giving you serial ports with names like - /dev/cu.USA19H3b1P1.1. - - To configure your Mac OS X system to allow C-Kermit to use these (or - any other) serial devices: - - 1. su - chgrp xxxx /var/spool/lock - chmod g+w /var/spool/lock - chgrp xxxx /dev/cu.* - (where xxxx is the name of the group for users to whom serial-port - access is to be granted). Use "admin" or other existing group, or - create a new group if desired. NB: - - In the absence of official guidance from Apple or anyone else, we - choose /var/spool/lock as the lockfile directory because this - directory (a) already exists on vanilla Mac OS X installations, and - (b) it is the directory used for serial-port lockfiles on many - other platforms. - 2. Put all users who need access to the serial port in the same - group. - 3. Make sure the serial device files that are to be used by C-Kermit - have group read-write permission and (if you care) lack world - read-write permission, e.g.: - chmod g+rw,o-rw /dev/cu.* - - If you do the above, then there's no need to become root to use - Kermit, or to make Kermit suid or sgid. Just do this: - -chmod 775 wermit -mv wermit /usr/local/bin/kermit - - (or whatever spot is more appropriate). For greater detail about - installation (man page, etc), [527]CLICK HERE. - - Back when Macs had serial ports, they were not RS-232 (the standard - for connecting computers with nearby modems) but rather RS-422 or -423 - (a standard for connecting serial devices over longer distances). - Macintosh serial ports do not support modems well because they do not - have enough wires (or more properly in the case RS-422/423, wire - pairs) to convey a useful subset of modem signals. The Keyspan USB - adapter gives you two Mini-Din8 RS-422 ports, that are no better (or - worse) for communicating with modems or serial devices than a real Mac - Din-8 port was. In essense, you get Data In, Data Out, and two modem - signals. It looks to me as if the signals chosen by Keyspan are RTS - and CTS. This gives you hardware flow control, but at the expense of - Carrier Detect. Thus to use C-Kermit with a Keyspan USB serial port, - you must tell C-Kermit to: - -set modem type none ; (don't expect a modem) -set carrier-watch off ; (ignore carrier signal) -set port /dev/cu.USA19H3b1P1.1 ; (open the port) -set flow rts/cts ; (this is the default) -set speed 57600 ; (or whatever) -connect ; (or whatever) - - Use Ctrl-\C in the normal manner to escape back to the C-Kermit> - prompt. Kermit can't pop back to its prompt automatically when Carrier - drops because there is no Carrier signal. - - Instructions for the built-in modem remain to be written. - - Links: - * [528]Unix tips for Mac OS X (Jerry Stratton) - ________________________________________________________________________ - - 3.20. C-KERMIT AND COHERENT - - [ [529]Top ] [ [530]Contents ] [ [531]Section Contents ] [ - [532]Previous ] - - Also see: - - [533]http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg00 - 000.html - - Mark Williams COHERENT was perhaps the first commercial Unix-based - operating system for PCs, first appearing about 1983 or -84 for the - PC/XT (?), and popular until about 1993, when Linux took over. - C-Kermit, as of version 8.0, is still current for COHERENT 386 4.2 - (i.e. only for i386 and above). Curses is included, but lots of other - features are omitted due to lack of the appropriate OS features, APIs, - libraries, hardware, or just space: e.g. TCP/IP, floating-point - arithmetic, learned scripts. Earlier versions of COHERENT ran on 8086 - and 80286, but these are to small to build or run C-Kermit, but - G-Kermit should be OK (as might be ancient versions of C-Kermit). - - You can actually build a version with floating point support -- just - take -DNOFLOAT out of CFLAGS and add -lm to LIBS; NOFLOAT is the - default because COHERENT tends to run on old PCs that don't have - floating-point hardware. You can also add "-f" to CFLAGS to have it - link in the floating-point emulation library. Also I'm not sure why - -DNOLEARN is included, since it depends on select(), which COHERENT - has. - ________________________________________________________________________ - - 4. GENERAL UNIX-SPECIFIC HINTS, LIMITATIONS, AND BUGS - - [ [534]Top ] [ [535]Contents ] [ [536]Next ] [ [537]Previous ] - - 4.1. Modem Signals - - There seems to be an escalating demand for the ability to control - "dumb serial devices" (such as "smartcard readers", barcode readers, - etc) by explicitly manipulating modem signals, particularly RTS. This - might have been easy to do in DOS, where there is no operating system - standing between the application and the serial device, but it is - problematic in Unix, where modem signals are controlled by the serial - device driver. If the driver does not provide an API for doing this, - then the application can't do it. If it does provide an API, expect it - to be totally different on each Unix platform, since there is no - standard for this. - - 4.2. NFS Troubles - - Beginning with C-Kermit 6.0, the default C-Kermit prompt includes your - current (working) directory; for example: - - [/usr/olga] C-Kermit> - - (In C-Kermit 7.0 the square braces were replaced by round parentheses - to avoid conflicts with ISO 646 national character sets.) - - 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 to 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 - - 4.3. C-Kermit as Login Shell - - 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 the [538]Configurations Options document 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). - - 4.4. C-Kermit versus screen and splitvt - - C-Kermit file transfers will probably not work if attemped through the - "splitvt" or GNU "screen" programs 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. - - 4.5. C-Kermit versus DOS Emulators - - 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. - - 4.6. C-Kermit versus Job Control - - Interruption by Ctrl-Z makes Unix C-Kermit try to suspend itself with - kill(0,SIGTSTP), but only on platforms 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. - - 4.7. Dates and Times - - Unix time conversion functions typically apply locale rules to return - local time in terms of any seasonal time zone change in effect for the - given date. The diffdate function assumes that the same timezone rules - are in effect for both dates, but a date with timezone information - will be converted to the local time zone in effect at the given time, - e.g., a GMT specification will produce either a Standard Time or - Daylight Savings Time, depending on which applies at the given time. - An example using the 2001 seasonal change from EDT (-0400) to EST - (-0500): - - C-Kermit> DATE 20011028 05:01:02 GMT ; EDT - 20011028 01:01:02 - C-Kermit> DATE 20011028 06:01:02 GMT ; EST - 20011028 01:01:02 - C-Kermit> - - but the implicit change in timezone offset is not recognized: - - C-Kermit> echo \fdiffdate(20011028 05:01:02 GMT, 20011028 06:01:02 GMT) - +0:00 - C-Kermit> - - Date/time arithmetic, offsets, delta times, and timezone support are - new to C-Kermit 8.0, and might be expected to evolve and improve in - subsequent releases. - - On some platforms, files downloaded with HTTP receive the current - timestamp, rather than the HTTP "Last Modified" time (this can be - fixed by including utime.h, e.g. in SunOS and Tru64...). - - 4.8. Pseudoterminals - - The SSH and PTY commands work by assigning a pseudoterminal and - reading and writing from it. Performance varies according to the - specific platform ranging from very fast to very flow. - - SSH and PTY commands can fail if (a) all pseudoterminals are in use; - or (b) you do not have read/write access to the pseudoterminal that - was assigned. An example of (b) was reported with the Zipslack - Slackware Linux distribution, in which the pseudoterminals were - created with crw-r--r-- permission, instead of crw-rw-rw-. - - 4.9. Miscellaneous - - * 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). - * 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 (and definitely in modern - bash versions). - ________________________________________________________________________ - - 5. INITIALIZATION AND COMMAND FILES - - [ [539]Top ] [ [540]Contents ] [ [541]Next ] [ [542]Previous ] - - 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 the [543]C-Kermit for Unix - Installation Instructions). - - 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 - - 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 - - [ [544]Top ] [ [545]Contents ] [ [546]Next ] [ [547]Previous ] - - 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 and later: - - 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 [548]Section 9.5 of the Installation - Instructions, plus any platform-specific notes in [549]Section 3 - above. - ________________________________________________________________________ - - 7. COMMUNICATIONS AND DIALING - - [ [550]Top ] [ [551]Contents ] [ [552]Next ] [ [553]Previous ] - - 7.1. Serial Ports and Modems - - 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. - - As of version 7.0, C-Kermit makes 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. - 4. Use C-Kermit new EXEC /REDIRECT command. - - 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. If MODEM HANGUP-METHOD is set to RS232-SIGNAL, change it to - MODEM-COMMAND. Or vice-versa. - 6. Try SET DIAL HANGUP OFF before the DIAL command. Also, SET DIAL - DISPLAY ON to watch what's happening. See [554]Section 8 of the - [555]Installation Instructions. - 7. Read pages 50-67 of [556]Using C-Kermit. - 8. 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). - - 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 C-Kermit - 7.0 and later, you can make Kermit connections "though" dk or dkcu - using "set line /pty". - - 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 CLOSE - command to close the device, and then another SET LINE command to - re-open the same device. Or rebuild your version of Kermit with the - -DCLSOPN compile-time switch. - - 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 - platform-dependent coding and #ifdefs, and a new routine and interface - between the platform-dependent and platform-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. - - 7.2. Network Connections - - 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. - ________________________________________________________________________ - - 8. HARDWARE FLOW CONTROL - - [ [557]Top ] [ [558]Contents ] [ [559]Next ] [ [560]Previous ] - - 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. - - WARNING: When hardware flow control is available, and you enable in - Kermit on a device that is not receiving the CTS signal, Kermit can - hang waiting for CTS to come up. This is most easily seen when the - local serial port has nothing plugged in to it, or is connected to an - external modem that is powered off. - ________________________________________________________________________ - - 9. TERMINAL CONNECTION AND KEY MAPPING - - [ [561]Top ] [ [562]Contents ] [ [563]Next ] [ [564]Previous ] - - C-Kermit is not a terminal emulator. Refer to page 147 of [565]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: - - [566]http://dickey.his.com/xterm/xterm.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 - - [ [567]Top ] [ [568]Contents ] [ [569]Next ] [ [570]Previous ] - - If uploads (or downloads) fail immediately, give the CAUTIOUS command - to Kermit and try again. If they still fail, then try SET PREFIXING - ALL. If they still fail, try SET PARITY SPACE. If they still fail, try - ROBUST. - - If reception (particularly of large files and/or binary files) begins - successfully but then fail constently after a certain amount of bytes - have been sent, check: - - * Your ulimit ("ulimit -a") - * The amount of available space on the target disk ("df ." or "df -k - .") - * Your personal disk quota (platform- and site-dependent) - * The maximum file size on the receiver's file system (e.g. 2GB in - old verions the Linux VFS file system, and/or in applications that - have not been recoded to use new "large file" APIs). - * If it's an NFS-mounted disk (if so, try uploading to a local disk) - * Is there an "idle limit" on the receiving end? - - If none of these seem to explain it, then the problem is not size - related, but reflects some clash between the file contents and the - characteristics of the connection, in which case follow the - instructions in the first paragraph of this section. - - Suppose two copies of Kermit are receiving files into the same - directory, and the files have the same name, e.g. "foo.bar". Whichever - one starts first opens an output file called "foo.bar". The second one - sees there is already a foo.bar file, and so renames the existing - foo.bar to foo.bar.~1~ (or whatever). When the first file has been - received completely, Kermit goes to change its modification time and - permissions to those given by the file sender in the Attribute packet. - But in Unix, the APIs for doing this take a filename, not a file - descriptor. Since the first Kermit's file has been renamed, and the - second Kermit is using the original name, the first Kermit changes the - modtime and permissions of the second Kermit's file, not its own. - Although there might be a way to work around this in the code, e.g. - using inode numbers to keep track of which file is which, this would - be tricky and most likely not very portable. It's better to set up - your application to prevent such things from happening, which is easy - enough using the script language, filename templates, etc. - - 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. - - 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. - - 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, BRIEF, or anything else - other than FULLSCREEN, and/or rebuild without -DCK_CURSES, and without - linking with (termlib and) curses. Note: This problem seemed to have - escalated in C-Kermit 7.0, 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. - - 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. - ________________________________________________________________________ - - 11. EXTERNAL FILE TRANSFER PROTOCOLS - - [ [571]Top ] [ [572]Contents ] [ [573]Next ] [ [574]Previous ] - - SECTION CONTENTS - - 11.1. [575]C-Kermit as an External Protocol - 11.2. [576]Invoking External Protocols from C-Kermit - - 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 (or making a network connection from it). 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. - - 11.1. C-KERMIT AS AN EXTERNAL PROTOCOL - - [ [577]Top ] [ [578]Contents ] [ [579]Section Contents ] [ [580]Next ] - - (This section deleted; see [581]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 filename rz - Kermit kermit -s filename 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 filename 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 (default in 8.0) - 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 - - [ [582]Top ] [ [583]Contents ] [ [584]Section Contents ] [ - [585]Previous ] - - (This section is obsolete, but not totally useless. See Chapter 14 - of [586]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 pass - it along 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 (but is redundant since C-Kermit 6.0, which now has - built-in support for external protocols via its SET PROTOCOL command). - - Note that external protocols can be used on C-Kermit SET LINE or SET - HOST connections only if they operate through standard input and - standard output. If they open their own connections, Kermit can't - redirect them over its own connection. - ________________________________________________________________________ - - 12. SECURITY - - [ [587]Top ] [ [588]Contents ] [ [589]Next ] [ [590]Previous ] - - As of version 7.0, C-Kermit supports a wide range of security options - for authentication and encryption: Kerberos 4, Kerberos 5 / GSSAPI, - SSL/TLS, and SRP. See the separate [591]security document for details. - ________________________________________________________________________ - - 13. MISCELLANEOUS USER REPORTS - - [ [592]Top ] [ [593]Contents ] [ [594]Next ] [ [595]Previous ] - -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 - - [ [596]Top ] [ [597]Contents ] [ [598]Next ] [ [599]Previous ] - - 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 document; 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, [600]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, [601]www.stallion.com, in the - /drivers/ata5/UnixWare directory. - - [ [602]Top ] [ [603]Contents ] [ [604]C-Kermit Home ] [ [605]C-Kermit - 8.0 Overview ] [ [606]Kermit Home ] - _________________________________________________________________ - - C-Kermit 8.0 Unix Hints and Tips / [607]The Kermit Project / - [608]Columbia University / [609]kermit@columbia.edu - -References - - 1. http://www.columbia.edu/kermit/ - 2. http://www.columbia.edu/ - 3. http://www.columbia.edu/kermit/ckubwr.html - 4. mailto:kermit-support@columbia.edu - 5. http://www.columbia.edu/kermit/ckermit.html - 6. http://www.columbia.edu/kermit/ckuins.html - 7. http://www.columbia.edu/kermit/ckututor.html - 8. http://www.columbia.edu/kermit/ckubwr.html#x1 - 9. http://www.columbia.edu/kermit/ckubwr.html#x2 - 10. http://www.columbia.edu/kermit/ckubwr.html#x3 - 11. http://www.columbia.edu/kermit/ckubwr.html#x4 - 12. http://www.columbia.edu/kermit/ckubwr.html#x5 - 13. http://www.columbia.edu/kermit/ckubwr.html#x6 - 14. http://www.columbia.edu/kermit/ckubwr.html#x7 - 15. http://www.columbia.edu/kermit/ckubwr.html#x8 - 16. http://www.columbia.edu/kermit/ckubwr.html#x9 - 17. http://www.columbia.edu/kermit/ckubwr.html#x10 - 18. http://www.columbia.edu/kermit/ckubwr.html#x11 - 19. http://www.columbia.edu/kermit/ckubwr.html#x12 - 20. http://www.columbia.edu/kermit/ckubwr.html#x13 - 21. http://www.columbia.edu/kermit/ckubwr.html#x14 - 22. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 23. http://www.columbia.edu/kermit/ckubwr.html#x3.18 - 24. http://www.columbia.edu/kermit/ckubwr.html#x3.19 - 25. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 26. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 27. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 28. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 29. http://www.columbia.edu/kermit/ckubwr.html#x3.13 - 30. http://www.columbia.edu/kermit/ckubwr.html#top - 31. http://www.columbia.edu/kermit/ckubwr.html#contents - 32. http://www.columbia.edu/kermit/ckubwr.html#x2 - 33. http://www.columbia.edu/kermit/ckubwr.html#x1.1 - 34. http://www.columbia.edu/kermit/ckubwr.html#x1.2 - 35. http://www.columbia.edu/kermit/ckubwr.html#x1.3 - 36. http://www.columbia.edu/kermit/ckubwr.html#x1.4 - 37. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 38. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 39. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 40. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 41. http://www.columbia.edu/kermit/ckcbwr.html - 42. mailto:kermit-support@columbia.edu - 43. http://www.columbia.edu/kermit/ckubwr.html#top - 44. http://www.columbia.edu/kermit/ckubwr.html#contents - 45. http://www.columbia.edu/kermit/ckubwr.html#x1.2 - 46. http://www.columbia.edu/kermit/ck60manual.html - 47. http://www.columbia.edu/kermit/ckermit70.html - 48. http://www.columbia.edu/kermit/ckermit80.html - 49. http://www.columbia.edu/kermit/ckubwr.html#top - 50. http://www.columbia.edu/kermit/ckubwr.html#contents - 51. http://www.columbia.edu/kermit/ckubwr.html#x1 - 52. http://www.columbia.edu/kermit/ckubwr.html#x1.3 - 53. http://www.columbia.edu/kermit/ckubwr.html#x1.1 - 54. http://www.columbia.edu/kermit/support.html - 55. http://www.columbia.edu/kermit/ckubwr.html#top - 56. http://www.columbia.edu/kermit/ckubwr.html#contents - 57. http://www.columbia.edu/kermit/ckubwr.html#x1 - 58. http://www.columbia.edu/kermit/ckubwr.html#x1.4 - 59. http://www.columbia.edu/kermit/ckubwr.html#x1.2 - 60. http://www.columbia.edu/kermit/ckubwr.html#top - 61. http://www.columbia.edu/kermit/ckubwr.html#contents - 62. http://www.columbia.edu/kermit/ckubwr.html#x1 - 63. http://www.columbia.edu/kermit/ckubwr.html#x1.3 - 64. http://www.columbia.edu/kermit/ckubwr.html#top - 65. http://www.columbia.edu/kermit/ckubwr.html#contents - 66. http://www.columbia.edu/kermit/ckubwr.html#x3 - 67. http://www.columbia.edu/kermit/ckubwr.html#x1 - 68. http://www.columbia.edu/kermit/ckubwr.html#top - 69. http://www.columbia.edu/kermit/ckubwr.html#contents - 70. http://www.columbia.edu/kermit/ckubwr.html#x4 - 71. http://www.columbia.edu/kermit/ckubwr.html#x2 - 72. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 73. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 74. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 75. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 76. http://www.columbia.edu/kermit/ckubwr.html#x3.4 - 77. http://www.columbia.edu/kermit/ckubwr.html#x3.5 - 78. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 79. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 80. http://www.columbia.edu/kermit/ckubwr.html#x3.8 - 81. http://www.columbia.edu/kermit/ckubwr.html#x3.9 - 82. http://www.columbia.edu/kermit/ckubwr.html#x3.10 - 83. http://www.columbia.edu/kermit/ckubwr.html#x3.11 - 84. http://www.columbia.edu/kermit/ckubwr.html#x3.12 - 85. http://www.columbia.edu/kermit/ckubwr.html#x3.13 - 86. http://www.columbia.edu/kermit/ckubwr.html#x3.14 - 87. http://www.columbia.edu/kermit/ckubwr.html#x3.15 - 88. http://www.columbia.edu/kermit/ckubwr.html#x3.16 - 89. http://www.columbia.edu/kermit/ckubwr.html#x3.17 - 90. http://www.columbia.edu/kermit/ckubwr.html#x3.18 - 91. http://www.columbia.edu/kermit/ckubwr.html#x3.19 - 92. http://www.columbia.edu/kermit/ckubwr.html#x3.20 - 93. http://www.faqs.org/ - 94. http://aplawrence.com/Unixart/newtounix.html - 95. http://www.columbia.edu/kermit/x3 - 96. mailto:kermit-support@columbia.edu - 97. http://www.columbia.edu/kermit/support.html - 98. http://www.columbia.edu/kermit/ckubwr.html#top - 99. http://www.columbia.edu/kermit/ckubwr.html#contents - 100. http://www.columbia.edu/kermit/ckubwr.html#x3 - 101. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 102. http://www.pcunix.com/ - 103. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1 - 104. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2 - 105. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3 - 106. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4 - 107. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5 - 108. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6 - 109. http://www.columbia.edu/kermit/ckubwr.html#top - 110. http://www.columbia.edu/kermit/ckubwr.html#contents - 111. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 112. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2 - 113. http://www.columbia.edu/kermit/ckubwr.html#top - 114. http://www.columbia.edu/kermit/ckubwr.html#contents - 115. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 116. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3 - 117. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1 - 118. http://www.linmodems.org/ - 119. http://www.microsoft.com/hwdev/platform/PCdesign/LR/default.asp - 120. http://www.columbia.edu/kermit/ckubwr.html#top - 121. http://www.columbia.edu/kermit/ckubwr.html#contents - 122. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 123. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4 - 124. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2 - 125. http://www.idir.net/~gromitkc/winmodem.html - 126. http://www.digi.com/ - 127. http://www.columbia.edu/kermit/ckubwr.html#top - 128. http://www.columbia.edu/kermit/ckubwr.html#contents - 129. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 130. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5 - 131. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3 - 132. http://www.columbia.edu/kermit/ckubwr.html#top - 133. http://www.columbia.edu/kermit/ckubwr.html#contents - 134. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 135. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6 - 136. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4 - 137. http://www.columbia.edu/kermit/ckubwr.html#top - 138. http://www.columbia.edu/kermit/ckubwr.html#contents - 139. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 140. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5 - 141. http://www.columbia.edu/kermit/ckubwr.html#top - 142. http://www.columbia.edu/kermit/ckubwr.html#contents - 143. http://www.columbia.edu/kermit/ckubwr.html#x3 - 144. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 145. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 146. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1 - 147. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2 - 148. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3 - 149. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4 - 150. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5 - 151. http://www.emerson.emory.edu/services/aix-faq/ - 152. http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html - 153. http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html - 154. http://aixpdslib.seas.ucla.edu/ - 155. http://www.rootvg.net (AIX history)/ - 156. ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1 - 157. ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix - 158. news:comp.unix.aix - 159. http://www.columbia.edu/kermit/ckubwr.html#top - 160. http://www.columbia.edu/kermit/ckubwr.html#contents - 161. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 162. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2 - 163. http://www.columbia.edu/kermit/ckubwr.html#top - 164. http://www.columbia.edu/kermit/ckubwr.html#contents - 165. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 166. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3 - 167. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1 - 168. http://www.columbia.edu/kermit/security.html#servers - 169. http://www.columbia.edu/kermit/ckubwr.html#top - 170. http://www.columbia.edu/kermit/ckubwr.html#contents - 171. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 172. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4 - 173. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2 - 174. http://service.software.ibm.com/rs6000/ - 175. http://www.columbia.edu/kermit/ckubwr.html#top - 176. http://www.columbia.edu/kermit/ckubwr.html#contents - 177. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 178. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5 - 179. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3 - 180. http://www.columbia.edu/kermit/ckubwr.html#top - 181. http://www.columbia.edu/kermit/ckubwr.html#contents - 182. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 183. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4 - 184. http://www.columbia.edu/kermit/ckubwr.html#top - 185. http://www.columbia.edu/kermit/ckubwr.html#contents - 186. http://www.columbia.edu/kermit/ckubwr.html#x3 - 187. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 188. http://www.columbia.edu/kermit/ckubwr.html#x3.1 - 189. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0 - 190. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1 - 191. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2 - 192. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3 - 193. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4 - 194. http://www.columbia.edu/kermit/ckubwr.html#x3.2.5 - 195. news:comp.sys.hp.hpux - 196. http://www.columbia.edu/kermit/ckubwr.html#top - 197. http://www.columbia.edu/kermit/ckubwr.html#contents - 198. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 199. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1 - 200. http://www.columbia.edu/kermit/ckubwr.html#top - 201. http://www.columbia.edu/kermit/ckubwr.html#contents - 202. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 203. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2 - 204. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0 - 205. ftp://kermit.columbia.edu/kermit/f/makefile - 206. http://www.columbia.edu/kermit/ckubwr.html#top - 207. http://www.columbia.edu/kermit/ckubwr.html#contents - 208. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 209. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3 - 210. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1 - 211. http://www.columbia.edu/kermit/ckubwr.html#top - 212. http://www.columbia.edu/kermit/ckubwr.html#contents - 213. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 214. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4 - 215. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2 - 216. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1 - 217. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2 - 218. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3 - 219. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4 - 220. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5 - 221. http://www.columbia.edu/kermit/ckubwr.html#top - 222. http://www.columbia.edu/kermit/ckubwr.html#contents - 223. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 224. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2 - 225. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2 - 226. http://www.columbia.edu/kermit/ckubwr.html#top - 227. http://www.columbia.edu/kermit/ckubwr.html#contents - 228. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4 - 229. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3 - 230. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1 - 231. http://www.columbia.edu/kermit/ckubwr.html#top - 232. http://www.columbia.edu/kermit/ckubwr.html#contents - 233. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4 - 234. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4 - 235. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2 - 236. http://www.columbia.edu/kermit/ckubwr.html#top - 237. http://www.columbia.edu/kermit/ckubwr.html#contents - 238. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4 - 239. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5 - 240. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3 - 241. http://www.columbia.edu/kermit/ckubwr.html#top - 242. http://www.columbia.edu/kermit/ckubwr.html#contents - 243. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4 - 244. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4 - 245. http://www.columbia.edu/kermit/ckubwr.html#top - 246. http://www.columbia.edu/kermit/ckubwr.html#contents - 247. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 248. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4 - 249. http://www.columbia.edu/kermit/ckubwr.html#top - 250. http://www.columbia.edu/kermit/ckubwr.html#contents - 251. http://www.columbia.edu/kermit/ckubwr.html#x3 - 252. http://www.columbia.edu/kermit/ckubwr.html#x3.4 - 253. http://www.columbia.edu/kermit/ckubwr.html#x3.2 - 254. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1 - 255. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2 - 256. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3 - 257. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4 - 258. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5 - 259. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6 - 260. news:comp.os.linux.misc - 261. news:comp.os.linux.answers - 262. http://www.tldp.org/ - 263. http://www.tldp.org/FAQ/Linux-FAQ.html - 264. http://www.tldp.org/HOWTO/Serial-HOWTO.html - 265. http://tldp.org/HOWTO/Modem-HOWTO.html - 266. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO - 267. ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO - 268. http://www.tldp.org/HOWTO/ - 269. http://www.tldp.org/hmirrors.html - 270. http://www.redhat.com/apps/support/ - 271. http://www.debian.org/support - 272. http://www.slackware.com/support/ - 273. http://www.caldera.com/support/ - 274. http://www.suse.com/support/ - 275. http://www.mandrake.com/support/ - 276. http://www.turbolinux.com/support/ - 277. http://www.linmodems.org/ - 278. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 279. http://linux.dreamtime.org/decnet/ - 280. mailto:kermit-support@columbia.edu - 281. http://www.linmodems.org/ - 282. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2 - 283. http://www.columbia.edu/kermit/security.html#servers - 284. http://www.columbia.edu/kermit/sshclient.html - 285. http://www.columbia.edu/kermit/ckubwr.html#top - 286. http://www.columbia.edu/kermit/ckubwr.html#contents - 287. http://www.columbia.edu/kermit/ckubwr.html#x3 - 288. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2 - 289. http://www.columbia.edu/kermit/ckubwr.html#top - 290. http://www.columbia.edu/kermit/ckubwr.html#contents - 291. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 292. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3 - 293. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1 - 294. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 295. http://www.columbia.edu/kermit/ckubwr.html#x6 - 296. http://www.columbia.edu/kermit/ckubwr.html#x7 - 297. http://www.columbia.edu/kermit/ckubwr.html#x8 - 298. http://www.columbia.edu/kermit/ckuins.html#x10 - 299. http://www.columbia.edu/kermit/ckuins.html#x11 - 300. http://www.columbia.edu/kermit/ckuins.html - 301. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 302. http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html - 303. http://www.columbia.edu/kermit/ckubwr.html#top - 304. http://www.columbia.edu/kermit/ckubwr.html#contents - 305. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 306. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4 - 307. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2 - 308. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5 - 309. http://www.columbia.edu/kermit/ckfaq.html#term - 310. http://dickey.his.com/xterm/xterm.html - 311. http://dickey.his.com/xterm/xterm.html - 312. ftp://kermit.columbia.edu/kermit/f/xmodmap.txt - 313. http://www.columbia.edu/kermit/ckubwr.html#top - 314. http://www.columbia.edu/kermit/ckubwr.html#contents - 315. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 316. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5 - 317. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3 - 318. http://www.columbia.edu/kermit/ckubwr.html#top - 319. http://www.columbia.edu/kermit/ckubwr.html#contents - 320. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 321. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6 - 322. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4 - 323. http://www.columbia.edu/kermit/ckermit.html - 324. mailto:kermit-support@columbia.edu - 325. http://www.redhat.com/support/errata/RHBA-2001-153.html - 326. news:comp.protocols.kermit.misc - 327. http://www.columbia.edu/kermit/ckubwr.html#top - 328. http://www.columbia.edu/kermit/ckubwr.html#contents - 329. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 330. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5 - 331. http://www.columbia.edu/kermit/ckubwr.html#top - 332. http://www.columbia.edu/kermit/ckubwr.html#contents - 333. http://www.columbia.edu/kermit/ckubwr.html#x3 - 334. http://www.columbia.edu/kermit/ckubwr.html#x3.5 - 335. http://www.columbia.edu/kermit/ckubwr.html#x3.3 - 336. http://www.columbia.edu/kermit/ckubwr.html#top - 337. http://www.columbia.edu/kermit/ckubwr.html#contents - 338. http://www.columbia.edu/kermit/ckubwr.html#x3 - 339. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 340. http://www.columbia.edu/kermit/ckubwr.html#x3.4 - 341. news:comp.os.qnx - 342. http://www.columbia.edu/kermit/gkermit.html - 343. http://www.columbia.edu/kermit/ckuins.html#x10 - 344. http://www.columbia.edu/kermit/ckuins.html - 345. http://www.columbia.edu/kermit/ckubwr.html#top - 346. http://www.columbia.edu/kermit/ckubwr.html#contents - 347. http://www.columbia.edu/kermit/ckubwr.html#x3 - 348. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 349. http://www.columbia.edu/kermit/ckubwr.html#x3.5 - 350. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1 - 351. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2 - 352. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3 - 353. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4 - 354. http://www.columbia.edu/kermit/ckubwr.html#x3.10 - 355. http://aplawrence.com/SCOFAQ/ - 356. http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl - 357. http://www.zenez.com/cgi-bin/scouw7faq/faq.pl - 358. http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl - 359. http://pcunix.com/Unixart/modems.html - 360. http://www.freebird.org/faq/ - 361. http://www.freebird.org/faq/developer.html - 362. http://support.caldera.com/caldera - 363. http://stage.caldera.com/ta/ - 364. http://aplawrence.com/newtosco.html - 365. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5 - 366. http://www.columbia.edu/kermit/ckfaq.html#term - 367. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 368. http://www.columbia.edu/kermit/ckubwr.html#top - 369. http://www.columbia.edu/kermit/ckubwr.html#contents - 370. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 371. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1 - 372. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c - 373. http://www.columbia.edu/kermit/ckubwr.html#top - 374. http://www.columbia.edu/kermit/ckubwr.html#contents - 375. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 376. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3 - 377. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1 - 378. http://www.digi.com/ - 379. ftp://ftp.fu-berlin.de/pub/unix/driver/fas - 380. http://www.columbia.edu/kermit/ckubwr.html#x14 - 381. http://www.sco.com/ - 382. ftp://ftp.sco.com/ - 383. http://www.columbia.edu/kermit/ckubwr.html#top - 384. http://www.columbia.edu/kermit/ckubwr.html#contents - 385. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 386. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4 - 387. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2 - 388. http://www.columbia.edu/kermit/ckubwr.html#x3.10 - 389. http://www.columbia.edu/kermit/ckubwr.html#top - 390. http://www.columbia.edu/kermit/ckubwr.html#contents - 391. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 392. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3 - 393. http://www.columbia.edu/kermit/ckubwr.html#top - 394. http://www.columbia.edu/kermit/ckubwr.html#contents - 395. http://www.columbia.edu/kermit/ckubwr.html#x3 - 396. http://www.columbia.edu/kermit/ckubwr.html#x3.8 - 397. http://www.columbia.edu/kermit/ckubwr.html#x3.6 - 398. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1 - 399. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2 - 400. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3 - 401. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4 - 402. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5 - 403. news:comp.unix.solaris - 404. http://access1.sun.com/ - 405. http://docs.sun.com/ - 406. http://www.sunhelp.com/ - 407. http://www.wins.uva.nl/pub/solaris/solaris2/ - 408. http://www.wins.uva.nl/cgi-bin/sfaq.cgi - 409. ftp://ftp.wins.uva.nl/pub/solaris - 410. http://www.science.uva.nl/pub/solaris/solaris2.html - 411. http://www.stokely.com/ - 412. http://www.stokely.com/unix.sysadm.resources/faqs.sun.html - 413. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 414. http://www.columbia.edu/kermit/ckubwr.html#top - 415. http://www.columbia.edu/kermit/ckubwr.html#contents - 416. http://www.columbia.edu/kermit/ckubwr.html#x3 - 417. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 418. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2 - 419. http://www.columbia.edu/kermit/ckubwr.html#top - 420. http://www.columbia.edu/kermit/ckubwr.html#contents - 421. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 422. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3 - 423. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1 - 424. http://www.columbia.edu/kermit/ckubwr.html#top - 425. http://www.columbia.edu/kermit/ckubwr.html#contents - 426. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 427. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4 - 428. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2 - 429. http://www.columbia.edu/kermit/ckubwr.html#top - 430. http://www.columbia.edu/kermit/ckubwr.html#contents - 431. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 432. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5 - 433. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3 - 434. news:comp.os.vms - 435. http://www.columbia.edu/kermit/ckubwr.html#top - 436. http://www.columbia.edu/kermit/ckubwr.html#contents - 437. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 438. http://www.columbia.edu/kermit/ckubwr.html#x3.7.6 - 439. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4 - 440. http://www.columbia.edu/kermit/ckubwr.html#top - 441. http://www.columbia.edu/kermit/ckubwr.html#contents - 442. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 443. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5 - 444. http://www.columbia.edu/kermit/ckubwr.html#top - 445. http://www.columbia.edu/kermit/ckubwr.html#contents - 446. http://www.columbia.edu/kermit/ckubwr.html#x3 - 447. http://www.columbia.edu/kermit/ckubwr.html#x3.9 - 448. http://www.columbia.edu/kermit/ckubwr.html#x3.7 - 449. http://www.stokely.com/ - 450. http://access1.sun.com/ - 451. http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt - 452. ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref - 453. ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref - 454. http://www.columbia.edu/kermit/ckubwr.html#top - 455. http://www.columbia.edu/kermit/ckubwr.html#contents - 456. http://www.columbia.edu/kermit/ckubwr.html#x3 - 457. http://www.columbia.edu/kermit/ckubwr.html#x3.10 - 458. http://www.columbia.edu/kermit/ckubwr.html#x3.8 - 459. news:comp.unix.ultrix - 460. news:comp.sys.dec - 461. http://www.columbia.edu/kermit/ckubwr.html#top - 462. http://www.columbia.edu/kermit/ckubwr.html#contents - 463. http://www.columbia.edu/kermit/ckubwr.html#x3 - 464. http://www.columbia.edu/kermit/ckubwr.html#x3.11 - 465. http://www.columbia.edu/kermit/ckubwr.html#x3.9 - 466. http://www.freebird.org/ - 467. http://www.freebird.org/faq/ - 468. news:comp.unix.unixware.misc - 469. news:comp.unix.sco.misc - 470. http://www.columbia.edu/kermit/ckubwr.html#x3.0 - 471. ftp://kermit.columbia.edu/kermit/f/ckutio.c - 472. http://www.columbia.edu/kermit/ckubwr.html#top - 473. http://www.columbia.edu/kermit/ckubwr.html#contents - 474. http://www.columbia.edu/kermit/ckubwr.html#x3 - 475. http://www.columbia.edu/kermit/ckubwr.html#x3.12 - 476. http://www.columbia.edu/kermit/ckubwr.html#x3.10 - 477. http://www.columbia.edu/kermit/ckubwr.html#top - 478. http://www.columbia.edu/kermit/ckubwr.html#contents - 479. http://www.columbia.edu/kermit/ckubwr.html#x3 - 480. http://www.columbia.edu/kermit/ckubwr.html#x3.13 - 481. http://www.columbia.edu/kermit/ckubwr.html#x3.11 - 482. http://www.columbia.edu/kermit/ckubwr.html#top - 483. http://www.columbia.edu/kermit/ckubwr.html#contents - 484. http://www.columbia.edu/kermit/ckubwr.html#x3 - 485. http://www.columbia.edu/kermit/ckubwr.html#x3.14 - 486. http://www.columbia.edu/kermit/ckubwr.html#x3.12 - 487. http://www.columbia.edu/kermit/ckubwr.html#top - 488. http://www.columbia.edu/kermit/ckubwr.html#contents - 489. http://www.columbia.edu/kermit/ckubwr.html#x3 - 490. http://www.columbia.edu/kermit/ckubwr.html#x3.15 - 491. http://www.columbia.edu/kermit/ckubwr.html#x3.13 - 492. news:comp.sys.sgi.misc - 493. news:comp.sys.sgi.admin - 494. http://www.sgi.com/ - 495. http://www-viz.tamu.edu/~sgi-faq/ - 496. ftp://viz.tamu.edu/pub/sgi/faq/ - 497. http://www.columbia.edu/kermit/ckuins.html - 498. http://freeware.sgi.com/Installable/gcc-2.95.2.html - 499. http://freeware.sgi.com/Installable/gcc-2.95.2.html - 500. http://www.columbia.edu/kermit/ckubwr.html#top - 501. http://www.columbia.edu/kermit/ckubwr.html#contents - 502. http://www.columbia.edu/kermit/ckubwr.html#x3 - 503. http://www.columbia.edu/kermit/ckubwr.html#x3.16 - 504. http://www.columbia.edu/kermit/ckubwr.html#x3.14 - 505. news:comp.sys.be - 506. http://www.columbia.edu/kermit/ckubwr.html#top - 507. http://www.columbia.edu/kermit/ckubwr.html#contents - 508. http://www.columbia.edu/kermit/ckubwr.html#x3 - 509. http://www.columbia.edu/kermit/ckubwr.html#x3.17 - 510. http://www.columbia.edu/kermit/ckubwr.html#x3.15 - 511. http://www.columbia.edu/kermit/ckubwr.html#top - 512. http://www.columbia.edu/kermit/ckubwr.html#contents - 513. http://www.columbia.edu/kermit/ckubwr.html#x3 - 514. http://www.columbia.edu/kermit/ckubwr.html#x3.18 - 515. http://www.columbia.edu/kermit/ckubwr.html#x3.16 - 516. http://www.columbia.edu/kermit/ckubwr.html#top - 517. http://www.columbia.edu/kermit/ckubwr.html#contents - 518. http://www.columbia.edu/kermit/ckubwr.html#x3 - 519. http://www.columbia.edu/kermit/ckubwr.html#x3.19 - 520. http://www.columbia.edu/kermit/ckubwr.html#x3.17 - 521. http://www.columbia.edu/kermit/ckubwr.html#top - 522. http://www.columbia.edu/kermit/ckubwr.html#contents - 523. http://www.columbia.edu/kermit/ckubwr.html#x3 - 524. http://www.columbia.edu/kermit/ckubwr.html#x3.20 - 525. http://www.columbia.edu/kermit/ckubwr.html#x3.18 - 526. http://www.keyspan.com/products/usb/adapter/ - 527. http://www.columbia.edu/kermit/ckuins.html - 528. http://cerebus.sandiego.edu/~jerry/UnixTips/ - 529. http://www.columbia.edu/kermit/ckubwr.html#top - 530. http://www.columbia.edu/kermit/ckubwr.html#contents - 531. http://www.columbia.edu/kermit/ckubwr.html#x3 - 532. http://www.columbia.edu/kermit/ckubwr.html#x3.19 - 533. http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg00000.html - 534. http://www.columbia.edu/kermit/ckubwr.html#top - 535. http://www.columbia.edu/kermit/ckubwr.html#contents - 536. http://www.columbia.edu/kermit/ckubwr.html#x5 - 537. http://www.columbia.edu/kermit/ckubwr.html#x3 - 538. http://www.columbia.edu/kermit/ckccfg.html - 539. http://www.columbia.edu/kermit/ckubwr.html#top - 540. http://www.columbia.edu/kermit/ckubwr.html#contents - 541. http://www.columbia.edu/kermit/ckubwr.html#x6 - 542. http://www.columbia.edu/kermit/ckubwr.html#x4 - 543. http://www.columbia.edu/kermit/ckuins.html - 544. http://www.columbia.edu/kermit/ckubwr.html#top - 545. http://www.columbia.edu/kermit/ckubwr.html#contents - 546. http://www.columbia.edu/kermit/ckubwr.html#x7 - 547. http://www.columbia.edu/kermit/ckubwr.html#x5 - 548. http://www.columbia.edu/kermit/ckuins.html#9.5 - 549. http://www.columbia.edu/kermit/ckubwr.html#x3 - 550. http://www.columbia.edu/kermit/ckubwr.html#top - 551. http://www.columbia.edu/kermit/ckubwr.html#contents - 552. http://www.columbia.edu/kermit/ckubwr.html#x8 - 553. http://www.columbia.edu/kermit/ckubwr.html#x6 - 554. http://www.columbia.edu/kermit/ckuins.html#x8 - 555. http://www.columbia.edu/kermit/ckuins.html - 556. http://www.columbia.edu/kermit/ck60manual.html - 557. http://www.columbia.edu/kermit/ckubwr.html#top - 558. http://www.columbia.edu/kermit/ckubwr.html#contents - 559. http://www.columbia.edu/kermit/ckubwr.html#x9 - 560. http://www.columbia.edu/kermit/ckubwr.html#x7 - 561. http://www.columbia.edu/kermit/ckubwr.html#top - 562. http://www.columbia.edu/kermit/ckubwr.html#contents - 563. http://www.columbia.edu/kermit/ckubwr.html#x10 - 564. http://www.columbia.edu/kermit/ckubwr.html#x8 - 565. http://www.columbia.edu/kermit/ck60manual.html - 566. http://dickey.his.com/xterm/xterm.html - 567. http://www.columbia.edu/kermit/ckubwr.html#top - 568. http://www.columbia.edu/kermit/ckubwr.html#contents - 569. http://www.columbia.edu/kermit/ckubwr.html#x11 - 570. http://www.columbia.edu/kermit/ckubwr.html#x9 - 571. http://www.columbia.edu/kermit/ckubwr.html#top - 572. http://www.columbia.edu/kermit/ckubwr.html#contents - 573. http://www.columbia.edu/kermit/ckubwr.html#x12 - 574. http://www.columbia.edu/kermit/ckubwr.html#x10 - 575. http://www.columbia.edu/kermit/ckubwr.html#x11.1 - 576. http://www.columbia.edu/kermit/ckubwr.html#x11.2 - 577. http://www.columbia.edu/kermit/ckubwr.html#top - 578. http://www.columbia.edu/kermit/ckubwr.html#contents - 579. http://www.columbia.edu/kermit/ckubwr.html#x11 - 580. http://www.columbia.edu/kermit/ckubwr.html#x11.2 - 581. http://www.columbia.edu/kermit/ck60manual.html - 582. http://www.columbia.edu/kermit/ckubwr.html#top - 583. http://www.columbia.edu/kermit/ckubwr.html#contents - 584. http://www.columbia.edu/kermit/ckubwr.html#x11 - 585. http://www.columbia.edu/kermit/ckubwr.html#x11.1 - 586. http://www.columbia.edu/kermit/ck60manual.html - 587. http://www.columbia.edu/kermit/ckubwr.html#top - 588. http://www.columbia.edu/kermit/ckubwr.html#contents - 589. http://www.columbia.edu/kermit/ckubwr.html#x13 - 590. http://www.columbia.edu/kermit/ckubwr.html#x11 - 591. http://www.columbia.edu/kermit/security.html - 592. http://www.columbia.edu/kermit/ckubwr.html#top - 593. http://www.columbia.edu/kermit/ckubwr.html#contents - 594. http://www.columbia.edu/kermit/ckubwr.html#x14 - 595. http://www.columbia.edu/kermit/ckubwr.html#x12 - 596. http://www.columbia.edu/kermit/ckubwr.html#top - 597. http://www.columbia.edu/kermit/ckubwr.html#contents - 598. http://www.columbia.edu/kermit/ckubwr.html#x15 - 599. http://www.columbia.edu/kermit/ckubwr.html#x14 - 600. mailto:support@stallion.oz.au - 601. http://www.stallion.com/ - 602. http://www.columbia.edu/kermit/ckubwr.html#top - 603. http://www.columbia.edu/kermit/ckubwr.html#contents - 604. http://www.columbia.edu/kermit/ckermit.html - 605. http://www.columbia.edu/kermit/ck80.html - 606. http://www.columbia.edu/kermit/index.html - 607. http://www.columbia.edu/kermit/index.html - 608. http://www.columbia.edu/ - 609. mailto:kermit@columbia.edu