Columbia Kermit/kermit.zip/archives/cku200txt.tar/ckubwr.txt

Text File | 2001-12-16 | 247KB | 5,122 lines

                       C-Kermit 8.0 Unix Hints and Tips

     Frank da Cruz
     [1]The Kermit Project, [2]Columbia University

   As of: C-Kermit 8.0.200 12 Dec 2001
   This page last updated: Sun Dec 16 11:35:16 2001 (New York USA Time)

     IF YOU ARE READING A PLAIN-TEXT version of this document, note that
     this file 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 welcome.

   [ [5]C-Kermit ] [ [6]C-Kermit 8.0 Beta Test ] [ [7]Installation
   Instructions ] [ [8]TUTORIAL ]
    ________________________________________________________________________

  CONTENTS

   1. [9]INTRODUCTION
   2. [10]PREBUILT C-KERMIT BINARIES
   3. [11]NOTES ON SPECIFIC UNIX VERSIONS
   4. [12]GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
   5. [13]INITIALIZATION AND COMMAND FILES
   6. [14]COMMUNICATION SPEED SELECTION
   7. [15]COMMUNICATIONS AND DIALING
   8. [16]HARDWARE FLOW CONTROL
   9. [17]TERMINAL CONNECTION AND KEY MAPPING
  10. [18]FILE TRANSFER
  11. [19]EXTERNAL FILE TRANSFER PROTOCOLS
  12. [20]SECURITY
  13. [21]MISCELLANEOUS USER REPORTS
  14. [22]THIRD-PARTY DRIVERS

   Quick Links:   [ [23]Linux ] [ [24]*BSD ] [ [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 (Rhapsody, Darwin)
  3.20. [92]C-KERMIT AND COHERENT

   REFERENCES

   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

   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
   [94]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 [95]send us your suggested fixes or changes. Or
   else just [96]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

   [ [97]Top ] [ [98]Contents ] [ [99]Section Contents ] [ [100]Next ]

   SECTION CONTENTS

  3.0.1. [101]Interrupt Conflicts
  3.0.2. [102]Windows-Specific Hardware
  3.0.3. [103]Modems
  3.0.4. [104]Character Sets
  3.0.5. [105]Keyboard, Screen, and Mouse Access
  3.0.6. [106]Laptops

  3.0.1. Interrupt Conflicts

   [ [107]Top ] [ [108]Contents ] [ [109]Section Contents ] [ [110]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

   [ [111]Top ] [ [112]Contents ] [ [113]Section Contents ] [ [114]Next ]
   [ [115]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 at all on any Unix to our
   knowledge (except Lucent has released a Linux-only driver for one of
   its PCI "software" modems). The self-proclaimed Microsoft PC 97 (or
   later) standard 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 [116]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

   [ [117]Top ] [ [118]Contents ] [ [119]Section Contents ] [ [120]Next ]
   [ [121]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:

  [122]http://www.o2.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 [123]DigiBoard are available for certain Unix platforms
   (typically SCO, maybe Linux) that come with special platform-specific
   drivers.
    ________________________________________________________________________

  3.0.4. Character Sets

   [ [124]Top ] [ [125]Contents ] [ [126]Section Contents ] [ [127]Next ]
   [ [128]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

   [ [129]Top ] [ [130]Contents ] [ [131]Section Contents ] [ [132]Next ]
   [ [133]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

   [ [134]Top ] [ [135]Contents ] [ [136]Section Contents ] [
   [137]Previous ]

   (To be filled in . . .)
    ________________________________________________________________________

  3.1. C-KERMIT AND AIX

   [ [138]Top ] [ [139]Contents ] [ [140]Section Contents ] [ [141]Next ]
   [ [142]Previous ]

   For additional information see:
     * [143]http://www.emerson.emory.edu/services/aix-faq/
     * [144]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
     * [145]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/to
       p.html
     * [146]http://aixpdslib.seas.ucla.edu/
     * [147]http://www.rootvg.net (AIX history)
     * [148]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
     * [149]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/
       aix

   and/or read the [150]comp.unix.aix newsgroup.

   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).

   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.

   Transfers over Telnet connections into AIX 4.3.3 might terminate by
   disconnecting your session, depending on the AIX patch level.
   Solution: in inetd.conf, add the "-a" option to the "telnet" entry:

  telnet  stream  tcp6    nowait  root    /usr/sbin/telnetd      telnetd -a

   At this writing we don't know why, or what the "-a" option does, but
   this setup was recommended by IBM (June 2000).

   Streaming transfers into AIX 4.2 or 4.3 (through the AIX Telnet
   server) have been observed to fail, when exactly the same kind of
   transfers into AIX 4.1 work without incident. The error reported by
   AIX is "interrupted system call". Streaming transfers work perfectly,
   however, if the AIX Telnet server is removed from the picture (e.g, by
   using "set host * 3000" on AIX, or by using Rlogin instead of Telnet).
   They also work perfectly if the Telnet connection is forced into
   binary mode (C-Kermit command "set telopt binary requested
   requested"). In case of file-transfer failure on a Telnet connection
   to AIX 4.2 or 4.3, tell AIX C-Kermit to "set streaming off" and/or
   tell the file sender to prefix all control characters ("set prefixing
   all"). Also be sure that the AIX C-Kermit on the remote end has "set
   flow none" (which is the default). NOTE: Maybe this one can also be
   addressed by starting AIX telnetd with the "-a" option.

   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

   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.

   IMPORTANT: Do NOT try to run AIX 3.x C-Kermit binaries on AIX 4.x (or
   vice versa). Obtain -- or build -- the C-Kermit binary that is
   appropriate for your AIX version. In general, it is always better to
   build from source code.

   WARNING: 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.

   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.

   Note that some RS/6000s (e.g. the IBM PowerServer 320) have
   nonstandard rectangular 10-pin serial ports; the DB-25 connector is
   NOT a serial port; it is a parallel printer port. IBM cables are
   required for the serial ports, (The IBM RT PC also had rectangular
   serial ports -- perhaps the same as these, perhaps different.)

   If you dial in to AIX through a modem that is connected directly to an
   AIX port (e.g. on the 128-port multiplexer) and find that data is
   lost, especially when uploading files to the AIX system (and system
   error logs report buffer overruns on the port):

    1. Make sure the port and modem are BOTH configured for hardware
       (RTS/CTS) flow control. The port is configured somewhere in the
       system configuration, outside of Kermit.
    2. Tell C-Kermit to "set flow keep"; experimentation shows that SET
       FLOW RTS/CTS has no effect when used in remote mode (i.e. on
       /dev/tty, as opposed to a specify port device).

   Several people have reported that C-Kermit (version unspecified)
   causes AIX 4.2 (or later) to "freeze" or "hang" or "halt". No further
   details are known at this time. However:

    1. No user-mode application should ever be able to make AIX or any
       other version of Unix freeze, hang, or halt; if it does, this
       indicates a serious bug in AIX, which should be reported
       immediately to IBM.
    2. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support
       and other AIX bugs are available from IBM at:

  [151]http://service.software.ibm.com/rs6000/
       Downloads -> Software Fixes -> Download FixDist gets an
       application for looking up known problems.

   Other people have reported that after upgrading AIX from 4.1 to 4.2,
   the "ttys hang" when they try to use Kermit. Again, so far no further
   details are available. However, others report that C-Kermit 6.0 works
   fine on both AIX 4.2 and 4.3 if it is rebuilt from source code. Still
   others report that the original C-Kermit 6.0 binaries, built under AIX
   4.1, work perfectly in AIX 4.2 and 4.3.

   More recently, people have reported various kinds of problems running
   a C-Kermit binary built under AIX 4.1 or 4.2 on AIX 4.3. There has
   been some speculation on the newsgroups about a new round binary
   incompatibility between AIX 4.3 and earlier versions -- some even
   suggest renumbered syscalls, but that seems unlikely. Example: a user
   in Germany reported that the C-Kermit 6.0 AIX 4.1 binary would crash
   during file transfer when run on AIX 4.2, but the problems disappeared
   when running a binary that was built on AIX 4.2.

   C-Kermit 6.0.192 and earlier were built by default without "BIGBUFOK"
   defined for AIX, and this limits the maximum size of macros, etc. In
   particular, it affects the alphanumeric page macro (TAPMSG)
   distributed with C-Kermit 6.0. BIGBUFOK should be defined, and it is
   in C-Kermit 6.1 and later. In the meantime use:

  make clean ; make aix???  KFLAGS=-DBIGBUFOK

   Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports
   does not work unless the port number is in the /etc/services file;
   it's not clear from the report whether this is a problem with AIX
   Telnet (in which case it would not affect Kermit), or with the sockets
   library (in which case it would). The purported fix is IBM APAR
   IX61523.

   Many problems reported with bidirectional terminal lines on AIX 3.2.x
   on the RS/6000. Workaround: don't use bidirectional terminal lines, or
   write a shell-script wrapper for Kermit that turns getty off on the
   line before starting Kermit, or before Kermit attempts to do the SET
   LINE. (But note: These problems MIGHT be fixed in C-Kermit 6.0 and
   later.) The commands for turning getty off and on (respectively) are
   /usr/sbin/pdisable and /usr/sbin/penable.

   Reportedly, all versions of IBM AIX use the same (undocumented)
   lockfile conventions as RTAIX. If this is true, the "makes" for PS/2
   AIX and AIX/370 will have to be changed to use the RTAIX convention
   (it may be sufficient to simply add -DRTAIX to the make entry). This
   should not be an issue in C-Kermit 7.0 or later, which now calls the
   AIX ttlock() family of library functions to create, check, and remove
   lockfiles. (But it is not known which versions of AIX prior to 4.1
   have working ttlock() functions; for example, the functions are
   present in AIX 3.2 but do not seem to work).

   C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to
   another won't work right unless you set your local terminal type to
   something other than AIXTERM. When your terminal type is AIXTERM, AIX
   TELNET sends two escapes whenever you type one, and the AIX telnet
   server swallows one of them. This has something to do with the "hft"
   device. This behavior seems to be removed in AIX 3.2 and later.

   Transfer of binary -- and maybe even text -- files can fail on AIX
   3.x. The problem was traced to a facility in AIX whereby a particular
   port can have character-set translation done for it by the tty driver.
   The following advice from a knowledgeable AIX user:

     [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)

   About AIX versions and hardware platforms (from the AIX FAQ):

     * If you are using IBM's xlc (cc) compiler, the default is to use
       the common instruction set, so the same binary will run on both
       RS/6000 and PowerPC.
     * The option -mcpu=common makes GCC use the common instruction set.
       Please note that (unlike xlc) this is *not* the default with GCC
       on AIX.

   A couple of other gotcha's:

     * Use shared libraries. The C runtime can and does change as IBM
       introduces patches. Also this avoids "Netscape syndrome." They
       bound AIX 3 libraries into their browser. Although AIX 3 binaries
       will run on AIX 4, the AIX 3 libraries aren't totally compatible.
     * AIX 4.2 changed the C runtime radically. AIX 4.2 binaries won't
       run on AIX 4.1 or 3.anything. AIX 3 binaries run on AIX 4.1 and
       AIX 4.2.

   "Is AIX Year 2000 Compliant?" According to a [152]comp.unix.aix
   newsgroup posting from IBM Austin, version 4.2 is; earlier versions
   such as 4.1.x and 3.2.5 require PTFs (which, as of Jan 1997, have not
   yet been issued).

   Here is a sample configuration for setting up an xterm keyboard for
   VT220 or higher terminal emulation on AIX, courtesy of Bruce Momjian,
   Drexel Hill, PA. Xterm can be started like this:

  xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220 \
          -title vt220 -tn xterm-220 "$@" &

---------------------------------------------------------------------------
  XTerm*VT100.Translations: #override \n\
          <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

   [ [153]Top ] [ [154]Contents ] [ [155]Section Contents ] [ [156]Next ]
   [ [157]Previous ]

   SECTION CONTENTS

  3.2.0. [158]Common Problems
  3.2.1. [159]Building C-Kermit on HP-UX
  3.2.2. [160]File Transfer
  3.2.3. [161]Dialing Out and UUCP Lockfiles in HP-UX
  3.2.4. [162]Notes on Specific HP-UX Releases
  3.2.5. [163]HP-UX and X.25

   REFERENCES

   For further information, read the [164]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.

  3.2.0. Common Problems

   [ [165]Top ] [ [166]Contents ] [ [167]Section Contents ] [ [168]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

   [ [169]Top ] [ [170]Contents ] [ [171]Section Contents ] [ [172]Next ]
   [ [173]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 [174]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

   [ [175]Top ] [ [176]Contents ] [ [177]Section Contents ] [ [178]Next ]
   [ [179]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 C-Kermit as a TCP server:

  set host * 3000
  server

   and then from the client "set host blah 3000", I get:

                   C-Kermit 6.0...    C-Kermit 7.0...
 Local    Remote   ACK/NAK........    Streaming......
 Client   Server   Send    Receive    Send    Receive
  Sun      HP       77       67       106      139
  HP       HP       50       50        64       62
  HP       Sun      57       85       155      105
  Sun      Sun      57       50       321      314

   Therefore the HP-UX telnet server or pty driver seems to be adding
   more overhead than the SunOS one, and most others. When going through
   this type of connection (a remote telnet server) there is little
   Kermit can do improve matters, since the telnet server and pty driver
   are between the two Kermits, and neither Kermit program can have any
   influence over them (except putting the Telnet connection in binary
   mode, but that doesn't help).

   (The numbers for the HP-HP transfers are lower than the others since
   both Kermit processes are running on the same slow 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

   [ [180]Top ] [ [181]Contents ] [ [182]Section Contents ] [ [183]Next ]
   [ [184]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. [185]HP-UX 11
  3.2.4.2. [186]HP-UX 10
  3.2.4.3. [187]HP-UX 9
  3.2.4.4. [188]HP-UX 8
  3.2.4.5. [189]HP-UX 7 and Earlier

  3.2.4.1. HP-UX 11

   [ [190]Top ] [ [191]Contents ] [ [192]Section Contents ] [ [193]Next ]

   As noted in [194]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

   [ [195]Top ] [ [196]Contents ] [ [197]Section Contents ] [ [198]Next ]
   [ [199]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

   [ [200]Top ] [ [201]Contents ] [ [202]Section Contents ] [ [203]Next ]
   [ [204]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

   [ [205]Top ] [ [206]Contents ] [ [207]Section Contents ] [ [208]Next ]
   [ [209]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

   [ [210]Top ] [ [211]Contents ] [ [212]Section Contents ] [
   [213]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

   [ [214]Top ] [ [215]Contents ] [ [216]Section Contents ] [
   [217]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

   [ [218]Top ] [ [219]Contents ] [ [220]Section Contents ] [ [221]Next ]
   [ [222]Previous ]

   SECTION CONTENTS

  3.3.1. [223]Problems Building C-Kermit for Linux
  3.3.2. [224]Problems with Serial Devices in Linux
  3.3.3. [225]Terminal Emulation in Linux
  3.3.4. [226]Dates and Times
  3.3.5. [227]Startup Errors
  3.3.6. [228]The Fullscreen File Transfer Display

   REFERENCES

   For further information, read the [229]comp.os.linux.misc,
   [230]comp.os.linux.answers, and other Linux-oriented newsgroups, and
   see:

   The Linux Document Project (LDP)
          [231]http://sunsite.unc.edu/LDP/

   The Linux FAQ
          [232]http://sunsite.unc.edu/LDP/FAQ/Linux-FAQ.html

   The Linux HOWTOs (especially the Serial HOWTO)

     [233]http://sunsite.unc.edu/LDP/HOWTO/Serial-HOWTO.html

     [234]http://linuxdoc.org/HOWTO/Modem-HOWTO.html

     [235]ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO

     [236]ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO

     [237]http://sunsite.unc.edu/LDP/HOWTO/

     [238]http://sunsite.unc.edu/LDP/hmirrors.html

   Linux Vendor Tech Support Pages:

     [239]http://www.redhat.com/apps/support/

     [240]http://www.debian.org/support

     [241]http://www.slackware.com/support/

     [242]http://www.caldera.com/support/

     [243]http://www.suse.com/support/

     [244]http://www.mandrake.com/support/

     [245]http://www.turbolinux.com/support/

   Also see general comments on PC-based Unixes in [246]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.2, 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:

  [247]http://linux.dreamtime.org/decnet/

   (But there is no support for it in C-Kermit -- anybody interested in
   adding it, please [248]let us know).

   Before proceeding, let's handle the two most frequently asked question
   in the Linux newsgroups:

    1. Neither C-Kermit nor any other Linux application can use Winmodems
       (with one known exception). See [249]Section 3.0 for details.
    2. "Why does it take such a long time to make a telnet connection to
       (or from) my Linux PC?" (this applies to C-Kermit 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.3.1. Problems Building C-Kermit for Linux

   [ [250]Top ] [ [251]Contents ] [ [252]Section Contents ] [ [253]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.

   Be sure to read the comments in the "linux:" makefile entry. There are
   all sorts of confusing issues caused by the many and varied Linux
   distributions. Some of the worst involve the curses library and header
   files: where are they, what are they called, which ones are they
   really? Other vexing questions involve libc5 vs libc6 vs glibc vs
   glibc2 (C libraries), gcc vs egcs vs lcc (compilers), plus using or
   avoiding features that were added in a certain version of Linux or a
   library or a distribution, and are not available in others.

   Linux C-Kermit, like all other Unix C-Kermit versions, was built
   traditionally with curses.h and the curses library. However, this
   library was evidently so buggy (users reported that, after doing a
   file transfer using the fullscreen display, "screen scrolling locks
   up" and the cursor "is stuck on the bottom of the screen", etc), that
   a new curses library, called ncurses, was developed to replace it. The
   Linux version of C-Kermit, as of version 6.1, uses ncurses rather than
   curses.

   After modern practice, ncurses is dynamically linked, rather than
   linked into the executable. This means a certain relationship must
   obtain between the version number referenced in the executable and the
   version number of the library. But there are evidently several
   different numbering systems for libncurses.so -- e.g. 1.9.9e is
   another "name" for 3.0 -- but the program loader doesn't know that and
   so won't run the program. Also the library and/or terminfo database
   might be in a different place on the target system (e.g.
   /usr/share/terminfo) than it was on the build system (e.g.
   /usr/lib/terminfo). Solution: Create the appropriate symbolic links
   and/or rebuild C-Kermit yourself from source code, and if you have
   additional trouble, come back and read the rest of this section.

   Of course static linking is also a possibility, but this makes the
   executable MUCH bigger and introduces new problems of its own.

   From the March 1999 Kermit newsgroup traffic:

  : When I start Kermit (under Redhat Linux 5.2), it complains about not
  : being able to recognise my terminal type - I've tried all the obvious
  : terminal types - which ones can I use?  Or can I get it to recognise
  : xterm?
  :
  Assuming that you can use full screen programs, this looks identical to the
  problem introduced by RedHat with 5.1.  They moved the curses library, and
  didn't [ leave a link from the old location to the new one ]:

  To fix: cd /usr/share; ln -s terminfo ../lib

   The termcap library is no longer referenced in the Linux target in the
   makefile, since its functions are supposedly incorporated into the
   ncurses and curses libraries. However, should any termcap-related
   entry points come up undefined at link time (_tgetent, _tgoto, _tputs,
   etc), it might be necessary to add -ltermcap back to the "LIBS="
   clause. But then you might find that the termcap library is not in
   /usr/lib after all, but has been moved to /usr/lib/termcap/, in which
   case you'll need to make a symlink, or do something like:

  "LIBS = -L/usr/lib/curses -lcurses -L/usr/lib/termcap -ltermcap"

   Different UUCP lockfile conventions are used by different Linux
   versions and/or distributions. In C-Kermit 6.0 and later, "make linux"
   uses /var/lock/LCK..name, decimal ASCII 10-byte PID string with
   leading spaces because -DLINUXFSSTND ("Linux File System Standard") is
   included in the compilation CFLAGS. If you remove this definition,
   C-Kermit will use the earlier arrangement of integer PID,
   /usr/spool/uucp/LCK..name. The leading spaces are required by FSSTND
   1.2, but FSSTND 1.0 required leading zeros; to get the leading zeros,
   also include -DFSSTND10. Use whichever option agrees with your uucp,
   cu, tip, etc, programs.

   One user reported problems building C-Kermit under Linux
   2.0.30/Slackware 96, errors like:

  /usr/include/linux/socket.h:77: warning: `PF_AAL5' redefined
  /usr/local/include/socketbits.h:68: warning: this is the location of the
  previous definition
  ckutio.c:4679: `TIOCGSERIAL' undeclared (first use this function)
  ckutio.c:4685: `TIOCSSERIAL' undeclared (first use this function)
  ckutio.c:6092: warning: passing arg 3 of `select' from incompatible
  pointer type

   etc etc. Diagnosis: These were caused by installing some other
   package, which created files in /usr/local/include. Cure:

  rm -rf /usr/local/include

   start over.

   Reportedly, building C-Kermit 6.0 on Linux 1.1.33 and 1.1.34 gets
   fatal compilation errors due to inconsistencies in the Linux header
   files. Linux kernel versions prior to 1.1.33 and later than 1.1.34
   should be OK. (Also, C-Kermit 6.1 and later should be OK since we no
   longer include kernel header files.)

   Reportedly there is a bug in gcc 2.5.8 with signed to unsigned
   compares that can wreak havoc when Kermit (or most any other program)
   is compiled with this version of gcc; reportedly this can be worked
   around, at least in part, by adding "-fno-unroll-loops" to the gcc
   compilation options. (This problem is evidently fixed in more recent
   gcc releases.)

   Reportedly, if you have the iBCS2 (Intel Binary Compatibility Standard
   2) module installed, you can also run SCO Xenix and Unix binaries
   under Linux, including the SCO C-Kermit binaries, shareable libraries
   and all. (iCBS2 is available via anonymous ftp from
   [254]tsx-11.mit.edu, along with an SCO libc_s compatibility module for
   Linux).

   There is evidently a minor problem with GCC (version unknown) on
   (64-bit) Alpha platforms, in which it complains:

  warning: cast to pointer from integer of different size

   whenever it encounters a legitimate trinary expression like:

  integer ? "string1" : "string2"

   (The "integer" can also be an integer-valued expression.) These
   warnings appear to be harmless.
    ________________________________________________________________________

  3.3.2. Problems with Serial Devices in Linux

   [ [255]Top ] [ [256]Contents ] [ [257]Section Contents ] [ [258]Next ]
   [ [259]Previous ]

     Also see: "man setserial", "man irqtune".
     And: [260]Sections 3.0, [261]6, [262]7, and [263]8 of this
     document.

   Don't expect it to be easy. Queries like the following are posted to
   the Linux newsgroups almost daily:

     Problem of a major kind with my Compaq Presario 1805 in the sense
     that the pnpdump doesn't find the modem and the configuration tells
     me that the modem is busy when I set everything by hand!

     I have <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.

   Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the
   like (see cautions in [264]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).

   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):

  [265]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

   [ [266]Top ] [ [267]Contents ] [ [268]Section Contents ] [ [269]Next ]
   [ [270]Previous ]

   C-Kermit is not a terminal emulator. For a brief explanation of why
   not, see [271]Section 3.0.5. For a fuller explanation, [272]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:

  [273]http://www.clark.net/pub/dickey/xterm/xterm.faq.html

   Before starting C-Kermit in an xterm window, you might need to tell
   the xterm window's shell to "stty sane".

   To set up your PC console keyboard to send VT220 key sequences when
   using C-Kermit as your communications program in an X terminal window
   (if it doesn't already), create a file somewhere (e.g. in /root/)
   called .xmodmaprc, containing something like the following:

  keycode 77  = KP_F1       ! Num Lock     => DEC Gold (PF1)
  keycode 112 = KP_F2       ! Keypad /     => DEC PF1
  keycode 63  = KP_F3       ! Keypad *     => DEC PF3
  keycode 82  = KP_F4       ! Keypad -     => DEC PF4
  keycode 111 = Help        ! Print Screen => DEC Help
  keycode 78  = F16         ! Scroll Lock  => DEC Do
  keycode 110 = F16         ! Pause        => DEC Do
  keycode 106 = Find        ! Insert       => DEC Find
  keycode 97  = Insert      ! Home         => DEC Insert
  keycode 99  = 0x1000ff00  ! Page Up      => DEC Remove
  keycode 107 = Select      ! Delete       => DEC Select
  keycode 103 = Page_Up     ! End          => DEC Prev Screen
  keycode 22  = Delete      ! Backspace sends Delete (127)

   Then put "xmodmap <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.
    ________________________________________________________________________

  3.3.4. Dates and Times

   [ [274]Top ] [ [275]Contents ] [ [276]Section Contents ] [ [277]Next ]
   [ [278]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

   [ [279]Top ] [ [280]Contents ] [ [281]Section Contents ] [ [282]Next ]
   [ [283]Previous ]

   C-Kermit should work on all versions of Linux current through December
   2001, 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, [284]let us know.

   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.

  [285]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
   [286]Kermit newsgroup:

     From: [e-mail]
     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

   [ [287]Top ] [ [288]Contents ] [ [289]Section Contents ] [
   [290]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=-DNCURSESNOSETBUF (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. At this writing, I don't know how to defeat it.
    ________________________________________________________________________

  3.4. C-KERMIT AND NEXTSTEP

   [ [291]Top ] [ [292]Contents ] [ [293]Section Contents ] [ [294]Next ]
   [ [295]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

   [ [296]Top ] [ [297]Contents ] [ [298]Section Contents ] [ [299]Next ]
   [ [300]Previous ]

   See also: The [301]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 [302]G-Kermit.

   The 32-bit version (and the 16-bit version prior to C-Kermit 7.0)
   support most of C-Kermit's advanced features including TCP/IP, high
   serial speeds, hardware flow-control, modem-signal awareness, curses
   support, etc.

   BUG: In C-Kermit 6.0 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 [303]UUCP
   lockfile section of the [304]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

   [ [305]Top ] [ [306]Contents ] [ [307]Section Contents ] [ [308]Next ]
   [ [309]Previous ]

   SECTION CONTENTS

3.6.1. [310]SCO XENIX
3.6.2. [311]SCO UNIX and OSR5
3.6.3. [312]Unixware
3.6.4. [313]Open UNIX 8

   REFERENCES

     * The comp.unix.sco.* newsgroups.
     * [314]Section 3.10 below for Unixware.
     * The following FAQs:

        The comp.sco.misc FAQ:
                [315]http://aplawrence.com/SCOFAQ/

        Caldera (SCO) comp.unix.sco.programmer FAQ:
                [316]http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl

        The UnixWare 7/OpenUNIX 8 FAQ:
                [317]http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
                [318]http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl

        The UnixWare FAQ
                [319]http://www.freebird.org/faq/

        The UnixWare 1.x and 2.0 Programmer FAQ
                [320]http://www.freebird.org/faq/developer.html

        Caldera Support Knowledge Base
                [321]http://support.caldera.com/caldera

   Also see general comments on PC-based Unixes in [322]Section 3.0.

  3.6.1. SCO XENIX

   [ [323]Top ] [ [324]Contents ] [ [325]Section Contents ] [ [326]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 [327]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

   [ [328]Top ] [ [329]Contents ] [ [330]Section Contents ] [ [331]Next ]
   [ [332]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.x does 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.

   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., [333]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:

  [334]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 [335]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
   [336]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 [337]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

   [ [338]Top ] [ [339]Contents ] [ [340]Section Contents ] [ [341]Next ]
   [ [342]Previous ]

   Unixware changed hands several times before landing at SCO, and so has
   its [343]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.)
    ________________________________________________________________________

  3.6.4. Open UNIX 8

   [ [344]Top ] [ [345]Contents ] [ [346]Section Contents ] [
   [347]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).
    ________________________________________________________________________

  3.7. C-KERMIT AND SOLARIS

   [ [348]Top ] [ [349]Contents ] [ [350]Section Contents ] [ [351]Next ]
   [ [352]Previous ]

   SECTION CONTENTS

3.7.1. [353]Serial Port Configuration
3.7.2. [354]Serial Port Problems
3.7.3. [355]SunLink X.25
3.7.4. [356]Sun Workstation Keyboard Mapping
3.7.5. [357]Solaris 2.4 and Earlier

   REFERENCES

     * The [358]comp.unix.solaris newsgroup
     * [359]http://access1.sun.com/
     * [360]http://docs.sun.com/
     * [361]http://www.sunhelp.com/
     * [362]http://www.wins.uva.nl/pub/solaris/solaris2/
     * [363]http://www.wins.uva.nl/cgi-bin/sfaq.cgi
     * [364]ftp://ftp.wins.uva.nl/pub/solaris
     * [365]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":

  [366]http://www.stokely.com/

   In particular:

  [367]http://www.stokely.com/unix.sysadm.resources/faqs.sun.html

   For PC-based Solaris, also see general comments on PC-based Unixes in
   [368]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

   [ [369]Top ] [ [370]Contents ] [ [371]Section Contents ] [
   [372]Section Contents ] [ [373]Next ]

   Even then your serial port can't be used -- or at least won't work
   right -- until it is enabled in Solaris. For example, you get a
   message like "SERIAL: Operation would block" when attempting to dial.
   This probably indicates that the serial port has not been enabled for
   use with modems. You'll need to follow the instructions in your system
   setup or management manual, such as (e.g.) the Desktop SPARC Sun
   System & Network Manager's Guide, which should contain a section
   "Setting up Modem Software"; read it and follow the instructions.
   These might (or might not) include running a program called "eeprom",
   editing some system configuration file (such as, for example:

  /platform/i86pc/kernel/drv/asy.conf

   and then doing a configuration reboot, or running some other programs
   like drvconfig and devlinks. "man eeprom" for details.

   Also, on certain Sun models like IPC, the serial port hardware might
   need to have a jumper changed to make it an RS-232 port rather than
   RS-423.

   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."
    ________________________________________________________________________

  3.7.2. Serial Port Problems

   [ [374]Top ] [ [375]Contents ] [ [376]Section Contents ] [ [377]Next ]
   [ [378]Previous ]

   Some users report difficulties dialing out with C-Kermit on serial
   port when using the /dev/cua/a name -- session seems to become stuck,
   can't escape back, etc -- but when using the /dev/term/a name for the
   same device, everything works fine. Explanation: unknown, but probably
   due to driver differences or improper configuration of the port;
   again, see the [379]materials referenced above.

   Reportedly, if you start C-Kermit and "set line" to a port that has a
   modem connected to it that is not turned on, and then "set flow
   rts/cts", there might be some (unspecified) difficulties closing the
   device (Solaris version not specified).
    ________________________________________________________________________

  3.7.3. SunLink X.25

   [ [380]Top ] [ [381]Contents ] [ [382]Section Contents ] [ [383]Next ]
   [ [384]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

   [ [385]Top ] [ [386]Contents ] [ [387]Section Contents ] [ [388]Next ]
   [ [389]Previous ]

   Hints for using a Sun workstation keyboard for VT emulation when
   accessing VMS, from the [390]comp.os.vms newsgroup:

     From: Jerry Leichter <[e-mail]>
     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 2.4 and Earlier

   [ [391]Top ] [ [392]Contents ] [ [393]Section Contents ] [
   [394]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

   [ [395]Top ] [ [396]Contents ] [ [397]Section Contents ] [ [398]Next ]
   [ [399]Previous ]

   For additional information, see "Celeste's Tutorial on SunOS 4.1.3+
   Modems and Terminals":

  [400]http://www.stokely.com/

   For FAQs, etc, from Sun, see:
     * [401]http://access1.sun.com/

   For history of Sun models and SunOS versions, see (should be all the
   same):
     * [402]http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
     * [403]ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
     * [404]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

   [ [405]Top ] [ [406]Contents ] [ [407]Section Contents ] [ [408]Next ]
   [ [409]Previous ]

   See also: The [410]comp.unix.ultrix and [411]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

   [ [412]Top ] [ [413]Contents ] [ [414]Section Contents ] [ [415]Next ]
   [ [416]Previous ]

   See also:
     * The Freebird Project (Unixware software repository)
       [417]http://www.freebird.org/
     * The UnixWare FAQ: [418]http://www.freebird.org/faq/
     * The following newsgroups:
          + [419]comp.unix.unixware.misc
          + [420]comp.unix.sco.misc.

   Also see general comments on PC-based Unixes in [421]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
   [422]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

   [ [423]Top ] [ [424]Contents ] [ [425]Section Contents ] [ [426]Next ]
   [ [427]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

   [ [428]Top ] [ [429]Contents ] [ [430]Section Contents ] [ [431]Next ]
   [ [432]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)

   [ [433]Top ] [ [434]Contents ] [ [435]Section Contents ] [ [436]Next ]
   [ [437]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

   [ [438]Top ] [ [439]Contents ] [ [440]Section Contents ] [ [441]Next ]
   [ [442]Previous ]

   See also:
     * The [443]comp.sys.sgi.misc and [444]comp.sys.sgi.admin newsgroups.
       [445]The SGI website
     * The SGI FAQ:
          + [446]http://www-viz.tamu.edu/~sgi-faq/
          + [447]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 [448]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:

  [449]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
   [450]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

   [ [451]Top ] [ [452]Contents ] [ [453]Section Contents ] [ [454]Next ]
   [ [455]Previous ]

   See also: The [456]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

   [ [457]Top ] [ [458]Contents ] [ [459]Section Contents ] [ [460]Next ]
   [ [461]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

   [ [462]Top ] [ [463]Contents ] [ [464]Section Contents ] [ [465]Next ]
   [ [466]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

   [ [467]Top ] [ [468]Contents ] [ [469]Section Contents ] [ [470]Next ]
   [ [471]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)

   [ [472]Top ] [ [473]Contents ] [ [474]Section Contents ] [ [475]Next ]
   [ [476]Previous ]

   Nomenclature:

  mac os x server 1.0   = rhapsody 5.3
  mac os x server 1.0.1 = rhapsody 5.4
  mac os x server 1.0.2 = rhapsody 5.5
  mac os x server 1.2   = rhapsody 5.6

  mac os x 10.0 and 10.0.x run on darwin 1.3.y
  mac os x 10.1 and 10.1.x run on darwin 1.4.y

  mac os x (client) to darwin =(approximately)= X11 to unix

   Evidently hardware flow control doesn't work. This has been reported
   to Apple (June 2001), no response yet that I know of.
    ________________________________________________________________________

  3.20. C-KERMIT AND COHERENT

   [ [477]Top ] [ [478]Contents ] [ [479]Section Contents ] [
   [480]Previous ]

   Also see:

     [481]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

   [ [482]Top ] [ [483]Contents ] [ [484]Next ] [ [485]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 [486]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. 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

   [ [487]Top ] [ [488]Contents ] [ [489]Next ] [ [490]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 [491]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

   [ [492]Top ] [ [493]Contents ] [ [494]Next ] [ [495]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 [496]Section 9.5 of the Installation
   Instructions, plus any platform-specific notes in [497]Section 3
   above.
    ________________________________________________________________________

  7. COMMUNICATIONS AND DIALING

   [ [498]Top ] [ [499]Contents ] [ [500]Next ] [ [501]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 [502]Section 8 of the
       [503]Installation Instructions.
    7. Read pages 50-67 of [504]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

   [ [505]Top ] [ [506]Contents ] [ [507]Next ] [ [508]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.
    ________________________________________________________________________

  9. TERMINAL CONNECTION AND KEY MAPPING

   [ [509]Top ] [ [510]Contents ] [ [511]Next ] [ [512]Previous ]

   C-Kermit is not a terminal emulator. Refer to page 147 of [513]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:

  [514]http://www.clark.net/pub/dickey/xterm/xterm.faq.html

   Unix C-Kermit's SET KEY command currently can not be used with keys
   that generate "wide" scan codes or multibyte sequences, such as
   workstation function or arrow keys, because Unix C-Kermit does not
   have direct access to the keyboard.

   However, many Unix workstations and/or console drivers provide their
   own key mapping feature. With xterm, for example, you can use
   'xmodmap' ("man xmodmap" for details); here is an xterm mapping to map
   the Sun keyboard to DEC VT200 values for use with VT-terminal oriented
   applications like VMS EVE:

  keycode 101=KP_0
  keycode 119=KP_1
  keycode 120=KP_2
  keycode 121=KP_3
  keycode 98=KP_4
  keycode 99=KP_5
  keycode 100=KP_6
  keycode 75=KP_7
  keycode 76=KP_8
  keycode 77=KP_9
  keycode 52=KP_F1
  keycode 53=KP_F2
  keycode 54=KP_F3
  keycode 57=KP_Decimal
  keycode 28=Left
  keycode 29=Right
  keycode 30=KP_Separator
  keycode 105=KP_F4
  keycode 78=KP_Subtract
  keycode 8=Left
  keycode 10=Right
  keycode 32=Up
  keycode 33=Down
  keycode 97=KP_Enter

   Users of Linux consoles can use loadkeys ("man dumpkeys loadkeys
   keytables" for details. The format used by loadkeys is compatible with
   that used by Xmodmap, although it is not definitely certain that the
   keycodes are compatible for different keyboard types (e.g. Sun vs HP
   vs PC, etc).
    ________________________________________________________________________

  10. FILE TRANSFER

   [ [515]Top ] [ [516]Contents ] [ [517]Next ] [ [518]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 uploads (particularly of large files and/or binary files) begin
   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)
     * 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

   [ [519]Top ] [ [520]Contents ] [ [521]Next ] [ [522]Previous ]

   SECTION CONTENTS

  11.1. [523]C-Kermit as an External Protocol
  11.2. [524]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

   [ [525]Top ] [ [526]Contents ] [ [527]Section Contents ] [ [528]Next ]

   (This section deleted; see [529]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

   [ [530]Top ] [ [531]Contents ] [ [532]Section Contents ] [
   [533]Previous ]

     (This section is obsolete, but not totally useless. See Chapter 14
     of [534]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

   [ [535]Top ] [ [536]Contents ] [ [537]Next ] [ [538]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 [539]security document for details.
    ________________________________________________________________________

  13. MISCELLANEOUS USER REPORTS

   [ [540]Top ] [ [541]Contents ] [ [542]Next ] [ [543]Previous ]

Date: Thu, 12 Mar 92 1:59:25 MEZ
From: Walter Mecky <[e-mail]>
Subject: Help.Unix.sw
To: [e-mail], [e-mail]

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 <[e-mail]>
   To: [e-mail]
   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 {[e-mail] } */
/* 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

   [ [544]Top ] [ [545]Contents ] [ [546]Next ] [ [547]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, [548][e-mail].

   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, [549]www.stallion.com, in the
       /drivers/ata5/UnixWare directory.

   [ [550]Top ] [ [551]Contents ] [ [552]C-Kermit Home ] [ [553]C-Kermit
   8.0 Overview ] [ [554]Kermit Home ]
     _________________________________________________________________

   C-Kermit 8.0 Unix Hints and Tips / [555]The Kermit Project /
   [556]Columbia University / [557][e-mail] / 16 Dec 2001

References

   1. http://www.columbia.edu/kermit/
   2. http://www.columbia.edu/
   3. http://www.columbia.edu/kermit/ckubwr.html
   4. mailto:[e-mail]
   5. http://www.columbia.edu/kermit/ckermit.html
   6. http://www.columbia.edu/kermit/ck80.html
   7. http://www.columbia.edu/kermit/ckuins.html
   8. http://www.columbia.edu/kermit/ckututor.html
   9. http://www.columbia.edu/kermit/ckubwr.html#x1
  10. http://www.columbia.edu/kermit/ckubwr.html#x2
  11. http://www.columbia.edu/kermit/ckubwr.html#x3
  12. http://www.columbia.edu/kermit/ckubwr.html#x4
  13. http://www.columbia.edu/kermit/ckubwr.html#x5
  14. http://www.columbia.edu/kermit/ckubwr.html#x6
  15. http://www.columbia.edu/kermit/ckubwr.html#x7
  16. http://www.columbia.edu/kermit/ckubwr.html#x8
  17. http://www.columbia.edu/kermit/ckubwr.html#x9
  18. http://www.columbia.edu/kermit/ckubwr.html#x10
  19. http://www.columbia.edu/kermit/ckubwr.html#x11
  20. http://www.columbia.edu/kermit/ckubwr.html#x12
  21. http://www.columbia.edu/kermit/ckubwr.html#x13
  22. http://www.columbia.edu/kermit/ckubwr.html#x14
  23. http://www.columbia.edu/kermit/ckubwr.html#x3.3
  24. http://www.columbia.edu/kermit/ckubwr.html#x3.18
  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:[e-mail]
  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/ckermit2.html
  48. http://www.columbia.edu/kermit/ckermit2.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://www.columbia.edu/kermit/x3
  95. mailto:[e-mail]
  96. http://www.columbia.edu/kermit/support.html
  97. http://www.columbia.edu/kermit/ckubwr.html#top
  98. http://www.columbia.edu/kermit/ckubwr.html#contents
  99. http://www.columbia.edu/kermit/ckubwr.html#x3
 100. http://www.columbia.edu/kermit/ckubwr.html#x3.1
 101. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
 102. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
 103. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
 104. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
 105. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
 106. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
 107. http://www.columbia.edu/kermit/ckubwr.html#top
 108. http://www.columbia.edu/kermit/ckubwr.html#contents
 109. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 110. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
 111. http://www.columbia.edu/kermit/ckubwr.html#top
 112. http://www.columbia.edu/kermit/ckubwr.html#contents
 113. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 114. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
 115. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
 116. http://www.microsoft.com/hwdev/newpc/
 117. http://www.columbia.edu/kermit/ckubwr.html#top
 118. http://www.columbia.edu/kermit/ckubwr.html#contents
 119. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 120. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
 121. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
 122. http://www.o2.net/~gromitkc/winmodem.html
 123. http://www.digi.com/
 124. http://www.columbia.edu/kermit/ckubwr.html#top
 125. http://www.columbia.edu/kermit/ckubwr.html#contents
 126. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 127. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
 128. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
 129. http://www.columbia.edu/kermit/ckubwr.html#top
 130. http://www.columbia.edu/kermit/ckubwr.html#contents
 131. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 132. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
 133. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
 134. http://www.columbia.edu/kermit/ckubwr.html#top
 135. http://www.columbia.edu/kermit/ckubwr.html#contents
 136. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 137. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
 138. http://www.columbia.edu/kermit/ckubwr.html#top
 139. http://www.columbia.edu/kermit/ckubwr.html#contents
 140. http://www.columbia.edu/kermit/ckubwr.html#x3
 141. http://www.columbia.edu/kermit/ckubwr.html#x3.2
 142. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 143. http://www.emerson.emory.edu/services/aix-faq/
 144. http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
 145. http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html
 146. http://aixpdslib.seas.ucla.edu/
 147. http://www.rootvg.net(AIXhistory)/
 148. ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
 149. ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix
 150. news:comp.unix.aix
 151. http://service.software.ibm.com/rs6000/
 152. news:comp.unix.aix
 153. http://www.columbia.edu/kermit/ckubwr.html#top
 154. http://www.columbia.edu/kermit/ckubwr.html#contents
 155. http://www.columbia.edu/kermit/ckubwr.html#x3
 156. http://www.columbia.edu/kermit/ckubwr.html#x3.3
 157. http://www.columbia.edu/kermit/ckubwr.html#x3.1
 158. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
 159. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
 160. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
 161. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
 162. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
 163. http://www.columbia.edu/kermit/ckubwr.html#x3.2.5
 164. news:comp.sys.hp.hpux
 165. http://www.columbia.edu/kermit/ckubwr.html#top
 166. http://www.columbia.edu/kermit/ckubwr.html#contents
 167. http://www.columbia.edu/kermit/ckubwr.html#x3.2
 168. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
 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.2
 172. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
 173. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
 174. ftp://kermit.columbia.edu/kermit/f/makefile
 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.2
 178. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
 179. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
 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.2
 183. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
 184. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
 185. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1
 186. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
 187. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
 188. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
 189. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
 190. http://www.columbia.edu/kermit/ckubwr.html#top
 191. http://www.columbia.edu/kermit/ckubwr.html#contents
 192. http://www.columbia.edu/kermit/ckubwr.html#x3.2
 193. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
 194. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
 195. http://www.columbia.edu/kermit/ckubwr.html#top
 196. http://www.columbia.edu/kermit/ckubwr.html#contents
 197. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
 198. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
 199. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.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.4
 203. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
 204. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
 205. http://www.columbia.edu/kermit/ckubwr.html#top
 206. http://www.columbia.edu/kermit/ckubwr.html#contents
 207. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
 208. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
 209. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
 210. http://www.columbia.edu/kermit/ckubwr.html#top
 211. http://www.columbia.edu/kermit/ckubwr.html#contents
 212. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
 213. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
 214. http://www.columbia.edu/kermit/ckubwr.html#top
 215. http://www.columbia.edu/kermit/ckubwr.html#contents
 216. http://www.columbia.edu/kermit/ckubwr.html#x3.2
 217. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
 218. http://www.columbia.edu/kermit/ckubwr.html#top
 219. http://www.columbia.edu/kermit/ckubwr.html#contents
 220. http://www.columbia.edu/kermit/ckubwr.html#x3
 221. http://www.columbia.edu/kermit/ckubwr.html#x3.4
 222. http://www.columbia.edu/kermit/ckubwr.html#x3.2
 223. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
 224. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
 225. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
 226. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
 227. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
 228. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
 229. news:comp.os.linux.misc
 230. news:comp.os.linux.answers
 231. http://sunsite.unc.edu/LDP/
 232. http://sunsite.unc.edu/LDP/FAQ/Linux-FAQ.html
 233. http://sunsite.unc.edu/LDP/HOWTO/Serial-HOWTO.html
 234. http://linuxdoc.org/HOWTO/Modem-HOWTO.html
 235. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
 236. ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
 237. http://sunsite.unc.edu/LDP/HOWTO/
 238. http://sunsite.unc.edu/LDP/hmirrors.html
 239. http://www.redhat.com/apps/support/
 240. http://www.debian.org/support
 241. http://www.slackware.com/support/
 242. http://www.caldera.com/support/
 243. http://www.suse.com/support/
 244. http://www.mandrake.com/support/
 245. http://www.turbolinux.com/support/
 246. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 247. http://linux.dreamtime.org/decnet/
 248. mailto:[e-mail]
 249. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 250. http://www.columbia.edu/kermit/ckubwr.html#top
 251. http://www.columbia.edu/kermit/ckubwr.html#contents
 252. http://www.columbia.edu/kermit/ckubwr.html#x3
 253. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
 254. ftp://tsx-11.mit.edu/
 255. http://www.columbia.edu/kermit/ckubwr.html#top
 256. http://www.columbia.edu/kermit/ckubwr.html#contents
 257. http://www.columbia.edu/kermit/ckubwr.html#x3.3
 258. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
 259. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
 260. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 261. http://www.columbia.edu/kermit/ckubwr.html#x6
 262. http://www.columbia.edu/kermit/ckubwr.html#x7
 263. http://www.columbia.edu/kermit/ckubwr.html#x8
 264. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 265. http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
 266. http://www.columbia.edu/kermit/ckubwr.html#top
 267. http://www.columbia.edu/kermit/ckubwr.html#contents
 268. http://www.columbia.edu/kermit/ckubwr.html#x3.3
 269. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
 270. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
 271. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
 272. http://www.columbia.edu/kermit/ckfaq.html#term
 273. http://www.clark.net/pub/dickey/xterm/xterm.faq.html
 274. http://www.columbia.edu/kermit/ckubwr.html#top
 275. http://www.columbia.edu/kermit/ckubwr.html#contents
 276. http://www.columbia.edu/kermit/ckubwr.html#x3.3
 277. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
 278. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
 279. http://www.columbia.edu/kermit/ckubwr.html#top
 280. http://www.columbia.edu/kermit/ckubwr.html#contents
 281. http://www.columbia.edu/kermit/ckubwr.html#x3.3
 282. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
 283. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
 284. mailto:[e-mail]
 285. http://www.redhat.com/support/errata/RHBA-2001-153.html
 286. news:comp.protocols.kermit.misc
 287. http://www.columbia.edu/kermit/ckubwr.html#top
 288. http://www.columbia.edu/kermit/ckubwr.html#contents
 289. http://www.columbia.edu/kermit/ckubwr.html#x3.3
 290. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
 291. http://www.columbia.edu/kermit/ckubwr.html#top
 292. http://www.columbia.edu/kermit/ckubwr.html#contents
 293. http://www.columbia.edu/kermit/ckubwr.html#x3
 294. http://www.columbia.edu/kermit/ckubwr.html#x3.5
 295. http://www.columbia.edu/kermit/ckubwr.html#x3.3
 296. http://www.columbia.edu/kermit/ckubwr.html#top
 297. http://www.columbia.edu/kermit/ckubwr.html#contents
 298. http://www.columbia.edu/kermit/ckubwr.html#x3
 299. http://www.columbia.edu/kermit/ckubwr.html#x3.6
 300. http://www.columbia.edu/kermit/ckubwr.html#x3.4
 301. news:comp.os.qnx
 302. http://www.columbia.edu/kermit/gkermit.html
 303. http://www.columbia.edu/kermit/ckuins.html#x10
 304. http://www.columbia.edu/kermit/ckuins.html
 305. http://www.columbia.edu/kermit/ckubwr.html#top
 306. http://www.columbia.edu/kermit/ckubwr.html#contents
 307. http://www.columbia.edu/kermit/ckubwr.html#x3
 308. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 309. http://www.columbia.edu/kermit/ckubwr.html#x3.5
 310. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
 311. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
 312. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
 313. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
 314. http://www.columbia.edu/kermit/ckubwr.html#x3.10
 315. http://aplawrence.com/SCOFAQ/
 316. http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
 317. http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
 318. http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
 319. http://www.freebird.org/faq/
 320. http://www.freebird.org/faq/developer.html
 321. http://support.caldera.com/caldera
 322. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 323. http://www.columbia.edu/kermit/ckubwr.html#top
 324. http://www.columbia.edu/kermit/ckubwr.html#contents
 325. http://www.columbia.edu/kermit/ckubwr.html#x3.6
 326. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
 327. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 328. http://www.columbia.edu/kermit/ckubwr.html#top
 329. http://www.columbia.edu/kermit/ckubwr.html#contents
 330. http://www.columbia.edu/kermit/ckubwr.html#x3.6
 331. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
 332. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
 333. http://www.digi.com/
 334. ftp://ftp.fu-berlin.de/pub/unix/driver/fas
 335. http://www.columbia.edu/kermit/ckubwr.html#x14
 336. http://www.sco.com/
 337. ftp://ftp.sco.com/
 338. http://www.columbia.edu/kermit/ckubwr.html#top
 339. http://www.columbia.edu/kermit/ckubwr.html#contents
 340. http://www.columbia.edu/kermit/ckubwr.html#x3.6
 341. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
 342. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
 343. http://www.columbia.edu/kermit/ckubwr.html#x3.10
 344. http://www.columbia.edu/kermit/ckubwr.html#top
 345. http://www.columbia.edu/kermit/ckubwr.html#contents
 346. http://www.columbia.edu/kermit/ckubwr.html#x3.6
 347. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
 348. http://www.columbia.edu/kermit/ckubwr.html#top
 349. http://www.columbia.edu/kermit/ckubwr.html#contents
 350. http://www.columbia.edu/kermit/ckubwr.html#x3
 351. http://www.columbia.edu/kermit/ckubwr.html#x3.8
 352. http://www.columbia.edu/kermit/ckubwr.html#x3.6
 353. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
 354. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
 355. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
 356. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
 357. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
 358. news:comp.unix.solaris
 359. http://access1.sun.com/
 360. http://docs.sun.com/
 361. http://www.sunhelp.com/
 362. http://www.wins.uva.nl/pub/solaris/solaris2/
 363. http://www.wins.uva.nl/cgi-bin/sfaq.cgi
 364. ftp://ftp.wins.uva.nl/pub/solaris
 365. http://www.science.uva.nl/pub/solaris/solaris2.html
 366. http://www.stokely.com/
 367. http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
 368. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 369. http://www.columbia.edu/kermit/ckubwr.html#top
 370. http://www.columbia.edu/kermit/ckubwr.html#contents
 371. http://www.columbia.edu/kermit/ckubwr.html#x3
 372. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 373. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
 374. http://www.columbia.edu/kermit/ckubwr.html#top
 375. http://www.columbia.edu/kermit/ckubwr.html#contents
 376. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 377. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
 378. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
 379. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 380. http://www.columbia.edu/kermit/ckubwr.html#top
 381. http://www.columbia.edu/kermit/ckubwr.html#contents
 382. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 383. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
 384. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
 385. http://www.columbia.edu/kermit/ckubwr.html#top
 386. http://www.columbia.edu/kermit/ckubwr.html#contents
 387. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 388. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
 389. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
 390. news:comp.os.vms
 391. http://www.columbia.edu/kermit/ckubwr.html#top
 392. http://www.columbia.edu/kermit/ckubwr.html#contents
 393. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 394. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
 395. http://www.columbia.edu/kermit/ckubwr.html#top
 396. http://www.columbia.edu/kermit/ckubwr.html#contents
 397. http://www.columbia.edu/kermit/ckubwr.html#x3
 398. http://www.columbia.edu/kermit/ckubwr.html#x3.9
 399. http://www.columbia.edu/kermit/ckubwr.html#x3.7
 400. http://www.stokely.com/
 401. http://access1.sun.com/
 402. http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
 403. ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
 404. ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref
 405. http://www.columbia.edu/kermit/ckubwr.html#top
 406. http://www.columbia.edu/kermit/ckubwr.html#contents
 407. http://www.columbia.edu/kermit/ckubwr.html#x3
 408. http://www.columbia.edu/kermit/ckubwr.html#x3.10
 409. http://www.columbia.edu/kermit/ckubwr.html#x3.8
 410. news:comp.unix.ultrix
 411. news:comp.sys.dec
 412. http://www.columbia.edu/kermit/ckubwr.html#top
 413. http://www.columbia.edu/kermit/ckubwr.html#contents
 414. http://www.columbia.edu/kermit/ckubwr.html#x3
 415. http://www.columbia.edu/kermit/ckubwr.html#x3.11
 416. http://www.columbia.edu/kermit/ckubwr.html#x3.9
 417. http://www.freebird.org/
 418. http://www.freebird.org/faq/
 419. news:comp.unix.unixware.misc
 420. news:comp.unix.sco.misc
 421. http://www.columbia.edu/kermit/ckubwr.html#x3.0
 422. ftp://kermit.columbia.edu/kermit/f/ckutio.c
 423. http://www.columbia.edu/kermit/ckubwr.html#top
 424. http://www.columbia.edu/kermit/ckubwr.html#contents
 425. http://www.columbia.edu/kermit/ckubwr.html#x3
 426. http://www.columbia.edu/kermit/ckubwr.html#x3.12
 427. http://www.columbia.edu/kermit/ckubwr.html#x3.10
 428. http://www.columbia.edu/kermit/ckubwr.html#top
 429. http://www.columbia.edu/kermit/ckubwr.html#contents
 430. http://www.columbia.edu/kermit/ckubwr.html#x3
 431. http://www.columbia.edu/kermit/ckubwr.html#x3.13
 432. http://www.columbia.edu/kermit/ckubwr.html#x3.11
 433. http://www.columbia.edu/kermit/ckubwr.html#top
 434. http://www.columbia.edu/kermit/ckubwr.html#contents
 435. http://www.columbia.edu/kermit/ckubwr.html#x3
 436. http://www.columbia.edu/kermit/ckubwr.html#x3.14
 437. http://www.columbia.edu/kermit/ckubwr.html#x3.12
 438. http://www.columbia.edu/kermit/ckubwr.html#top
 439. http://www.columbia.edu/kermit/ckubwr.html#contents
 440. http://www.columbia.edu/kermit/ckubwr.html#x3
 441. http://www.columbia.edu/kermit/ckubwr.html#x3.15
 442. http://www.columbia.edu/kermit/ckubwr.html#x3.13
 443. news:comp.sys.sgi.misc
 444. news:comp.sys.sgi.admin
 445. http://www.sgi.com/
 446. http://www-viz.tamu.edu/~sgi-faq/
 447. ftp://viz.tamu.edu/pub/sgi/faq/
 448. http://www.columbia.edu/kermit/ckuins.html
 449. http://freeware.sgi.com/Installable/gcc-2.95.2.html
 450. http://freeware.sgi.com/Installable/gcc-2.95.2.html
 451. http://www.columbia.edu/kermit/ckubwr.html#top
 452. http://www.columbia.edu/kermit/ckubwr.html#contents
 453. http://www.columbia.edu/kermit/ckubwr.html#x3
 454. http://www.columbia.edu/kermit/ckubwr.html#x3.16
 455. http://www.columbia.edu/kermit/ckubwr.html#x3.14
 456. news:comp.sys.be
 457. http://www.columbia.edu/kermit/ckubwr.html#top
 458. http://www.columbia.edu/kermit/ckubwr.html#contents
 459. http://www.columbia.edu/kermit/ckubwr.html#x3
 460. http://www.columbia.edu/kermit/ckubwr.html#x3.17
 461. http://www.columbia.edu/kermit/ckubwr.html#x3.15
 462. http://www.columbia.edu/kermit/ckubwr.html#top
 463. http://www.columbia.edu/kermit/ckubwr.html#contents
 464. http://www.columbia.edu/kermit/ckubwr.html#x3
 465. http://www.columbia.edu/kermit/ckubwr.html#x3.18
 466. http://www.columbia.edu/kermit/ckubwr.html#x3.16
 467. http://www.columbia.edu/kermit/ckubwr.html#top
 468. http://www.columbia.edu/kermit/ckubwr.html#contents
 469. http://www.columbia.edu/kermit/ckubwr.html#x3
 470. http://www.columbia.edu/kermit/ckubwr.html#x3.19
 471. http://www.columbia.edu/kermit/ckubwr.html#x3.17
 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.20
 476. http://www.columbia.edu/kermit/ckubwr.html#x3.18
 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.19
 481. http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg00000.html
 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#x5
 485. http://www.columbia.edu/kermit/ckubwr.html#x3
 486. http://www.columbia.edu/kermit/ckccfg.html
 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#x6
 490. http://www.columbia.edu/kermit/ckubwr.html#x4
 491. http://www.columbia.edu/kermit/ckuins.html
 492. http://www.columbia.edu/kermit/ckubwr.html#top
 493. http://www.columbia.edu/kermit/ckubwr.html#contents
 494. http://www.columbia.edu/kermit/ckubwr.html#x7
 495. http://www.columbia.edu/kermit/ckubwr.html#x5
 496. http://www.columbia.edu/kermit/ckuins.html#9.5
 497. http://www.columbia.edu/kermit/ckubwr.html#x3
 498. http://www.columbia.edu/kermit/ckubwr.html#top
 499. http://www.columbia.edu/kermit/ckubwr.html#contents
 500. http://www.columbia.edu/kermit/ckubwr.html#x8
 501. http://www.columbia.edu/kermit/ckubwr.html#x6
 502. http://www.columbia.edu/kermit/ckuins.html#x8
 503. http://www.columbia.edu/kermit/ckuins.html
 504. http://www.columbia.edu/kermit/ck60manual.html
 505. http://www.columbia.edu/kermit/ckubwr.html#top
 506. http://www.columbia.edu/kermit/ckubwr.html#contents
 507. http://www.columbia.edu/kermit/ckubwr.html#x9
 508. http://www.columbia.edu/kermit/ckubwr.html#x7
 509. http://www.columbia.edu/kermit/ckubwr.html#top
 510. http://www.columbia.edu/kermit/ckubwr.html#contents
 511. http://www.columbia.edu/kermit/ckubwr.html#x10
 512. http://www.columbia.edu/kermit/ckubwr.html#x8
 513. http://www.columbia.edu/kermit/ck60manual.html
 514. http://www.clark.net/pub/dickey/xterm/xterm.faq.html
 515. http://www.columbia.edu/kermit/ckubwr.html#top
 516. http://www.columbia.edu/kermit/ckubwr.html#contents
 517. http://www.columbia.edu/kermit/ckubwr.html#x11
 518. http://www.columbia.edu/kermit/ckubwr.html#x9
 519. http://www.columbia.edu/kermit/ckubwr.html#top
 520. http://www.columbia.edu/kermit/ckubwr.html#contents
 521. http://www.columbia.edu/kermit/ckubwr.html#x12
 522. http://www.columbia.edu/kermit/ckubwr.html#x10
 523. http://www.columbia.edu/kermit/ckubwr.html#x11.1
 524. http://www.columbia.edu/kermit/ckubwr.html#x11.2
 525. http://www.columbia.edu/kermit/ckubwr.html#top
 526. http://www.columbia.edu/kermit/ckubwr.html#contents
 527. http://www.columbia.edu/kermit/ckubwr.html#x11
 528. http://www.columbia.edu/kermit/ckubwr.html#x11.2
 529. http://www.columbia.edu/kermit/ck60manual.html
 530. http://www.columbia.edu/kermit/ckubwr.html#top
 531. http://www.columbia.edu/kermit/ckubwr.html#contents
 532. http://www.columbia.edu/kermit/ckubwr.html#x11
 533. http://www.columbia.edu/kermit/ckubwr.html#x11.1
 534. http://www.columbia.edu/kermit/ck60manual.html
 535. http://www.columbia.edu/kermit/ckubwr.html#top
 536. http://www.columbia.edu/kermit/ckubwr.html#contents
 537. http://www.columbia.edu/kermit/ckubwr.html#x13
 538. http://www.columbia.edu/kermit/ckubwr.html#x11
 539. http://www.columbia.edu/kermit/security.html
 540. http://www.columbia.edu/kermit/ckubwr.html#top
 541. http://www.columbia.edu/kermit/ckubwr.html#contents
 542. http://www.columbia.edu/kermit/ckubwr.html#x14
 543. http://www.columbia.edu/kermit/ckubwr.html#x12
 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#x15
 547. http://www.columbia.edu/kermit/ckubwr.html#x14
 548. mailto:[e-mail]
 549. http://www.stallion.com/
 550. http://www.columbia.edu/kermit/ckubwr.html#top
 551. http://www.columbia.edu/kermit/ckubwr.html#contents
 552. http://www.columbia.edu/kermit/ckermit.html
 553. http://www.columbia.edu/kermit/ck80.html
 554. http://www.columbia.edu/kermit/index.html
 555. http://www.columbia.edu/kermit/index.html
 556. http://www.columbia.edu/
 557. mailto:[e-mail]