+++ /dev/null
-
- 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\
- <Key>Home: string(0x1b) string("[3~") \n \
- <Key>End: string(0x1b) string("[4~") \n
- vt220*VT100.Translations: #override \n\
- Shift <Key>F1: string("[23~") \n \
- Shift <Key>F2: string("[24~") \n \
- Shift <Key>F3: string("[25~") \n \
- Shift <Key>F4: string("[26~") \n \
- Shift <Key>F5: string("[K~") \n \
- Shift <Key>F6: string("[31~") \n \
- Shift <Key>F7: string("[31~") \n \
- Shift <Key>F8: string("[32~") \n \
- Shift <Key>F9: string("[33~") \n \
- Shift <Key>F10: string("[34~") \n \
- Shift <Key>F11: string("[28~") \n \
- Shift <Key>F12: string("[29~") \n \
- <Key>Print: string(0x1b) string("[32~") \n\
- <Key>Cancel: string(0x1b) string("[33~") \n\
- <Key>Pause: string(0x1b) string("[34~") \n\
- <Key>Insert: string(0x1b) string("[2~") \n\
- <Key>Delete: string(0x1b) string("[3~") \n\
- <Key>Home: string(0x1b) string("[1~") \n\
- <Key>End: string(0x1b) string("[4~") \n\
- <Key>Prior: string(0x1b) string("[5~") \n\
- <Key>Next: string(0x1b) string("[6~") \n\
- <Key>BackSpace: string(0x7f) \n\
- <Key>Num_Lock: string(0x1b) string("OP") \n\
- <Key>KP_Divide: string(0x1b) string("Ol") \n\
- <Key>KP_Multiply: string(0x1b) string("Om") \n\
- <Key>KP_Subtract: string(0x1b) string("OS") \n\
- <Key>KP_Add: string(0x1b) string("OM") \n\
- <Key>KP_Enter: string(0x1b) string("OM") \n\
- <Key>KP_Decimal: string(0x1b) string("On") \n\
- <Key>KP_0: string(0x1b) string("Op") \n\
- <Key>KP_1: string(0x1b) string("Oq") \n\
- <Key>KP_2: string(0x1b) string("Or") \n\
- <Key>KP_3: string(0x1b) string("Os") \n\
- <Key>KP_4: string(0x1b) string("Ot") \n\
- <Key>KP_5: string(0x1b) string("Ou") \n\
- <Key>KP_6: string(0x1b) string("Ov") \n\
- <Key>KP_7: string(0x1b) string("Ow") \n\
- <Key>KP_8: string(0x1b) string("Ox") \n\
- <Key>KP_9: string(0x1b) string("Oy") \n
-
- ! <Key>Up: string(0x1b) string("[A") \n\
- ! <Key>Down: string(0x1b) string("[B") \n\
- ! <Key>Right: string(0x1b) string("[C") \n\
- ! <Key>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<YY> tty<X>p<Y> tty<D>p<p>
- diag:mux<X> diag:mux<D>
- ---------------------------------------------------------------------
- ttyd* dial-in modems ttyd<YY> ttyd<X>p<Y> ttyd<D>p<p>
- diag:ttyd<X>p<Y> diag:ttyd<D>p<p>
- ---------------------------------------------------------------------
- cua* auto-dial out cua<YY> cua<X>p<Y> cua<D>p<p>
- diag:cua<X>p<Y>
- ---------------------------------------------------------------------
- cul* dial-out cul<YY> cul<X>p<Y> cul<D>p<p>
- diag:cul<X>p<Y>
- ---------------------------------------------------------------------
- <X>= LU (Logical Unit) <D>= Devspec (decimal card instance)
- <Y> or <YY> = Port <p>= 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 tty<D>p<d>
- (e.g. tty0p0) device, the carrier signal should be ignored. The
- tty<D>p<d> 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
- ttyd<D>p<d> 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
- <other> LCK..<other> (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 <other> 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 <some recent SuSE distribution>, 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 <leichter@smarts.com>
- 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 <INVALID>
- ...
- 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. <termbits.h> or <sys/termios.h> or <sys/ttydev.h>, 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 <device> 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 <termiox.h> 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
- <sys/termiox.h>), 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 <walter@rent-a-guru.de>
-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 <stdlib.h>
-#include <stdio.h>
-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 <spath@jhunix.hcf.jhu.edu>
- 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 <stdio.h>
-
-/* 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
projects / ckermit.git / blobdiff