- C-Kermit 8.0 Unix Hints and Tips
+ [1]The Columbia Crown The Kermit Project | Columbia University
+ 612 West 115th Street, New York NY 10025 USA o [2]kermit@columbia.edu
+ ...since 1981
+ [3]Home [4]Kermit 95 [5]C-Kermit [6]Scripts [7]Current [8]New [9]FAQ
+ [10]Support
+
+C-Kermit Unix Hints and Tips
Frank da Cruz
- [1]The Kermit Project, [2]Columbia University
+ [11]The Kermit Project, [12]Columbia University
- As of: C-Kermit 8.0.211 10 April 2004
- This page last updated: Fri Apr 16 16:13:14 2004 (New York USA Time)
+ As of: C-Kermit 9.0.300 30 June 2011
+ This page last updated: Wed Jul 6 10:02:34 2011 (New York USA Time)
- IF YOU ARE READING A PLAIN-TEXT version of this document, note it
- is a plain-text dump of a Web page. You can visit the original (and
+ IF YOU ARE READING A PLAIN-TEXT version of this document, note it is
+ a plain-text dump of a Web page. You can visit the original (and
possibly more up-to-date) Web page here:
- [3]http://www.columbia.edu/kermit/ckubwr.html
+ [13]http://www.columbia.edu/kermit/ckubwr.html
Since the material in this file has been accumulating since 1985,
- some (much) of it might be dated. [4]Feedback from experts on
- particular OS's and platforms is always welcome.
+ some (much) of it might be dated.
+
+Known problems with C-Kermit 9.0
- [ [5]C-Kermit ] [ [6]Installation Instructions ] [ [7]TUTORIAL ]
- ________________________________________________________________________
+ * Domain name resolution does not work in Solaris 10 or 11 (fixed in
+ [14]9.0.301).
+ * Opening new SSH sessions after closing previous ones sometimes
+ fails.
- CONTENTS
+ [ [15]C-Kermit ] [ [16]Installation Instructions ] [ [17]TUTORIAL ]
- 1. [8]INTRODUCTION
- 2. [9]PREBUILT C-KERMIT BINARIES
- 3. [10]PLATFORM-SPECIFIC NOTES
- 4. [11]GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
- 5. [12]INITIALIZATION AND COMMAND FILES
- 6. [13]COMMUNICATION SPEED SELECTION
- 7. [14]COMMUNICATIONS AND DIALING
- 8. [15]HARDWARE FLOW CONTROL
- 9. [16]TERMINAL CONNECTION AND KEY MAPPING
- 10. [17]FILE TRANSFER
- 11. [18]EXTERNAL FILE TRANSFER PROTOCOLS
- 12. [19]SECURITY
- 13. [20]MISCELLANEOUS USER REPORTS
- 14. [21]THIRD-PARTY DRIVERS
+CONTENTS
- Quick Links: [ [22]Linux ] [ [23]*BSD ] [[24]Mac OS X] [ [25]AIX ] [
- [26]HP-UX ] [ [27]Solaris ] [ [28]SCO ] [ [29]DEC/Compaq ]
- ________________________________________________________________________
+ 1. [18]INTRODUCTION
+ 2. [19]PREBUILT C-KERMIT BINARIES
+ 3. [20]PLATFORM-SPECIFIC NOTES
+ 4. [21]GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
+ 5. [22]INITIALIZATION AND COMMAND FILES
+ 6. [23]COMMUNICATION SPEED SELECTION
+ 7. [24]COMMUNICATIONS AND DIALING
+ 8. [25]HARDWARE FLOW CONTROL
+ 9. [26]TERMINAL CONNECTION AND KEY MAPPING
+ 10. [27]FILE TRANSFER
+ 11. [28]EXTERNAL FILE TRANSFER PROTOCOLS
+ 12. [29]SECURITY
+ 13. [30]MISCELLANEOUS USER REPORTS
+ 14. [31]THIRD-PARTY DRIVERS
- 1. INTRODUCTION
+ Quick Links: [ [32]Linux ] [ [33]*BSD ] [[34]Mac OS X] [ [35]AIX ] [
+ [36]HP-UX ] [ [37]Solaris ] [ [38]SCO ]
- [ [30]Top ] [ [31]Contents ] [ [32]Next ]
+1. INTRODUCTION
+
+ [ [39]Top ] [ [40]Contents ] [ [41]Next ]
SECTION CONTENTS
- 1.1. [33]Documentation
- 1.2. [34]Technical Support
- 1.3. [35]The Year 2000
- 1.4. [36]The Euro
+ 1.1. [42]Documentation
+ 1.2. [43]Technical Support
+ 1.3. [44]The Year 2000
+ 1.4. [45]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
(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.
+ 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
+ specific Unix variations like [46]Linux, [47]AIX, [48]HP-UX,
+ [49]Solaris, and so on, and should be read in conjunction with the
+ [50]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.
+ 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 [51]let me know.
- 1.1. Documentation
+1.1. Documentation
- [ [43]Top ] [ [44]Contents ] [ [45]Next ]
+ [ [52]Top ] [ [53]Contents ] [ [54]Next ]
- C-Kermit 6.0 is documented in the book [46]Using C-Kermit, Second
+ C-Kermit 6.0 is documented in the book [55]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
+ 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
+ [56]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
+ [57]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
+ [58]Supplement to Using C-Kermit, Second Edition, For C-Kermit 9.0
+ Thorough documentation of features new to version 9.0.
+
+1.2. Technical Support
- [ [49]Top ] [ [50]Contents ] [ [51]Section Contents ] [ [52]Next ] [
- [53]Previous ]
+ [ [59]Top ] [ [60]Contents ] [ [61]Section Contents ] [ [62]Next ] [
+ [63]Previous ]
For information on how to get technical support, please visit:
- [54]http://www.columbia.edu/kermit/support.html
+ [64]http://www.columbia.edu/kermit/support.html
- 1.3. The Year 2000
+1.3. The Year 2000
- [ [55]Top ] [ [56]Contents ] [ [57]Section Contents ] [ [58]Next ] [
- [59]Previous ]
+ [ [65]Top ] [ [66]Contents ] [ [67]Section Contents ] [ [68]Next ] [
+ [69]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.)
+ 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.
+ 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
+ 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
Command and script programming functions that deal with dates use
C-Kermit specific code that always uses full years.
- 1.4. The Euro
+1.4. The Euro
- [ [60]Top ] [ [61]Contents ] [ [62]Section Contents ] [ [63]Previous ]
+ [ [70]Top ] [ [71]Contents ] [ [72]Section Contents ] [ [73]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
+2. PREBUILT C-KERMIT BINARIES
- [ [64]Top ] [ [65]Contents ] [ [66]Next ] [ [67]Previous ]
+ [ [74]Top ] [ [75]Contents ] [ [76]Next ] [ [77]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
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.
+ 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.
+ 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
+3. NOTES ON SPECIFIC UNIX VERSIONS
- [ [68]Top ] [ [69]Contents ] [ [70]Next ] [ [71]Previous ]
+ [ [78]Top ] [ [79]Contents ] [ [80]Next ] [ [81]Previous ]
SECTION CONTENTS
- 3.0. [72]C-KERMIT ON PC-BASED UNIXES
- 3.1. [73]C-KERMIT AND AIX
- 3.2. [74]C-KERMIT AND HP-UX
- 3.3. [75]C-KERMIT AND LINUX
- 3.4. [76]C-KERMIT AND NEXTSTEP
- 3.5. [77]C-KERMIT AND QNX
- 3.6. [78]C-KERMIT AND SCO
- 3.7. [79]C-KERMIT AND SOLARIS
- 3.8. [80]C-KERMIT AND SUNOS
- 3.9. [81]C-KERMIT AND ULTRIX
- 3.10. [82]C-KERMIT AND UNIXWARE
- 3.11. [83]C-KERMIT AND APOLLO SR10
- 3.12. [84]C-KERMIT AND TANDY XENIX 3.0
- 3.13. [85]C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
- 3.14. [86]C-KERMIT AND SGI IRIX
- 3.15. [87]C-KERMIT AND THE BEBOX
- 3.16. [88]C-KERMIT AND DG/UX
- 3.17. [89]C-KERMIT AND SEQUENT DYNIX
- 3.18. [90]C-KERMIT AND {FREE,OPEN,NET}BSD
- 3.19. [91]C-KERMIT AND MAC OS X
- 3.20. [92]C-KERMIT AND COHERENT
+ 3.0. [82]C-KERMIT ON PC-BASED UNIXES
+ 3.1. [83]C-KERMIT AND AIX
+ 3.2. [84]C-KERMIT AND HP-UX
+ 3.3. [85]C-KERMIT AND LINUX
+ 3.4. [86]C-KERMIT AND NEXTSTEP
+ 3.5. [87]C-KERMIT AND QNX
+ 3.6. [88]C-KERMIT AND SCO
+ 3.7. [89]C-KERMIT AND SOLARIS
+ 3.8. [90]C-KERMIT AND SUNOS
+ 3.9. [91]C-KERMIT AND ULTRIX
+ 3.10. [92]C-KERMIT AND UNIXWARE
+ 3.11. [93]C-KERMIT AND APOLLO SR10
+ 3.12. [94]C-KERMIT AND TANDY XENIX 3.0
+ 3.13. [95]C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
+ 3.14. [96]C-KERMIT AND SGI IRIX
+ 3.15. [97]C-KERMIT AND THE BEBOX
+ 3.16. [98]C-KERMIT AND DG/UX
+ 3.17. [99]C-KERMIT AND SEQUENT DYNIX
+ 3.18. [100]C-KERMIT AND {FREE,OPEN,NET}BSD
+ 3.19. [101]C-KERMIT AND MAC OS X
+ 3.20. [102]C-KERMIT AND COHERENT
The following sections apply to specific Unix versions. Most of them
- contain references to FAQs (Frequently Asked Questions), but these
- tend to be ephemeral. For possibly more current information see:
+ contain references to FAQs (Frequently Asked Questions), but these tend
+ to be ephemeral. For possibly more current information see:
- [93]http://www.faqs.org
- [94]http://aplawrence.com/Unixart/newtounix.html
+ [103]http://www.faqs.org
+ [104]http://aplawrence.com/Unixart/newtounix.html
One thread that runs through many of them, and implicitly perhaps
through all, concerns the problems that occur when trying to dial out
on a serial device that is (also) enabled for dialing in. The
"solutions" to this problem are many, varied, diverse, and usually
gross, involving configuring the device for bidirectional use. This is
- done in a highly OS-dependent and often obscure manner, and the
- effects (good or evil) are also highly dependent on the particular OS
- (and getty variety, etc). Many examples are given in the
- [95]OS-specific sections below.
+ 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 [105]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
releases. If you think that C-Kermit is behaving badly or missing
something on your particular Unix version, you might be right -- we
can't claim to be expert in hundreds of different OS / version /
- hardware / library combinations. If you're a programmer, take a look
- at the source code and [96]send us your suggested fixes or changes. Or
- else just [97]send us a report about what seems to be wrong and we'll
+ hardware / library combinations. If you're a programmer, take a look at
+ the source code and [106]send us your suggested fixes or changes. Or
+ else just [107]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
+3.0. C-KERMIT ON PC-BASED UNIXES
- [ [98]Top ] [ [99]Contents ] [ [100]Section Contents ] [ [101]Next ]
+ [ [108]Top ] [ [109]Contents ] [ [110]Section Contents ] [ [111]Next ]
- Also see: [102]http://www.pcunix.com/.
+ Also see: [112]http://www.pcunix.com/.
SECTION CONTENTS
- 3.0.1. [103]Interrupt Conflicts
- 3.0.2. [104]Windows-Specific Hardware
- 3.0.3. [105]Modems
- 3.0.4. [106]Character Sets
- 3.0.5. [107]Keyboard, Screen, and Mouse Access
- 3.0.6. [108]Laptops
+ 3.0.1. [113]Interrupt Conflicts
+ 3.0.2. [114]Windows-Specific Hardware
+ 3.0.3. [115]Modems
+ 3.0.4. [116]Character Sets
+ 3.0.5. [117]Keyboard, Screen, and Mouse Access
+ 3.0.6. [118]Laptops
- 3.0.1. Interrupt Conflicts
+3.0.1. Interrupt Conflicts
- [ [109]Top ] [ [110]Contents ] [ [111]Section Contents ] [ [112]Next ]
+ [ [119]Top ] [ [120]Contents ] [ [121]Section Contents ] [ [122]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.
+ 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:
+ 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
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.
- ________________________________________________________________________
+ 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
+3.0.2. Windows-Specific Hardware
- [ [113]Top ] [ [114]Contents ] [ [115]Section Contents ] [ [116]Next ]
- [ [117]Previous ]
+ [ [123]Top ] [ [124]Contents ] [ [125]Section Contents ] [ [126]Next ]
+ [ [127]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,
+ Windows-based software drivers to do the jobs that you would expect the
+ device itself to do. PCMCIA, PCI, or "Plug-n-Play" devices are rarely
+ supported on PC-based Unix versions such as SCO; Winmodems,
Winprinters, and the like are not supported on any Unix variety (with
- [118]a few exceptions). The self-proclaimed Microsoft PC 97 (or later)
- standard only makes matters worse since its only purpose to ensure
- that PCs are "optimized to run Windows 95 and Windows NT 4.0 and
- future versions of these operating systems".
-
- With the exception noted (the Lucent modem, perhaps a handful of
- others by the time you read this), drivers for "Win" devices are
- available only for Windows, since the Windows market dwarfs that of
- any particular Unix brand, and for that matter all Unixes (or for that
- matter, all non-Windows operating systems) combined. If your version
- of Unix (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular
+ [128]a few exceptions). The self-proclaimed Microsoft PC 97 (or later)
+ standard only makes matters worse since its only purpose to ensure that
+ PCs are "optimized to run Windows 95 and Windows NT 4.0 and future
+ versions of these operating systems".
+
+ With the exception noted (the Lucent modem, perhaps a handful of others
+ by the time you read this), drivers for "Win" devices are available
+ only for Windows, since the Windows market dwarfs that of any
+ particular Unix brand, and for that matter all Unixes (or for that
+ matter, all non-Windows operating systems) combined. If your version of
+ Unix (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular
device, then C-Kermit can't use it either. C-Kermit, like any Unix
- application, must access all devices through drivers and not directly
+ application, must accesss 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
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.
+ version of each one) is potentially different. Third, a Winmodem driver
+ would be enormously complex; it would take years to write and debug, by
+ which time it would be obsolete.
A more recent generation of PCs (circa 1999-2000) is marketed as
- "Legacy Free". One can only speculate what that could mean. Most
- likely it means it will ONLY run the very latest versions of Windows,
- and is made exclusively of Winmodems, Winprinters, Winmemory, and
- Win-CPU-fans (Legacy Free is a concept [119]pioneered by Microsoft).
+ "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 [129]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
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.
- ________________________________________________________________________
+ 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
+3.0.3. Modems
- [ [120]Top ] [ [121]Contents ] [ [122]Section Contents ] [ [123]Next ]
- [ [124]Previous ]
+ [ [130]Top ] [ [131]Contents ] [ [132]Section Contents ] [ [133]Next ]
+ [ [134]Previous ]
External modems are recommended:
software will know how to control it.) For more about Unix compatible
modems, see:
- [125]http://www.idir.net/~gromitkc/winmodem.html
+ [135]http://www.idir.net/~gromitkc/winmodem.html
Remember that PCs, even now -- more than two decades after they were
first introduced -- are not (in general) capable of supporting more
than 2 serial devices. Here's a short success story from a recent
newsgroup posting: "I have a Diamond SupraSonic II dual modem in my
- machine. What I had to end up doing is buying a PS/2 mouse and port
- and install it. Had to get rid of my serial mouse. I also had to
- disable PnP in my computer bios. I was having IRQ conflicts between my
- serial mouse and 'com 3'. Both modems work fine for me. My first modem
- is ttyS0 and my second is ttyS1." Special third-party multiport boards
- such as [126]DigiBoard are available for certain Unix platforms
+ 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 [136]DigiBoard are available for certain Unix platforms
(typically SCO, maybe Linux) that come with special platform-specific
drivers.
- ________________________________________________________________________
- 3.0.4. Character Sets
+3.0.4. Character Sets
- [ [127]Top ] [ [128]Contents ] [ [129]Section Contents ] [ [130]Next ]
- [ [131]Previous ]
+ [ [137]Top ] [ [138]Contents ] [ [139]Section Contents ] [ [140]Next ]
+ [ [141]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
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:
+ 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
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).
- ________________________________________________________________________
+ 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
+3.0.5. Keyboard, Screen, and Mouse Access
- [ [132]Top ] [ [133]Contents ] [ [134]Section Contents ] [ [135]Next ]
- [ [136]Previous ]
+ [ [142]Top ] [ [143]Contents ] [ [144]Section Contents ] [ [145]Next ]
+ [ [146]Previous ]
Finally, note that as a real operating system, Unix (unlike Windows)
does not provide the intimate connection to the PC keyboard, screen,
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
+ is running on the PC's keyboard and screen to accesss these devices
directly, there are no APIs (outside of X) for this.
- ________________________________________________________________________
- 3.0.6. Laptops
+3.0.6. Laptops
- [ [137]Top ] [ [138]Contents ] [ [139]Section Contents ] [
- [140]Previous ]
+ [ [147]Top ] [ [148]Contents ] [ [149]Section Contents ] [
+ [150]Previous ]
(To be filled in . . .)
- ________________________________________________________________________
- 3.1. C-KERMIT AND AIX
+3.1. C-KERMIT AND AIX
- [ [141]Top ] [ [142]Contents ] [ [143]Section Contents ] [ [144]Next ]
- [ [145]Previous ]
+ [ [151]Top ] [ [152]Contents ] [ [153]Section Contents ] [ [154]Next ]
+ [ [155]Previous ]
SECTION CONTENTS
- 3.1.1. [146]AIX: General
- 3.1.2. [147]AIX: Network Connections
- 3.1.3. [148]AIX: Serial Connections
- 3.1.4. [149]AIX: File Transfer
- 3.1.5. [150]AIX: Xterm Key Map
+ 3.1.1. [156]AIX: General
+ 3.1.2. [157]AIX: Network Connections
+ 3.1.3. [158]AIX: Serial Connections
+ 3.1.4. [159]AIX: File Transfer
+ 3.1.5. [160]AIX: Xterm Key Map
For additional information see:
- * [151]http://www.emerson.emory.edu/services/aix-faq/
- * [152]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
- * [153]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/to
- p.html
- * [154]http://aixpdslib.seas.ucla.edu/
- * [155]http://www.rootvg.net (AIX history)
- * [156]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
- * [157]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/
- aix
+ * [161]http://www.emerson.emory.edu/services/aix-faq/
+ * [162]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
+ * [163]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top
+ .html
+ * [164]http://aixpdslib.seas.ucla.edu/
+ * [165]http://www.rootvg.net (AIX history)
+ * [166]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
+ * [167]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/a
+ ix
- and/or read the [158]comp.unix.aix newsgroup.
- ______________________________________________________________________
+ and/or read the [168]comp.unix.aix newsgroup.
+ ________________________________________________________________________
- 3.1.1. AIX: General
+3.1.1. AIX: General
- [ [159]Top ] [ [160]Contents ] [ [161]Section Contents ] [ [162]Next ]
+ [ [169]Top ] [ [170]Contents ] [ [171]Section Contents ] [ [172]Next ]
About AIX version numbers: "uname -a" tells the two-digit version
number, such as 3.2 or 4.1. The three-digit form can be seen with the
- "oslevel" command (this information is unavailable at the API level
- and is reportedly obtained by scanning the installed patch list).
+ "oslevel" command (this information is unavailable at the API level and
+ is reportedly obtained by scanning the installed patch list).
Supposedly all three-digit versions within the same two-digit version
(e.g. 4.3.1, 4.3.2) are binary compatible; i.e. a binary built on any
- one of them should run on all others, but who knows. Most AIX
- advocates tell you that any AIX binary will run on any AIX version
- greater than or equal to the one under which it was built, but
- experience with C-Kermit suggests otherwise. It is always best to run
- a binary built under your exact same AIX version, down to the third
- decimal place, if possible. Ideally, build it from source code
- yourself. Yes, this advice would be easier to follow if AIX came with
- a C compiler.
- ______________________________________________________________________
+ one of them should run on all others, but who knows. Most AIX advocates
+ tell you that any AIX binary will run on any AIX version greater than
+ or equal to the one under which it was built, but experience with
+ C-Kermit suggests otherwise. It is always best to run a binary built
+ under your exact same AIX version, down to the third decimal place, if
+ possible. Ideally, build it from source code yourself. Yes, this advice
+ would be easier to follow if AIX came with a C compiler.
+ ________________________________________________________________________
- 3.1.2. AIX: Network Connections
+3.1.2. AIX: Network Connections
- [ [163]Top ] [ [164]Contents ] [ [165]Section Contents ] [ [166]Next ]
- [ [167]Previous ]
+ [ [173]Top ] [ [174]Contents ] [ [175]Section Contents ] [ [176]Next ]
+ [ [177]Previous ]
File transfers into AIX 4.2 or 4.3 through the AIX Telnet or Rlogin
server have been observed to fail (or accumulate huge numbers of
removed from the picture; e.g, by using "set host * 3000" on AIX.
The problem can be completely cured by replacing the IBM Telnet server
- with [168]MIT's Kerberos Telnet server -- even if you don't actually
+ with [178]MIT's Kerberos Telnet server -- even if you don't actually
use the Kerberos part. Diagnosis: AIX pseudoterminals (which are
controlled by the Telnet server to give you a login terminal for your
session) have quirks that not even IBM knows about. The situation with
REDUCE SYSTEM LOAD.
REDUCE SERIAL PORT BAUD RATE
- Before leaving the topic of AIX pseudoterminals, it is very likely
- that Kermit's PTY and SSH commands do not work well either, for the
- same reason that Telnet connections into AIX don't work well. A brief
- test with "pty rlogin somehost" got a perfectly usable terminal
- (CONNECT) session, but file-transfer problems like those just
- described.
+ Before leaving the topic of AIX pseudoterminals, it is very likely that
+ Kermit's PTY and SSH commands do not work well either, for the same
+ reason that Telnet connections into AIX don't work well. A brief test
+ with "pty rlogin somehost" got a perfectly usable terminal (CONNECT)
+ session, but file-transfer problems like those just described.
Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports
- does not work unless the port number is in the /etc/services file;
- it's not clear from the report whether this is a problem with AIX
- Telnet (in which case it would not affect Kermit), or with the sockets
- library (in which case it would). The purported fix is IBM APAR
- IX61523.
+ does not work unless the port number is in the /etc/services file; it's
+ not clear from the report whether this is a problem with AIX Telnet (in
+ which case it would not affect Kermit), or with the sockets library (in
+ which case it would). The purported fix is IBM APAR IX61523.
C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to
another won't work right unless you set your local terminal type to
TELNET sends two escapes whenever you type one, and the AIX telnet
server swallows one of them. This has something to do with the "hft"
device. This behavior seems to be removed in AIX 3.2 and later.
- ______________________________________________________________________
+ ________________________________________________________________________
- 3.1.3. AIX: Serial Connections
+3.1.3. AIX: Serial Connections
- [ [169]Top ] [ [170]Contents ] [ [171]Section Contents ] [ [172]Next ]
- [ [173]Previous ]
+ [ [179]Top ] [ [180]Contents ] [ [181]Section Contents ] [ [182]Next ]
+ [ [183]Previous ]
In AIX 3, 4, or 5, C-Kermit won't be able to "set line /dev/tty0" (or
any other dialout device) if you haven't installed "cu" or "uucp" on
- your system, because installing these is what creates the UUCP
- lockfile directory. If SET LINE commands always result in "Sorry,
- access to lock denied", even when C-Kermit has been given the same
- owner, group, and permissions as cu:
+ your system, because installing these is what creates the UUCP lockfile
+ directory. If SET LINE commands always result in "Sorry, accesss 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
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:
+ 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
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.
+ 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."
+ 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.
+ 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
gives 9600 bps, but SET SPEED 19200 gives 19200 (on the built-in S1
port).
- Note that some RS/6000s (e.g. the IBM PowerServer 320) have
- nonstandard rectangular 10-pin serial ports; the DB-25 connector is
- NOT a serial port; it is a parallel printer port. IBM cables are
- required for the serial ports, (The IBM RT PC also had rectangular
- serial ports -- perhaps the same as these, perhaps different.)
+ 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):
+ 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
2. Tell C-Kermit to "set flow keep"; experimentation shows that SET
FLOW RTS/CTS has no effect when used in remote mode (i.e. on
/dev/tty, as opposed to a specify port device).
- 3. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support
- and other AIX bugs are available from IBM at:
- [174]http://service.software.ibm.com/rs6000/
- Downloads -> Software Fixes -> Download FixDist gets an
- application for looking up known problems.
+ 3. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support and
+ other AIX bugs are available from IBM at:
+ [184]http://service.software.ibm.com/rs6000/
+
+ Downloads -> Software Fixes -> Download FixDist gets an application
+ for looking up known problems.
Many problems reported with bidirectional terminal lines on AIX 3.2.x
on the RS/6000. Workaround: don't use bidirectional terminal lines, or
LINE. (But note: These problems MIGHT be fixed in C-Kermit 6.0 and
later.) The commands for turning getty off and on (respectively) are
/usr/sbin/pdisable and /usr/sbin/penable.
- ______________________________________________________________________
+ ________________________________________________________________________
- 3.1.4. AIX: File Transfer
+3.1.4. AIX: File Transfer
- [ [175]Top ] [ [176]Contents ] [ [177]Section Contents ] [ [178]Next ]
- [ [179]Previous ]
+ [ [185]Top ] [ [186]Contents ] [ [187]Section Contents ] [ [188]Next ]
+ [ [189]Previous ]
Evidently AIX 4.3 (I don't know about earlier versions) does not allow
open files to be overwritten. This can cause Kermit transfers to fail
varieties or earlier AIX versions.
Transfer of binary -- and maybe even text -- files can fail in AIX if
- the AIX terminal has particular port can have character-set
- translation done for it by the tty driver. The following advice from a
+ the AIX terminal has particular port can have character-set translation
+ done for it by the tty driver. The following advice from a
knowledgeable AIX user:
[This feature] has to be checked (and set/cleared) with a separate
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.
+ 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:
sign, "none" being the value we want for C-Kermit. Of course, the
above can also be changed by using the SMIT utility and selecting
devices - tty. (...end quote)
- ______________________________________________________________________
- 3.1.5. AIX: Xterm Key Map
+ In 2007 I noticed the following on high-speed SSH connections (local
+ network) into AIX 5.3: streaming transfers into AIX just don't work.
+ The same might be true for Telnet connections; I have no way to check.
+ It appears that the AIX pty driver and/or the SSH (and possibly Telnet)
+ server are not capable of receiving a steady stream of incoming data at
+ high speed. Solution: unknown. Workaround: put "set streaming off" in
+ your .kermrc or .mykermrc file, since streaming is the default for
+ network connections.
+ ________________________________________________________________________
+
+3.1.5. AIX: Xterm Key Map
- [ [180]Top ] [ [181]Contents ] [ [182]Section Contents ] [
- [183]Previous ]
+ [ [190]Top ] [ [191]Contents ] [ [192]Section Contents ] [
+ [193]Previous ]
Here is a sample configuration for setting up an xterm keyboard for
VT220 or higher terminal emulation on AIX, courtesy of Bruce Momjian,
*cursesemul: true
*scrollKey: true
*scrollBar: true
- ________________________________________________________________________
- 3.2. C-KERMIT AND HP-UX
+3.2. C-KERMIT AND HP-UX
- [ [184]Top ] [ [185]Contents ] [ [186]Section Contents ] [ [187]Next ]
- [ [188]Previous ]
+ [ [194]Top ] [ [195]Contents ] [ [196]Section Contents ] [ [197]Next ]
+ [ [198]Previous ]
SECTION CONTENTS
- 3.2.0. [189]Common Problems
- 3.2.1. [190]Building C-Kermit on HP-UX
- 3.2.2. [191]File Transfer
- 3.2.3. [192]Dialing Out and UUCP Lockfiles in HP-UX
- 3.2.4. [193]Notes on Specific HP-UX Releases
- 3.2.5. [194]HP-UX and X.25
+ 3.2.0. [199]Common Problems
+ 3.2.1. [200]Building C-Kermit on HP-UX
+ 3.2.2. [201]File Transfer
+ 3.2.3. [202]Dialing Out and UUCP Lockfiles in HP-UX
+ 3.2.4. [203]Notes on Specific HP-UX Releases
+ 3.2.5. [204]HP-UX and X.25
REFERENCES
- For further information, read the [195]comp.sys.hp.hpux newsgroup.
+ For further information, read the [205]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
the problem. The true fix in each situation is to install the current
release of C-Kermit.
- 3.2.0. Common Problems
+3.2.0. Common Problems
- [ [196]Top ] [ [197]Contents ] [ [198]Section Contents ] [ [199]Next ]
+ [ [206]Top ] [ [207]Contents ] [ [208]Section Contents ] [ [209]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.
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
+ 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
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).
- ________________________________________________________________________
+ 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
+3.2.1. Building C-Kermit on HP-UX
- [ [200]Top ] [ [201]Contents ] [ [202]Section Contents ] [ [203]Next ]
- [ [204]Previous ]
+ [ [210]Top ] [ [211]Contents ] [ [212]Section Contents ] [ [213]Next ]
+ [ [214]Previous ]
- This section applies mainly to old (pre-10.20) HP-UX version on
- old, slow, and/or memory-constrained hardware.
+ 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
+ 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.
+ periods of time, like 9 hours. This problem is handled by compiling the
+ modules that tickle it without optimization; the new C-Kermit makefile
+ takes care of this, and shows how to do it in case the same thing
+ begins happening with other modules.
+
+ On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment
+ size), seems to be important. On Motorola systems, it is 16MB by
+ default, whereas on RISC systems the default is much bigger. Increasing
+ maxdsiz to about 80MB seems to make the problem go away, but only if
+ the system also has a lot of physical memory -- otherwise it swaps
+ itself to death.
The optimizing compiler might complain about "some optimizations
skipped" on certain modules, due to lack of space available to the
optimizer. You can increase the space (the incantation depends on the
- particular compiler version -- see the [205]makefile), but doing so
+ particular compiler version -- see the [215]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*
In the makefile, all HP-UX entries automatically skip optimization of
problematic modules.
- ________________________________________________________________________
- 3.2.2. File Transfer
+3.2.2. File Transfer
- [ [206]Top ] [ [207]Contents ] [ [208]Section Contents ] [ [209]Next ]
- [ [210]Previous ]
+ [ [216]Top ] [ [217]Contents ] [ [218]Section Contents ] [ [219]Next ]
+ [ [220]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
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.
+ 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......
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).
+ 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
+ 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......
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
+ 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
+3.2.3. Dialing Out and UUCP Lockfiles in HP-UX
- [ [211]Top ] [ [212]Contents ] [ [213]Section Contents ] [ [214]Next ]
- [ [215]Previous ]
+ [ [221]Top ] [ [222]Contents ] [ [223]Section Contents ] [ [224]Next ]
+ [ [225]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;
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).
+ 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).
+ 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
---------------------------------------------------------------------
<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",
+ 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 accesss 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:
+ programs (Kermit, cu, etc, and UUCP itself) from accesssing 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.
+ 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
+ accesssing 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"
"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
+ "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
+ Selection Lockfile 1 Lockfile 2
/dev/tty0p0 LCK..tty0p0 (none)
* /dev/ttyd0p0 LCK..ttyd0p0 (none)
/dev/cua0p0 LCK..cua0p0 LCK..ttyd0p0
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.
+ dialin accesss 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
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.
+ 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.
+ 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 accesss 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
+ 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
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.
+ 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:
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
+ 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.
+ (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
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
+3.2.4 Notes on Specific HP-UX Releases
SECTION CONTENTS
- 3.2.4.1. [216]HP-UX 11
- 3.2.4.2. [217]HP-UX 10
- 3.2.4.3. [218]HP-UX 9
- 3.2.4.4. [219]HP-UX 8
- 3.2.4.5. [220]HP-UX 7 and Earlier
+ 3.2.4.1. [226]HP-UX 11
+ 3.2.4.2. [227]HP-UX 10
+ 3.2.4.3. [228]HP-UX 9
+ 3.2.4.4. [229]HP-UX 8
+ 3.2.4.5. [230]HP-UX 7 and Earlier
- 3.2.4.1. HP-UX 11
+3.2.4.1. HP-UX 11
- [ [221]Top ] [ [222]Contents ] [ [223]Section Contents ] [ [224]Next ]
+ [ [231]Top ] [ [232]Contents ] [ [233]Section Contents ] [ [234]Next ]
- As noted in [225]Section 3.2.2, the HP-UX 11 Telnet server and/or
+ As noted in [235]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:
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:
+ 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
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
+3.2.4.2. HP-UX 10
- [ [226]Top ] [ [227]Contents ] [ [228]Section Contents ] [ [229]Next ]
- [ [230]Previous ]
+ [ [236]Top ] [ [237]Contents ] [ [238]Section Contents ] [ [239]Next ]
+ [ [240]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
+ 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
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.
- ________________________________________________________________________
+ 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
+3.2.4.3. HP-UX 9
- [ [231]Top ] [ [232]Contents ] [ [233]Section Contents ] [ [234]Next ]
- [ [235]Previous ]
+ [ [241]Top ] [ [242]Contents ] [ [243]Section Contents ] [ [244]Next ]
+ [ [245]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
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
+ 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.
- ________________________________________________________________________
+ 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
+3.2.4.4. HP-UX 8
- [ [236]Top ] [ [237]Contents ] [ [238]Section Contents ] [ [239]Next ]
- [ [240]Previous ]
+ [ [246]Top ] [ [247]Contents ] [ [248]Section Contents ] [ [249]Next ]
+ [ [250]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,
On HP-UX 8 DON'T install 'tty patch' PHKL_4656, install PHKL_3047
instead! Yesterday I tried this latest tty patch PHKL_4656 and had
- terrible problems. This patch should fix RTS/CTS problems. With
- text transver all looks nice. But when I switched over to binary
- files the serial interface returned only rubish to C-Kermit. All
- sorts of protocol, CRC and packed errors I had. After several tests
- and after uninstalling that patch, all transvers worked fine. MB's
- of data without any errors. So keep your fingers away from that
- patch. If anybody needs the PHKL_3047 patch I have it here. It is
- no longer availabel from HP's patch base.
- ________________________________________________________________________
-
- 3.2.4.5. HP-UX 7 and Earlier
-
- [ [241]Top ] [ [242]Contents ] [ [243]Section Contents ] [
- [244]Previous ]
-
- When transferring files into HP-UX 5 or 6 over a Telnet connection,
- you must not use streaming, and you must not use a packet length
- greater than 512. However, you can use streaming and longer packets
- when sending files from HP-UX on a Telnet connection. In C-Kermit 8.0,
- the default receive packet length for HP-UX 5 and 6 was changed to 500
- (but you can still increase it with SET RECEIVE PACKET-LENGTH if you
- wish, e.g. for non-Telnet connections). Disable streaming with SET
- STREAMING OFF.
+ terrible problems. This patch should fix RTS/CTS problems. With text
+ transfer 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 transfers 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
+ available from HP's patch base.
+
+3.2.4.5. HP-UX 7 and Earlier
+
+ [ [251]Top ] [ [252]Contents ] [ [253]Section Contents ] [
+ [254]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.
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.)
- ________________________________________________________________________
+ 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
+3.2.5. HP-UX and X.25
- [ [245]Top ] [ [246]Contents ] [ [247]Section Contents ] [
- [248]Previous ]
+ [ [255]Top ] [ [256]Contents ] [ [257]Section Contents ] [
+ [258]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:
+ 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
+3.3. C-KERMIT AND LINUX
- [ [249]Top ] [ [250]Contents ] [ [251]Section Contents ] [ [252]Next ]
- [ [253]Previous ]
+ [ [259]Top ] [ [260]Contents ] [ [261]Section Contents ] [ [262]Next ]
+ [ [263]Previous ]
SECTION CONTENTS
- 3.3.1. [254]Problems Building C-Kermit for Linux
- 3.3.2. [255]Problems with Serial Devices in Linux
- 3.3.3. [256]Terminal Emulation in Linux
- 3.3.4. [257]Dates and Times
- 3.3.5. [258]Startup Errors
- 3.3.6. [259]The Fullscreen File Transfer Display
+ 3.3.1. [264]Problems Building C-Kermit for Linux
+ 3.3.2. [265]Problems with Serial Devices in Linux
+ 3.3.3. [266]Terminal Emulation in Linux
+ 3.3.4. [267]Dates and Times
+ 3.3.5. [268]Startup Errors
+ 3.3.6. [269]The Fullscreen File Transfer Display
+
+ (August 2010) Reportedly C-Kermit packages for certain Linux
+ distributions such as Centos and Ubuntu have certain features
+ disabled, for example the SSH command, SET HOST PTY /SSH, and
+ perhaps anything else to do with SSH and/or pseudoterminals and who
+ knows what else. If you download the regular package ("tarball")
+ from the Kermit Project and build from it ("make linux"), everything
+ is fine.
+
+ C-Kermit in Ubuntu 10.04 and 9.10 was reported slow to start because
+ it was trying to resolve the IP address 255.255.255.255. Later, also
+ in recent Debian versions. The following is seen in the strace:
+
+write(3, "RESOLVE-ADDRESS 255.255.255.255\n", 32)
+
+ This is not Kermit Project code. Turns out to be something in
+ glibc's resolver, and can be fixed by changing /etc/nsswitch.conf,
+ but it might break other software, such as [270]Avahi or anything
+ (such as Gnome, Java, or Cups) that depends on it. I'm not sure
+ where it happens; I don't think Kermit tries to get its IP address
+ at startup time, only when it's needed or asked for, e.g. when
+ making a connection or evaluating \v(ipaddress).
REFERENCES
- For further information, read the [260]comp.os.linux.misc,
- [261]comp.os.linux.answers, and other Linux-oriented newsgroups, and
+ For further information, read the [271]comp.os.linux.misc,
+ [272]comp.os.linux.answers, and other Linux-oriented newsgroups, and
see:
The Linux Document Project (LDP)
- [262]http://www.tldp.org/
+ [273]http://www.tldp.org/
The Linux FAQ
- [263]http://www.tldp.org/FAQ/Linux-FAQ.html
+ [274]http://www.tldp.org/FAQ/Linux-FAQ.html
The Linux HOWTOs (especially the Serial HOWTO)
- [264]http://www.tldp.org/HOWTO/Serial-HOWTO.html
+ [275]http://www.tldp.org/HOWTO/Serial-HOWTO.html
- [265]http://tldp.org/HOWTO/Modem-HOWTO.html
+ [276]http://tldp.org/HOWTO/Modem-HOWTO.html
- [266]ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
+ [277]ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
- [267]ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
+ [278]ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
- [268]http://www.tldp.org/HOWTO/
+ [279]http://www.tldp.org/HOWTO/
- [269]http://www.tldp.org/hmirrors.html
+ [280]http://www.tldp.org/hmirrors.html
Linux Vendor Tech Support Pages:
- [270]http://www.redhat.com/apps/support/
+ [281]http://www.redhat.com/apps/support/
- [271]http://www.debian.org/support
+ [282]http://www.debian.org/support
- [272]http://www.slackware.com/support/
+ [283]http://www.slackware.com/support/
- [273]http://www.caldera.com/support/
+ [284]http://www.caldera.com/support/
- [274]http://www.suse.com/support/
+ [285]SUSE Linux Support
- [275]http://www.mandrake.com/support/
+ [286]http://www.mandrake.com/support/
- [276]http://www.turbolinux.com/support/
+ [287]http://www.turbolinux.com/support/
Linux Winmodem Support
- [277]http://www.linmodems.org/
+ [288]http://www.linmodems.org/
- Also see general comments on PC-based Unixes in [278]Section 3.0.
+ Also see general comments on PC-based Unixes in [289]Section 3.0.
What Linux version is it? -- "uname -a" supplies only kernel
- information, but these days it's the distribution that matters: Red
- Hat 7.3, Debian 2.2, Slackware 8.0, etc. Unfortunately there's no
+ information, but these days it's the distribution that matters: Red Hat
+ 7.3, Debian 2.2, Slackware 8.0, etc. Unfortunately there's no
consistent way to get the distribution version. Usually it's in a
distribution-specific file:
Did you know: DECnet is available for Linux? See:
- [279]http://linux.dreamtime.org/decnet/
+ [290]http://linux.dreamtime.org/decnet/
(But there is no support for it in C-Kermit -- anybody interested in
- adding it, please [280]let us know).
+ adding it, please [291]let me know).
Before proceeding, let's handle the some of the most frequently asked
question in the Linux newsgroups:
- 1. Neither C-Kermit nor any other Linux application can use
- Winmodems, except in the [281]rare cases where Linux drivers have
- been written for them. See [282]Section 3.0.2 for details.
+ 1. Neither C-Kermit nor any other Linux application can use Winmodems,
+ except in the [292]rare cases where Linux drivers have been written
+ for them. See [293]Section 3.0.2 for details.
2. "Why does it take such a long time to make a telnet connection to
(or from) my Linux PC?" (this applies to C-Kermit and to regular
- Telnet). Most telnet servers these days perform reverse DNS
- lookups on the client (for security and/or logging reasons). If
- the Telnet client's address cannot be found by the server's local
- DNS server, the DNS request goes out to the Internet at large, and
- this can take quite some time. The solution to this problem is to
- make sure that both client and host are registered in DNS, and
- that the registrations are exported. C-Kermit itself performs
- reverse DNS lookups unless you tell it not to; this is to allow
- C-Kermit to let you know which host it is actually connected to in
- case you have made a connection to a host pool (multihomed host).
- You can disable C-Kermit's reverse DNS lookup with SET TCP
- REVERSE-DNS-LOOKUP OFF.
+ Telnet). Most telnet servers these days perform reverse DNS lookups
+ on the client (for security and/or logging reasons). If the Telnet
+ client's address cannot be found by the server's local DNS server,
+ the DNS request goes out to the Internet at large, and this can
+ take quite some time. The solution to this problem is to make sure
+ that both client and host are registered in DNS, and that the
+ registrations are exported. C-Kermit itself performs reverse DNS
+ lookups unless you tell it not to; this is to allow C-Kermit to let
+ you know which host it is actually connected to in case you have
+ made a connection to a host pool (multihomed host). You can disable
+ C-Kermit's reverse DNS lookup with SET TCP REVERSE-DNS-LOOKUP OFF.
3. (Any question that has the word "Telnet" in it...) The knee-jerk
- reaction is "don't use Telnet, use SSH!" There's nothing wrong
- with Telnet. In fact it's far superior to SSH as a protocol in
- terms of features and extensibility, not to mention platform
- neutrality. The issue lurking behind the knee-jerk reaction is
- security. SSH is thought to be secure, whereas Telnet is thought
- to be insecure. This is true for clear-text Telnet (because
- passwords travel in the clear across the network), but apparently
- few people realize that [283]secure Telnet clients and servers
- have been available for years, and these are more secure than SSH
- (for reasons explained [284]HERE.
+ reaction is "don't use Telnet, use SSH!" There's nothing wrong with
+ Telnet. In fact it's far superior to SSH as a protocol in terms of
+ features and extensibility, not to mention platform neutrality. The
+ issue lurking behind the knee-jerk reaction is security. SSH is
+ thought to be secure, whereas Telnet is thought to be insecure.
+ This is true for clear-text Telnet (because passwords travel in the
+ clear across the network), but apparently few people realize that
+ [294]secure Telnet clients and servers have been available for
+ years, and these are more secure than SSH (for reasons explained
+ [295]HERE).
4. (Any question that has the word "FTP" in it...) The knee-jerk
reaction being "Don't use FTP, use SCP!" (or SFTP). Same answer as
above, but moreso. SCP and SFTP are not only not platform neutral,
- they're diversity-hostile. They transfer files only in binary
- mode, which mangles text files across different platforms, to the
- same degree the platform's text-file record format and character
- set differ. An extreme example would be an Variable-Block format
- EBCDIC text file on an IBM mainframe, binary transfer of which to
- Unix would do you little good indeed. FTP was designed with
- diversity in mind and secure versions are available.
- ________________________________________________________________________
+ they're diversity-hostile. They transfer files only in binary mode,
+ which mangles text files across different platforms, to the same
+ degree the platform's text-file record format and character set
+ differ. An extreme example would be an Variable-Block format EBCDIC
+ text file on an IBM mainframe, binary transfer of which to Unix
+ would do you little good indeed. FTP was designed with diversity in
+ mind and secure versions are available.
- 3.3.1. Problems Building C-Kermit for Linux
+3.3.1. Problems Building C-Kermit for Linux
- [ [285]Top ] [ [286]Contents ] [ [287]Section Contents ] [ [288]Next ]
+ [ [296]Top ] [ [297]Contents ] [ [298]Section Contents ] [ [299]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.
+ installation whether to include "developer tools". Obviously, you can't
+ build C-Kermit or any other C program from source code if you have not
+ installed the developer tools. But to confuse matters, you might also
+ have to choose (separately) to install the "curses" or "ncurses"
+ terminal control library; thus it is possible to install the C compiler
+ and linker, but omit the (n)curses library and headers. If curses is
+ not installed, you will not be able to build a version of C-Kermit that
+ supports the fullscreen file-transfer display, in which case you'll
+ need to use the "linuxnc" makefile target (nc = No Curses) or else
+ install ncurses before building.
There are all sorts of confusing issues caused by the many and varied
Linux distributions. Some of the worst involve the curses library and
- header files: where are they, what are they called, which ones are
- they really? Other vexing questions involve libc5 vs libc6 vs glibc vs
+ header files: where are they, what are they called, which ones are they
+ really? Other vexing questions involve libc5 vs libc6 vs glibc vs
glibc2 (C libraries), gcc vs egcs vs lcc (compilers), plus using or
avoiding features that were added in a certain version of Linux or a
library or a distribution, and are not available in others. As of
C-Kermit 8.0, these questions should be resolved by the "linux"
makefile target itself, which does a bit of looking around to see
what's what, and then sets the appropriate CFLAGS.
- ________________________________________________________________________
- 3.3.2. Problems with Serial Devices in Linux
+3.3.2. Problems with Serial Devices in Linux
- [ [289]Top ] [ [290]Contents ] [ [291]Section Contents ] [ [292]Next ]
- [ [293]Previous ]
+ [ [300]Top ] [ [301]Contents ] [ [302]Section Contents ] [ [303]Next ]
+ [ [304]Previous ]
Also see: "man setserial", "man irqtune".
- And: [294]Sections 3.0, [295]6, [296]7, and [297]8 of this
- document.
+ And: [305]Sections 3.0, [306]6, [307]7, and [308]8 of this document.
NOTE: Red Hat Linux 7.2 and later include a new API that allows
- serial-port arbitration by non-setuid/gid programs. This API has
- not yet been added to C-Kermit. If C-Kermit is to be used for
- dialing out on Red Hat 7.2 or later, it must still be installed as
- described in in Sections [298]10 and [299]11 of the
- [300]Installation Instructions.
+ serial-port arbitration by non-setuid/gid programs. This API has not
+ yet been added to C-Kermit. If C-Kermit is to be used for dialing
+ out on Red Hat 7.2 or later, it must still be installed as described
+ in in Sections [309]10 and [310]11 of the [311]Installation
+ Instructions.
Don't expect it to be easy. Queries like the following are posted to
the Linux newsgroups almost daily:
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
+ show me AT-style commands exchanged so I have no reason to believe
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.
+ 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:
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.
+ calling pnpdump but pnpdump returns "no boards found". I have looked
+ around on my BIOS (Phoenix) and there is not much evidence of it
+ being PNP aware. However for what it calls "Serial port A", it
+ offers a choice of Auto, Disabled or Manual settings (currently set
+ to Auto), but using the BIOS interface I tried to change to 'manual'
+ and saw the default settings offered to be were 0x3F8 and IRQ 4
+ (COM1). The BIOS menus did not give me any chance to configure COM2
+ or any "modem". I ended up not saving any BIOS changes in the course
+ of my investigations.
You can also find out a fair amount about your PC's hardware
configuration in the text files in /proc, e.g.:
-r--r--r-- 1 root 0 Sep 4 14:00 /proc/ioports
-r--r--r-- 1 root 0 Sep 4 14:00 /proc/pci
- From the directory listing they look like empty files, but in fact
- they are text files that you "cat":
+ From the directory listing they look like empty files, but in fact they
+ are text files that you "cat":
$ cat /proc/pci
Bus 0, device 14, function 0:
15: 6 XT-PIC ide1
Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the
- like (see cautions in [301]Section 3.0 Linux supports Plug-n-Play
+ like (see cautions in [312]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
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.
+ 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
+ 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.
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.)
+ 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:
+ 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
+ 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.
+ 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
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):
+ Note that the cua device is now "deprecated", and new editions of Linux
+ will phase (have phased) it out in favor of the ttyS device. See (if
+ it's still there):
- [302]http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
+ [313]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.
+ (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").
+ 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
+3.3.3. Terminal Emulation in Linux
- [ [303]Top ] [ [304]Contents ] [ [305]Section Contents ] [ [306]Next ]
- [ [307]Previous ]
+ [ [314]Top ] [ [315]Contents ] [ [316]Section Contents ] [ [317]Next ]
+ [ [318]Previous ]
C-Kermit is not a terminal emulator. For a brief explanation of why
- not, see [308]Section 3.0.5. For a fuller explanation, [309]ClICK
- HERE.
+ not, see [319]Section 3.0.5. For a fuller explanation, [320]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:
+ xterm window, which gives VTxxx emulation. An xterm that includes color
+ ANSI and VT220 emulation is available with Xfree86:
- [310]http://dickey.his.com/xterm/xterm.html
+ [321]http://dickey.his.com/xterm/xterm.html
- Before starting C-Kermit in an xterm window, you might need to tell
- the xterm window's shell to "stty sane".
+ 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
Console-mode keys are mapped separately using loadkeys, and different
keycodes are used. Find out what they are with showkey.
- For a much more complete VT220/320 key mapping for [311]Xfree86 xterm,
- [312]CLICK HERE.
- ________________________________________________________________________
+ For a much more complete VT220/320 key mapping for [322]Xfree86 xterm,
+ [323]CLICK HERE.
- 3.3.4. Dates and Times
+3.3.4. Dates and Times
- [ [313]Top ] [ [314]Contents ] [ [315]Section Contents ] [ [316]Next ]
- [ [317]Previous ]
+ [ [324]Top ] [ [325]Contents ] [ [326]Section Contents ] [ [327]Next ]
+ [ [328]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.
+ each must be set independently.
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
+3.3.5. Startup Errors
- [ [318]Top ] [ [319]Contents ] [ [320]Section Contents ] [ [321]Next ]
- [ [322]Previous ]
+ [ [329]Top ] [ [330]Contents ] [ [331]Section Contents ] [ [332]Next ]
+ [ [333]Previous ]
C-Kermit should work on all versions of Linux current through March
- 2003, provided it was built on the same version you have, with the
- same libraries and header files (just get the source code and "make
- linux"). Binaries tend not to travel well from one Linux machine to
- another, due to their many differences. There is no guarantee that a
- particular C-Kermit binary will not stop working at a later date,
- since Linux tends to change out from under its applications. If that
- happens, rebuild C-Kermit from source. If something goes wrong with
- the build process, look on the [323]C-Kermit website for a newer
- version. If you have the latest version, then [324]report the problem
- to us.
+ 2003, provided it was built on the same version you have, with the same
+ libraries and header files (just get the source code and "make linux").
+ Binaries tend not to travel well from one Linux machine to another, due
+ to their many differences. There is no guarantee that a particular
+ C-Kermit binary will not stop working at a later date, since Linux
+ tends to change out from under its applications. If that happens,
+ rebuild C-Kermit from source. If something goes wrong with the build
+ process, look on the [334]C-Kermit website for a newer version. If you
+ have the latest version, then [335]report the problem to us.
Inability to transfer files in Red Hat 7.2: the typical symptom would
- be if you start Kermit and tell it to RECEIVE, it fails right away
- with "?/dev/tty: No such device or address" or "?Bad file descriptor".
- One report says this is because of csh, and if you change your shell
- to bash or other shell, it doesn't happen. Another report cite bugs in
- Red Hat 7.2 Telnetd "very seldom (if ever) providing a controlling
- tty, and lots of other people piled on saying they have the same
- problem.") A third theory is that this happens only when Linux has
- been installed without "virtual terminal support".
+ 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
assigning a controlling TTY for the session, which would make most use
of "/dev/tty" somewhat less than useful.
- [325]http://www.redhat.com/support/errata/RHBA-2001-153.html
+ [336]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."
+ not find the controlling terminal correctly, and a shell in single user
+ mode would exhibit strange terminal input characteristics. This update
+ fixes both of these problems."
Since the Red Hat 5.1 release (circa August 1998), there have been
numerous reports of prebuilt Linux executables, and particularly the
Kermit RPM for Red Hat Linux, not working; either it won't start at
all, or it gives error messages about "terminal type unknown" and
refuses to initialize its curses support. The following is from the
- [326]Kermit newsgroup:
+ [337]Kermit newsgroup:
From: rchandra@hal9000.buf.servtech.com
Newsgroups: comp.protocols.kermit.misc
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.)
+ 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).
+ 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
+ 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
+ can be accesssed 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.
+ 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
+3.3.6. The Fullscreen File Transfer Display
- [ [327]Top ] [ [328]Contents ] [ [329]Section Contents ] [
- [330]Previous ]
+ [ [338]Top ] [ [339]Contents ] [ [340]Section Contents ] [
+ [341]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:
+ 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:
In Red Hat 7.1, when using C-Kermit in a Gnome terminal window, it was
noticed that when the fullscreen file transfer display exits (via
- endwin()), the previous (pre-file-transfer-display) screen is
- restored. Thus you can't look at the completed display to see what
- happened. This is a evidently a new feature of xterm. I can only
- speculate that initscreen() and endwin() must send some kind of
- special escape sequences that command xterm to save and restore the
- screen. To defeat this effect, tell Linux you have a vt100 or other
- xterm-compatible terminal that is not actually an xterm, or else tell
- Kermit to SET TRANSFER DISPLAY to something besides FULLSCREEN.
- ________________________________________________________________________
+ endwin()), the previous (pre-file-transfer-display) screen is restored.
+ Thus you can't look at the completed display to see what happened. This
+ is a evidently a new feature of xterm. I can only speculate that
+ initscreen() and endwin() must send some kind of special escape
+ sequences that command xterm to save and restore the screen. To defeat
+ this effect, tell Linux you have a vt100 or other xterm-compatible
+ terminal that is not actually an xterm, or else tell Kermit to SET
+ TRANSFER DISPLAY to something besides FULLSCREEN.
- 3.4. C-KERMIT AND NEXTSTEP
+3.4. C-KERMIT AND NEXTSTEP
- [ [331]Top ] [ [332]Contents ] [ [333]Section Contents ] [ [334]Next ]
- [ [335]Previous ]
+ [ [342]Top ] [ [343]Contents ] [ [344]Section Contents ] [ [345]Next ]
+ [ [346]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
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
+ 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"):
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).
+ 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.
+ 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
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.
- ________________________________________________________________________
+ 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
+3.5. C-KERMIT AND QNX
- [ [336]Top ] [ [337]Contents ] [ [338]Section Contents ] [ [339]Next ]
- [ [340]Previous ]
+ [ [347]Top ] [ [348]Contents ] [ [349]Section Contents ] [ [350]Next ]
+ [ [351]Previous ]
- See also: The [341]comp.os.qnx newsgroup.
+ See also: The [352]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,
successfully (after stripping most most features, I succeeded in
getting it to compile and link without complaint, but the executable
just beeps when you run it); for 16-bit QNX 4.2x, use C-Kermit 6.0 or
- earlier, or else [342]G-Kermit.
+ earlier, or else [353]G-Kermit.
The 32-bit version (and the 16-bit version prior to C-Kermit 7.0)
supports most of C-Kermit's advanced features including TCP/IP, high
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
+ 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
-DNOUUCP switch. This is because QNX, as distributed, does not include
UUCP, and its own communications software (e.g. qterm) does not use
UUCP line locking. If you have a UUCP product installed on your QNX
- system, remove the -DNOUUCP switch from the makefile entry and
- rebuild. Then check to see that Kermit's UUCP lockfile conventions are
- the same as those of your UUCP package; if not, read the [343]UUCP
- lockfile section of the [344]Installation Instructions and make the
- necessary changes to the makefile entry (e.g. add -DHDBUUCP).
+ 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 [354]UUCP lockfile
+ section of the [355]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:
+ 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...
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
+3.6. C-KERMIT AND SCO
- [ [345]Top ] [ [346]Contents ] [ [347]Section Contents ] [ [348]Next ]
- [ [349]Previous ]
+ [ [356]Top ] [ [357]Contents ] [ [358]Section Contents ] [ [359]Next ]
+ [ [360]Previous ]
SECTION CONTENTS
-3.6.1. [350]SCO XENIX
-3.6.2. [351]SCO UNIX and OSR5
-3.6.3. [352]Unixware
-3.6.4. [353]Open UNIX 8
+3.6.1. [361]SCO XENIX
+3.6.2. [362]SCO UNIX and OSR5
+3.6.3. [363]Unixware
+3.6.4. [364]Open UNIX 8
REFERENCES
* The comp.unix.sco.* newsgroups.
- * [354]Section 3.10 below for Unixware.
+ * [365]Section 3.10 below for Unixware.
* The following FAQs:
The comp.sco.misc FAQ:
- [355]http://aplawrence.com/SCOFAQ/
+ [366]http://aplawrence.com/SCOFAQ/
Caldera (SCO) comp.unix.sco.programmer FAQ:
- [356]http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
+ [367]http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
The UnixWare 7/OpenUNIX 8 FAQ:
- [357]http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
- [358]http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
+ [368]http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
+ [369]http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
High Speed Modems for SCO Unix:
- [359]http://pcunix.com/Unixart/modems.html
+ [370]http://pcunix.com/Unixart/modems.html
The UnixWare FAQ
- [360]http://www.freebird.org/faq/
+ [371]http://www.freebird.org/faq/
The UnixWare 1.x and 2.0 Programmer FAQ
- [361]http://www.freebird.org/faq/developer.html
+ [372]http://www.freebird.org/faq/developer.html
Caldera Support Knowledge Base
- [362]http://support.caldera.com/caldera
+ [373]http://support.caldera.com/caldera
- [363]http://stage.caldera.com/ta/
+ [374]http://stage.caldera.com/ta/
Caldera (SCO) Technical Article Search Center
- [364]http://aplawrence.com/newtosco.html
+ [375]http://aplawrence.com/newtosco.html
New to SCO (Tony Lawrence)
- The same comments regarding terminal emulation and key mapping apply
- to SCO operating systems as to all other Unixes. C-Kermit is not a
- terminal emulator, and you can't use it to map F-keys, Arrow keys,
- etc. The way to do this is with xmodmap (xterm) or loadkeys (console).
- For a brief explanation, see [365]Section 3.0.5. For a fuller
- explanation, [366]ClICK HERE.
+ The same comments regarding terminal emulation and key mapping apply to
+ SCO operating systems as to all other Unixes. C-Kermit is not a
+ terminal emulator, and you can't use it to map F-keys, Arrow keys, etc.
+ The way to do this is with xmodmap (xterm) or loadkeys (console). For a
+ brief explanation, see [376]Section 3.0.5. For a fuller explanation,
+ [377]ClICK HERE.
- Also see general comments on PC-based Unixes in [367]Section 3.0.
+ Also see general comments on PC-based Unixes in [378]Section 3.0.
- 3.6.1. SCO XENIX
+3.6.1. SCO XENIX
- [ [368]Top ] [ [369]Contents ] [ [370]Section Contents ] [ [371]Next ]
+ [ [379]Top ] [ [380]Contents ] [ [381]Section Contents ] [ [382]Next ]
Old Xenix versions... Did you know: Xenix 3.0 is *older* than Xenix
2.0?
DTR to hang up a modem does not work. DTR goes down but does not come
up again. Workaround: Use SET MODEM HANGUP-METHOD MODEM-COMMAND.
Anybody who would like to fix this is welcome to take a look at
- tthang() in [372]ckutio.c. Also: modem signals can not be read in
+ tthang() in [383]ckutio.c. Also: modem signals can not be read in
Xenix, and the maximum serial speed is 38400.
There is all sorts of confusion among SCO versions, particularly when
- third- party communications boards and drivers are installed,
- regarding lockfile naming conventions, as well as basic functionality.
- As far as lockfiles go, all bets are off if you are using a
- third-party multiport board. At least you have the source code.
- Hopefully you also have a C compiler :-)
-
- Xenix 2.3.0 and later claim to support RTSFLOW and CTSFLOW, but this
- is not modern bidirectional hardware flow control; rather it
- implements the original RS-232 meanings of these signals for
- unidirectional half-duplex line access: If both RTSFLOW and CTSFLOW
- bits are set, Xenix asserts RTS when it wants to send data and waits
- for CTS assertion before it actually starts sending data (also,
- reportedly, even this is broken in Xenix 2.3.0 and 2.3.1).
- ________________________________________________________________________
-
- 3.6.2. SCO UNIX AND OSR5
-
- [ [373]Top ] [ [374]Contents ] [ [375]Section Contents ] [ [376]Next ]
- [ [377]Previous ]
+ 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 accesss: 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
+
+ [ [384]Top ] [ [385]Contents ] [ [386]Section Contents ] [ [387]Next ]
+ [ [388]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
+ 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,
signals. Thus "show comm" does not list modem signals, and C-Kermit
does not automatically pop back to its prompt when the modem hangs up
the connection (drops CD). The ioctl() call for this is simply not
- implmented, at least not in the standard drivers. OSR5.0.6 attempts to
+ implemented, at least not in the standard drivers. OSR5.0.6 attempts to
deal with modem signals but fails; however OSR5.0.6a appears to
function properly.
- Dialing is likely not to work well in SCO OpenServer 5.0.x because
- many of the serial-port APIs simply do not operate when using the
- standard drivers. For example, if DTR is dropped by the recommended
- method (setting speed to 0 for half a seconds, then restoring the
- speed), DTR and RTS go down but never come back up. When in doubt SET
- MODEM HANGUP-METHOD MODEM-COMMAND or SET DIAL HANGUP OFF.
-
- On the other hand, certain functions that might not (do not) work
- right or at all when using SCO drivers (e.g. high serial speeds,
- hardware flow control, and/or reading of modem signals) might work
- right when using third-party drivers. (Example: hardware flow control
- works, reportedly, only on uppercase device like tty1A -- not tty1a --
- and only when CLOCAL is clear when using the SCO sio driver, but there
- are no such restrictions in, e.g., [378]Digiboard drivers).
-
- One user reports that he can't transfer large files with C-Kermit
- under SCO OSR5.0.0 and 5.0.4 -- after the first 5K, everything falls
- apart. Same thing without Kermit -- e.g. with ftp over a PPP
- connection. Later, he said that replacing SCO's SIO driver with FAS,
- an alternative communications driver, made the problem go away:
-
- [379]ftp://ftp.fu-berlin.de/pub/unix/driver/fas
+ 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., [389]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:
+
+ [390]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.
+ 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:
+ 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
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.
+ you should disable it in /usr/lib/uucp/Devices; this will prevent getty
+ from doing things to it. You should also changes the device's file
+ modes in /etc/conf/node.d/sio by changing fields 5-7 for the desired
+ device(s); this determines how the devices are set if you relink the
+ kernel.
One SCO user of C-Kermit 5A(190) reported that only one copy of Kermit
can run at a time when a Stallion Technologies multiport boards are
- installed. Cause, cure, and present status unknown (see [380]Section
- 14 for more info regarding Stallion).
+ installed. Cause, cure, and present status unknown (see [391]Section 14
+ for more info regarding Stallion).
Prior to SCO OpenServer 5.0.4, the highest serial port speed supported
by SCO was 38400. However, in some SCO versions (e.g. OSR5) it is
possible to map rarely-used lower speeds (like 600 and 1800) to higher
ones like 57600 and 115200. To find out how, go to
- [381]http://www.sco.com/ and search for "115200". In OSR5.0.4, serial
- speeds up to 921600 are supported through the POSIX interface;
- C-Kermit 6.1.193 or later, when built for OSR5.0.4 using /bin/cc (NOT
- the UDK, which hides the high-speed definitions from CPP), supports
- these speeds, but you might be able to run this binary on earlier
- releases to get the high serial speeds, depending on various factors,
- described by Bela Lubkin of SCO:
+ [392]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
========================================================
SCO OpenServer Release 5.0.4 or later
SCO Internet FastStart Release 1.0.0 or later
- SCO supplements are at [382]ftp://ftp.sco.com/; the "rs40" series are
+ SCO supplements are at [393]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.
+ 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
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
+ 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
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:
+ 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
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.
- ________________________________________________________________________
+ 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
+3.6.3. Unixware
- [ [383]Top ] [ [384]Contents ] [ [385]Section Contents ] [ [386]Next ]
- [ [387]Previous ]
+ [ [394]Top ] [ [395]Contents ] [ [396]Section Contents ] [ [397]Next ]
+ [ [398]Previous ]
Unixware changed hands several times before landing at SCO, and so has
- its [388]own section in this document. (Briefly: AT&T UNIX Systems
+ its [399]own section in this document. (Briefly: AT&T UNIX Systems
Laboratories sold the rights to the UNIX name and to System V R4 (or
R5?) to Novell; later Novell spun its UNIX division off into a new
company called Univel, which eventually was bought by SCO, which later
was bought by Caldera, which later sort of semi-spun-off SCO...)
- ________________________________________________________________________
- 3.6.4. Open UNIX 8
+3.6.4. Open UNIX 8
- [ [389]Top ] [ [390]Contents ] [ [391]Section Contents ] [
- [392]Previous ]
+ [ [400]Top ] [ [401]Contents ] [ [402]Section Contents ] [
+ [403]Previous ]
- SCO was bought by Caldera in 2000 or 2001 and evolved Unixware 7.1
- into Caldera Open UNIX 8.00. It's just like Unixware 7.1 as far as
- Kermit is concerned (the Unixware 7.1 makefile target works for Open
- UNIX 8.00, and in fact a Unixware 7.1 Kermit binary built on Unixware
- 7.1 runs under OU8; a separate OU8 makefile target exists simply to
- generate an appropriate program startup herald). Open Unix is now
- defunct; subsequent releases are called UnixWare again (e.g. UnixWare
- 7.1.3).
- ________________________________________________________________________
+ SCO was bought by Caldera in 2000 or 2001 and evolved Unixware 7.1 into
+ Caldera Open UNIX 8.00. It's just like Unixware 7.1 as far as Kermit is
+ concerned (the Unixware 7.1 makefile target works for Open UNIX 8.00,
+ and in fact a Unixware 7.1 Kermit binary built on Unixware 7.1 runs
+ under OU8; a separate OU8 makefile target exists simply to generate an
+ appropriate program startup herald). Open Unix is now defunct;
+ subsequent releases are called UnixWare again (e.g. UnixWare 7.1.3).
- 3.7. C-KERMIT AND SOLARIS
+3.7. C-KERMIT AND SOLARIS
- [ [393]Top ] [ [394]Contents ] [ [395]Section Contents ] [ [396]Next ]
- [ [397]Previous ]
+ [ [404]Top ] [ [405]Contents ] [ [406]Section Contents ] [ [407]Next ]
+ [ [408]Previous ]
SECTION CONTENTS
-3.7.1. [398]Serial Port Configuration
-3.7.2. [399]Serial Port Problems
-3.7.3. [400]SunLink X.25
-3.7.4. [401]Sun Workstation Keyboard Mapping
-3.7.5. [402]Solaris 2.4 and Earlier
+3.7.1. [409]Serial Port Configuration
+3.7.2. [410]Serial Port Problems
+3.7.3. [411]SunLink X.25
+3.7.4. [412]Sun Workstation Keyboard Mapping
+3.7.5. [413]Solaris 2.4 and Earlier
REFERENCES
- * The [403]comp.unix.solaris newsgroup
- * [404]http://access1.sun.com/
- * [405]http://docs.sun.com/
- * [406]http://www.sunhelp.com/
- * [407]http://www.wins.uva.nl/pub/solaris/solaris2/
- * [408]http://www.wins.uva.nl/cgi-bin/sfaq.cgi
- * [409]ftp://ftp.wins.uva.nl/pub/solaris
- * [410]http://www.science.uva.nl/pub/solaris/solaris2.html
+ * The [414]comp.unix.solaris newsgroup
+ * [415]http://accesss1.sun.com/
+ * [416]http://docs.sun.com/
+ * [417]http://www.sunhelp.com/
+ * [418]http://www.wins.uva.nl/pub/solaris/solaris2/
+ * [419]http://www.wins.uva.nl/cgi-bin/sfaq.cgi
+ * [420]ftp://ftp.wins.uva.nl/pub/solaris
+ * [421]http://www.science.uva.nl/pub/solaris/solaris2.html
And about serial communications in particular, see "Celeste's Tutorial
on Solaris 2.x Modems and Terminals":
- [411]http://www.stokely.com/
+ [422]http://www.stokely.com/
In particular:
- [412]http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
+ [423]http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
For PC-based Solaris, also see general comments on PC-based Unixes in
- [413]Section 3.0. Don't expect Solaris or any other kind of Unix to
+ [424]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
+3.7.1. Serial Port Configuration
- [ [414]Top ] [ [415]Contents ] [ [416]Section Contents ] [
- [417]Section Contents ] [ [418]Next ]
+ [ [425]Top ] [ [426]Contents ] [ [427]Section Contents ] [ [428]Section
+ Contents ] [ [429]Next ]
- Your serial port can't be used -- or at least won't work right --
- until it is enabled in Solaris. For example, you get a message like
- "SERIAL: Operation would block" when attempting to dial. This probably
- indicates that the serial port has not been enabled for use with
- modems. You'll need to follow the instructions in your system setup or
- management manual, such as (e.g.) the Desktop SPARC Sun System &
- Network Manager's Guide, which should contain a section "Setting up
- Modem Software"; read it and follow the instructions. These might (or
- might not) include running a program called "eeprom", editing some
- system configuration file (such as, for example:
+ 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
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."
+ still possible that a zombie process has hold of the port EVEN IF there
+ is no lock file and the fuser command comes up empty. In that case, the
+ only way to resolve the problem is by rebooting."
If you can't establish communication through a serial port to a device
that is not asserting CD (Carrier Detect), try setting the environment
variable "ttya-ignore-cd" to "true" (replace "ttya" with the port
name).
- ________________________________________________________________________
- 3.7.2. Serial Port Problems
+3.7.2. Serial Port Problems
- [ [419]Top ] [ [420]Contents ] [ [421]Section Contents ] [ [422]Next ]
- [ [423]Previous ]
+ [ [430]Top ] [ [431]Contents ] [ [432]Section Contents ] [ [433]Next ]
+ [ [434]Previous ]
- Current advice from Sun is to always the /dev/cua/x devices for
- dialing out, rather than the /dev/term/x. Nevertheless, if you have
- trouble dialing out with one, try the other.
+ Current advice from Sun is to always the /dev/cua/x devices for dialing
+ out, rather than the /dev/term/x. Nevertheless, if you have trouble
+ dialing out with one, try the other.
Reportedly, if you start C-Kermit and "set line" to a port that has a
modem connected to it that is not turned on, and then "set flow
rts/cts", there might be some (unspecified) difficulties closing the
device because the CTS signal is not coming in from the modem.
- ________________________________________________________________________
- 3.7.3. SunLink X.25
+3.7.3. SunLink X.25
- [ [424]Top ] [ [425]Contents ] [ [426]Section Contents ] [ [427]Next ]
- [ [428]Previous ]
+ [ [435]Top ] [ [436]Contents ] [ [437]Section Contents ] [ [438]Next ]
+ [ [439]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.
+ 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:
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.
+ 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
+ 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).
+ 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.
- ________________________________________________________________________
+ 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
+3.7.4. Sun Workstation Keyboard Mapping
- [ [429]Top ] [ [430]Contents ] [ [431]Section Contents ] [ [432]Next ]
- [ [433]Previous ]
+ [ [440]Top ] [ [441]Contents ] [ [442]Section Contents ] [ [443]Next ]
+ [ [444]Previous ]
Hints for using a Sun workstation keyboard for VT emulation when
- accessing VMS, from the [434]comp.os.vms newsgroup:
+ accesssing VMS, from the [445]comp.os.vms newsgroup:
From: Jerry Leichter <leichter@smarts.com>
Newsgroups: comp.os.vms
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.
+ 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 '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).
+ Beware of one thing about xmodmap: Keymap changes are applied to the
+ *whole workstation*, not just to individual windows. There is, in
+ fact, no way I know of to apply them to individual windows. These
+ definitions *may* confuse some Unix programs (and/or some Unix
+ users).
If you're using Motif, you may also need to apply bindings at the
Motif level. If just using xmodmap doesn't work, I can try and dig
that stuff up for you.
- ________________________________________________________________________
- 3.7.5. Solaris PPP Connections
+3.7.5. Solaris PPP Connections
- [ [435]Top ] [ [436]Contents ] [ [437]Section Contents ] [ [438]Next ]
- [ [439]Previous ]
+ [ [446]Top ] [ [447]Contents ] [ [448]Section Contents ] [ [449]Next ]
+ [ [450]Previous ]
The following is a report from a user of C-Kermit 8.0 on Solaris 8 and
- 9, who had complained that while Kermit file transfers worked
- perfectly on direct (non-PPP) dialout connections, they failed
- miserably on PPP connections. We suggested that the PPP dialer
- probably was not setting the port and/or modem up in the same way that
- Kermit did:
+ 9, who had complained that while Kermit file transfers worked perfectly
+ on direct (non-PPP) dialout connections, they failed miserably on PPP
+ connections. We suggested that the PPP dialer probably was not setting
+ the port and/or modem up in the same way that Kermit did:
- I want to get back on this and tell you what the resolution was.
- You pointed me in the direction of flow control, which turned out
- to be the key.
+ I want to get back on this and tell you what the resolution was. You
+ pointed me in the direction of flow control, which turned out to be
+ the key.
Some discussion on the comp.unix.solaris newsgroup led to some
comments from Greg Andrews about the need to use the uucp driver to
talk to the modem (/dev/cua/a). I had to remind Greg that no matter
what the manpages for the zs and se drivers say, the ppp that Sun
- released with Solaris 8 7/01, and has in Solaris 9, is a setuid
- root program, and simply trying to make a pppd call from user space
+ released with Solaris 8 7/01, and has in Solaris 9, is a setuid root
+ program, and simply trying to make a pppd call from user space
specifying /dev/cua/a would fail because of permissions. Greg
finally put the question to the ppp people, who came back with
information that is not laid out anywhere in the docs available for
- Solaris users. Namely, put /dev/cua/a in one of the priviledged
+ Solaris users. Namely, put /dev/cua/a in one of the privileged
options files in the /etc/ppp directory. That, plus resetting the
OBP ttya-ignore-cd flag (this is Sun hardware) to false, seems to
have solved the problems.
/dev/term/a. Not so with pppd.
With this change in place, I seem to be able to upload and download
- through telnet run on Kermit with the maximum length packets. I
- note that the window allocation display does show STREAMING, using
+ through telnet run on Kermit with the maximum length packets. I note
+ that the window allocation display does show STREAMING, using
telnet. Running ssh on Kermit, I see the standard 1 of 30 windows
display, and note that there appears to be a buffer length limit
between 1000 and 2000 bytes. Run with 1000, and it's tick-tock,
solid as a rock. With 2000 I see timeout errors and RTS/CTS action
on the modem.
- Kermit's packet-length and other controls let you make adjustments
- like this to get around whatever obstacles might be thrown up -- in
- this case (running Kermit over ssh), the underling Solaris PTY driver.
- ________________________________________________________________________
+ Kermit's packet-length and other controls let you make adjustments like
+ this to get around whatever obstacles might be thrown up -- in this
+ case (running Kermit over ssh), the underling Solaris PTY driver.
- 3.7.6. Solaris 2.4 and Earlier
+3.7.6. Solaris 2.4 and Earlier
- [ [440]Top ] [ [441]Contents ] [ [442]Section Contents ] [
- [443]Previous ]
+ [ [451]Top ] [ [452]Contents ] [ [453]Section Contents ] [
+ [454]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
* 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
+ * 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.
+ 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).
+ 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:
+ soon as I dial the number and get a 'CONNECT' message from the modem, I
+ get:
BAD TRAP
kermit: Data fault
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.
+ 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:
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."
+ 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
+ * 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
+ * 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
kermit
sleep 2
surun pmadm -e -p zsmon -s a
- ________________________________________________________________________
- 3.8. C-KERMIT AND SUNOS
+3.8. C-KERMIT AND SUNOS
- [ [444]Top ] [ [445]Contents ] [ [446]Section Contents ] [ [447]Next ]
- [ [448]Previous ]
+ [ [455]Top ] [ [456]Contents ] [ [457]Section Contents ] [ [458]Next ]
+ [ [459]Previous ]
For additional information, see "Celeste's Tutorial on SunOS 4.1.3+
Modems and Terminals":
- [449]http://www.stokely.com/
+ [460]http://www.stokely.com/
For FAQs, etc, from Sun, see:
- * [450]http://access1.sun.com/
+ * [461]http://accesss1.sun.com/
For history of Sun models and SunOS versions, see (should be all the
same):
- * [451]http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
- * [452]ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
- * [453]ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref
+ * [462]http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
+ * [463]ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
+ * [464]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
+ 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
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.
+ 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.
+ 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
+ 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
+ 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
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:
+ 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.
+ 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
+3.9. C-KERMIT AND ULTRIX
- [ [454]Top ] [ [455]Contents ] [ [456]Section Contents ] [ [457]Next ]
- [ [458]Previous ]
+ [ [465]Top ] [ [466]Contents ] [ [467]Section Contents ] [ [468]Next ]
+ [ [469]Previous ]
- See also: The [459]comp.unix.ultrix and [460]comp.sys.dec newsgroups.
+ See also: The [470]comp.unix.ultrix and [471]comp.sys.dec newsgroups.
There is no hardware flow control in Ultrix. That's not a Kermit
deficiency, but an Ultrix one.
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:
+ 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
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.
+ 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,
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
+3.10. C-KERMIT AND UNIXWARE
- [ [461]Top ] [ [462]Contents ] [ [463]Section Contents ] [ [464]Next ]
- [ [465]Previous ]
+ [ [472]Top ] [ [473]Contents ] [ [474]Section Contents ] [ [475]Next ]
+ [ [476]Previous ]
See also:
* The Freebird Project (Unixware software repository)
- [466]http://www.freebird.org/
- * The UnixWare FAQ: [467]http://www.freebird.org/faq/
+ [477]http://www.freebird.org/
+ * The UnixWare FAQ: [478]http://www.freebird.org/faq/
* The following newsgroups:
- + [468]comp.unix.unixware.misc
- + [469]comp.unix.sco.misc.
+ + [479]comp.unix.unixware.misc
+ + [480]comp.unix.sco.misc.
- Also see general comments on PC-based Unixes in [470]Section 3.0. By
+ Also see general comments on PC-based Unixes in [481]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.
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
+ 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(?)
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).
+ 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
+ prevent us from having modem signals, accesss to the hardware flow
control APIs, select(), etc -- in short, all the other things we need
in communications software, especially when high speeds are used. Oh
the irony. And so C-Kermit must be shamelessly butchered -- as it has
been so many times before -- to allow us to have the needed features
from the POSIX and non-POSIX worlds. See the UNIXWAREPOSIX sections of
- [471]ckutio.c.
+ [482]ckutio.c.
After the butchery, we wind up with Unixware 2.x having full
modem-signal capability, but politically-correct Unixware 7.x lacking
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.
+ 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
+ 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".
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
+3.11. C-KERMIT AND APOLLO SR10
- [ [472]Top ] [ [473]Contents ] [ [474]Section Contents ] [ [475]Next ]
- [ [476]Previous ]
+ [ [483]Top ] [ [484]Contents ] [ [485]Section Contents ] [ [486]Next ]
+ [ [487]Previous ]
Reportedly, version 5A(190), when built under Apollo SR10 using "make
sr10-bsd", compiles, links, and executes OK, but leaves the terminal
kermit @*
stty sane
- ________________________________________________________________________
- 3.12. C-KERMIT AND TANDY XENIX 3.0
+3.12. C-KERMIT AND TANDY XENIX 3.0
- [ [477]Top ] [ [478]Contents ] [ [479]Section Contents ] [ [480]Next ]
- [ [481]Previous ]
+ [ [488]Top ] [ [489]Contents ] [ [490]Section Contents ] [ [491]Next ]
+ [ [492]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.
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)
+3.13. C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
- [ [482]Top ] [ [483]Contents ] [ [484]Section Contents ] [ [485]Next ]
- [ [486]Previous ]
+ [ [493]Top ] [ [494]Contents ] [ [495]Section Contents ] [ [496]Next ]
+ [ [497]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.
+ 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:
+ 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:
"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.
+ 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.
+ 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
+ those who use Kermit or other terminal emulators to accesss 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.
+ 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.
+ #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
+ Reportedly 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
+3.14. C-KERMIT AND SGI IRIX
- [ [487]Top ] [ [488]Contents ] [ [489]Section Contents ] [ [490]Next ]
- [ [491]Previous ]
+ [ [498]Top ] [ [499]Contents ] [ [500]Section Contents ] [ [501]Next ]
+ [ [502]Previous ]
See also:
- * The [492]comp.sys.sgi.misc and [493]comp.sys.sgi.admin newsgroups.
- [494]The SGI website
+ * The [503]comp.sys.sgi.misc and [504]comp.sys.sgi.admin newsgroups.
+ [505]The SGI website
* The SGI FAQ:
- + [495]http://www-viz.tamu.edu/~sgi-faq/
- + [496]ftp://viz.tamu.edu/pub/sgi/faq/
+ + [506]http://www-viz.tamu.edu/~sgi-faq/
+ + [507]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
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:
+ 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
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.
+ 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".
+ 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
+ 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
+ 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.
+ 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.
+ release. Similarly, IRIX 5.2 has several problems with serial i/o, flow
+ control, etc. Again, patch or upgrade.
Reportedly on machines with IRIX 4.0, Kermit cannot be suspended by
- typing the suspend ("swtch") character if it was started from csh,
- even though other programs can be suspended this way, and even though
- the Z and SUSPEND commands still work correctly. This is evidently
- because IRIX's csh does not deliver the SIGTSTP signal to Kermit. The
- reason other programs can be suspended in the same environment is
- probably that they do not trap SIGTSTP themselves, so the shell is
- doing the suspending rather than the application.
-
- Also see notes about IRIX 3.x in the [497]C-Kermit for Unix
+ 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 [508]C-Kermit for Unix
Installation Instructions.
If you have problems making TCP/IP connections in versions of IRIX
built with GCC 2.95.2, see the bugs section of:
- [498]http://freeware.sgi.com/Installable/gcc-2.95.2.html.
+ [509]http://freeware.sgi.com/Installable/gcc-2.95.2.html.
Reportedly, if you allow gcc to compile C-Kermit on Irix you should be
aware that there might be problems with some of the network code. The
specifics are at
- [499]http://freeware.sgi.com/Installable/gcc-2.95.2.html; scroll down
+ [510]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
+3.15. C-KERMIT AND THE BEBOX
- [ [500]Top ] [ [501]Contents ] [ [502]Section Contents ] [ [503]Next ]
- [ [504]Previous ]
+ [ [511]Top ] [ [512]Contents ] [ [513]Section Contents ] [ [514]Next ]
+ [ [515]Previous ]
- See also: The [505]comp.sys.be newsgroup.
+ See also: The [516]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:
+ 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)
* 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 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
+3.16. C-KERMIT AND DG/UX
- [ [506]Top ] [ [507]Contents ] [ [508]Section Contents ] [ [509]Next ]
- [ [510]Previous ]
+ [ [517]Top ] [ [518]Contents ] [ [519]Section Contents ] [ [520]Next ]
+ [ [521]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
+3.17. C-KERMIT AND SEQUENT DYNIX
- [ [511]Top ] [ [512]Contents ] [ [513]Section Contents ] [ [514]Next ]
- [ [515]Previous ]
+ [ [522]Top ] [ [523]Contents ] [ [524]Section Contents ] [ [525]Next ]
+ [ [526]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.
- ________________________________________________________________________
+ 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
+3.18. C-KERMIT AND FREEBSD, OPENBSD, and NETBSD
- [ [516]Top ] [ [517]Contents ] [ [518]Section Contents ] [ [519]Next ]
- [ [520]Previous ]
+ [ [527]Top ] [ [528]Contents ] [ [529]Section Contents ] [ [530]Next ]
+ [ [531]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.
+ prompt if the modem drops carrier. This needs to be checked out & fixed
+ if possible.
(All the above seems to work properly in C-Kermit 7.0 and later.)
- ________________________________________________________________________
- 3.19. C-KERMIT AND MAC OS X (Rhapsody, Darwin, Jaguar, Panther)
+3.19. C-KERMIT AND MAC OS X
- [ [521]Top ] [ [522]Contents ] [ [523]Section Contents ] [ [524]Next ]
- [ [525]Previous ]
+ [ [532]Top ] [ [533]Contents ] [ [534]Section Contents ] [ [535]Next ]
+ [ [536]Previous ]
Mac OS X is Apple's 4.4BSD Unix variety, closely related to FreeBSD,
but different. "uname -a" is singularly uninformative, as in Linux,
- giving only the Darwin kernel version number. As far as I can tell,
- there is no way to find out the Mac OS X version number, such as 10.3
- (in Linux you can find the distribution version in a
- distribution-dependent file). Here are some points to be aware of:
-
- * The biggest gotcha for Kermit users is that Mac OS X does not
- support serial ports and, as far as I can tell, doesn't support
- its built-in modem either, for anything other than making Internet
+ giving only the Darwin kernel version number. The way to find out the
+ actual Mac OS X version is with
+
+ /usr/bin/sw_vers -productName
+ /usr/bin/sw_vers -productVersion
+
+ or:
+
+ fgrep -A 1 'ProductVersion'
+ /System/Library/CoreServices/SystemVersion.plist
+
+ Here are some points to be aware of:
+
+ * A big gotcha for Kermit users is that Mac OS X does not support
+ serial ports and, as far as I can tell, doesn't support its
+ built-in modem either, for anything other than making Internet
connections. Macintoshes capable of running Mac OS X, such as the
- G5, some without serial ports and without any APIs to support
- them, and also without the UUCP family of programs (including cu),
- nor any standard for serial-port lockfile directory.
- * At least early versions of Mac OS X came without Curses, Termlib,
- or Terminfo libraries. Later versions seem to have ncurses. Kermit
- uses curses for its file-transfer display. See elsewhere about
- curses-vs-ncurses confusion.
- * In the HFS+ file system, filenames are case-folded. Thus
- "makefile" and "Makefile" are the same file. The UFS file system
- is, like normal Unix, case-sensitive.
- * Files that are composed of a resource fork and a data fork... I
- doubt that C-Kermit does anything useful with them. There is no
- code in C-Kermit for traditional two-forked Macintosh files, but
- it could be added if there is any demand.
+ G5 and later, come without serial ports and without any APIs to
+ support them, and also without the UUCP family of programs
+ (including cu), nor any standard for serial-port lockfile
+ directory.
+ * Early versions of Mac OS X came without Curses, Termlib, or
+ Terminfo libraries. Later versions seem to have ncurses (it would
+ seem that Mac OS X 10.3.9 was the first mature and complete version
+ of Mac OS X). Kermit uses curses for its file-transfer display. See
+ elsewhere about curses-vs-ncurses confusion.
+ * In the HFS+ file system, filenames are case-folded. Thus "makefile"
+ and "Makefile" are the same file. So, for example, suppose you are
+ sending two distinct files, Foo and FOO, from (say) Linux to Mac OS
+ X. This will produce a file collision that will be handled
+ according to Mac OS X C-Kermit's FILE COLLISION setting, which by
+ default is BACKUP, so the Mac will wind up with files called FOO
+ and Foo.~1~.
+ * HSF+ files that are composed of a resource fork and a data fork...
+ I doubt that C-Kermit does anything useful with them. There is no
+ code in C-Kermit for traditional two-forked Macintosh files, but it
+ could be added if there is any demand (code for this existed in
+ [537]Mac Kermit, the old pre-Mac-OS-X Macintosh version of
+ C-Kermit).
* In case you want to transfer a traditional Macintosh text file (or
- data fork of a file that is plain text), you can use these
- C-Kermit commands:
+ data fork of a file that is plain text), you can use these C-Kermit
+ commands:
set file eol cr
set file character-set apple-quickdraw
* File or pathnames that include spaces must be enclosed in either
doublequotes or curly braces in C-Kermit commands.
- * Mac OS X has its own package format for applications, called
- "fink". Various fink packages for C-Kermit are floating around
- that are not standard releases. For example, there's a C-Kermit
- 8.0.201 package in which C-Kermit was modifed (at least) to use a
- UUCP lockfile directory that does not exist on vanilla Mac OS X
- systems.
+ * Mac OS X can use a third-party package manager called "fink".
+ Various fink packages for C-Kermit are floating around that are not
+ standard releases. For example, there's a C-Kermit 8.0.201 package
+ in which C-Kermit was modifed (at least) to use a UUCP lockfile
+ directory that does not exist on vanilla Mac OS X systems.
- Mac OS X and Serial Ports
+Mac OS X and Serial Ports
Apple is in the forefront of companies that believe serial ports have
no use in the modern world and so has simply eliminated all traces of
them from its machines and OS. But of course serial ports are still
needed to connect not only to external modems, but also to the control
ports of hubs, routers, terminal servers, PBXs, and similar devices,
- not to mention barcode readers, POS systems and components, automated
- factory-floor equipment, and scientific, medical, and lab equipment
- (to name a few). Among workers in these areas, there is a need to add
- serial ports back onto this platform, which is being filled by
- third-party products such as the [526]Keyspan USB Serial Adapter. To
- use the Keyspan device, you must install the accompanying device
- drivers, which wind up giving you serial ports with names like
- /dev/cu.USA19H3b1P1.1.
-
- To configure your Mac OS X system to allow C-Kermit to use these (or
- any other) serial devices:
-
- 1. su
+ not to mention barcode readers, POS systems and components, speaking
+ devices, hand calculators such as the HP48, automated factory-floor
+ equipment, and scientific, medical, and lab equipment (to name a few).
+ Among workers in these areas, there is a need to add serial ports back
+ onto this platform, which is being filled by third-party products such
+ as the [538]Keyspan High Speed USB Serial Adapter USA-19HS, which has a
+ DB-9 male connector. To use the Keyspan device, you must install the
+ accompanying device drivers, which winds up giving you serial ports
+ with names like /dev/cu.USA19H3b1P1.1, /dev/cu.KeySerial1,
+ /dev/tty.KeySerial1.
+
+ C-Kermit 9.0 works "out of the box" with third-party serial ports on
+ Mac OS X, because it is built by default ("make macosx") without the
+ "UUCP lockfile" feature. If you have C-Kermit 9.0 on a personal
+ Macintosh, you can skip the next section.
+
+Mac OS X Serial Ports with C-Kermit 8.0 and earlier
+
+ In earlier versions of C-Kermit, you'll need to either build a special
+ -DNOUUCP version, or deal with the UUCP port contention sytem in
+ [539]all its glory (this is usually an exercise in futility because any
+ other applications on your Mac that use the serial port will not
+ necessarily follow the same conventions):
+
+ 1. su (or sudo -s)
chgrp xxxx /var/spool/lock
chmod g+w /var/spool/lock
chgrp xxxx /dev/cu.*
(where xxxx is the name of the group for users to whom serial-port
- access is to be granted). Use "admin" or other existing group, or
+ accesss is to be granted). Use "admin" or other existing group, or
create a new group if desired. NB:
In the absence of official guidance from Apple or anyone else, we
choose /var/spool/lock as the lockfile directory because this
directory (a) already exists on vanilla Mac OS X installations, and
- (b) it is the directory used for serial-port lockfiles on many
- other platforms.
- 2. Put all users who need access to the serial port in the same
+ (b) it is the directory used for serial-port lockfiles on many other
+ platforms.
+ 2. Put all users who need accesss to the serial port in the same
group.
3. Make sure the serial device files that are to be used by C-Kermit
have group read-write permission and (if you care) lack world
read-write permission, e.g.:
- chmod g+rw,o-rw /dev/cu.*
- If you do the above, then there's no need to become root to use
- Kermit, or to make Kermit suid or sgid. Just do this:
+ chmod g+rw,o-rw /dev/cu.*
+
+ If you do the above, then there's no need to become root to use Kermit,
+ or to make Kermit suid or sgid. Just do this:
chmod 775 wermit
-mv wermit /usr/local/bin/kermit
-
- (or whatever spot is more appropriate). For greater detail about
- installation (man page, etc), [527]CLICK HERE.
-
- Back when Macs had serial ports, they were not RS-232 (the standard
- for connecting computers with nearby modems) but rather RS-422 or -423
- (a standard for connecting serial devices over longer distances).
- Macintosh serial ports do not support modems well because they do not
- have enough wires (or more properly in the case RS-422/423, wire
- pairs) to convey a useful subset of modem signals. The Keyspan USB
- adapter gives you two Mini-Din8 RS-422 ports, that are no better (or
- worse) for communicating with modems or serial devices than a real Mac
- Din-8 port was. In essense, you get Data In, Data Out, and two modem
- signals. It looks to me as if the signals chosen by Keyspan are RTS
- and CTS. This gives you hardware flow control, but at the expense of
- Carrier Detect. Thus to use C-Kermit with a Keyspan USB serial port,
- you must tell C-Kermit to:
+mv wermit /usr/local/kermit
+
+ (or whatever spot is more appropriate, e.g. /usr/bin/). For greater
+ detail about installation, [540]CLICK HERE.
+
+ Alternatively, to build a pre-9.0 version of C-Kermit without UUCP
+ lockfile support, set the NOUUCP flag; e.g. (for Mac OS 10.4):
+
+ make macosx10.4 KFLAGS=-DNOUUCP
+
+ This circumvents the SET PORT failure "?Access to lockfile directory
+ denied". But it also sacrifices Kermit's ability to ensure that only
+ one copy of Kermit can have the device open at a time, since Mac OS X
+ is the same as all other varieties of Unix in that exclusive accesss to
+ serial ports is not enforced in any way. But if it's for your own
+ desktop machine that nobody else uses, a -DNOUUCP version might be
+ adequate and preferable to the alternatives.
+
+ To build C-Kermit 9.0 with UUCP support, do:
+
+ make macosx KFLAGS=-UNOUUCP
+
+ (note: "-U", not "-D).
+
+RS-232 versus RS-422
+
+ Meanwhile, back when Macs had serial ports, they were not RS-232 (the
+ standard for connecting computers with nearby modems) but rather RS-422
+ or -423 (a standard for connecting serial devices over longer
+ distances). Macintosh serial ports do not support modems well because
+ they do not have enough wires (or more properly in the case RS-422/423,
+ wire pairs) to convey a useful subset of modem signals.
+
+ Keyspan also sells a [541]USB Twin Serial Adapter that gives you two
+ Mini-Din8 RS-422 ports, that are no better (or worse) for communicating
+ with modems or serial devices than a real Mac Din-8 port was. In
+ essence, you get Data In, Data Out, and two modem signals. It looks to
+ me as if the signals chosen by Keyspan are RTS and CTS. This gives you
+ hardware flow control, but at the expense of Carrier Detect. Thus to
+ use C-Kermit with a Keyspan USB serial port, you must tell C-Kermit to:
set modem type none ; (don't expect a modem)
set carrier-watch off ; (ignore carrier signal)
set port /dev/cu.USA19H3b1P1.1 ; (open the port)
set flow rts/cts ; (this is the default)
set speed 57600 ; (or whatever)
-connect ; (or whatever)
+connect ; (or DIAL or whatever)
Use Ctrl-\C in the normal manner to escape back to the C-Kermit>
prompt. Kermit can't pop back to its prompt automatically when Carrier
- drops because there is no Carrier signal.
+ drops because there is no Carrier signal in the physical interface.
- Instructions for the built-in modem remain to be written.
+ Here's a typical sequence for connecting to Cisco devices (using a
+ mixture of command-line options and interactive commands at the
+ prompt):
- Links:
- * [528]Unix tips for Mac OS X (Jerry Stratton)
- ________________________________________________________________________
+$ ckermit -l /dev/cu.USA19H3b1P1.1 -b 9600
+C-Kermit> set carrier-watch off
+C-Kermit> connect
- 3.20. C-KERMIT AND COHERENT
+ Instructions for the built-in modem (if any) remain to be written due
+ to lack of knowledge. If you can contribute instructions, hints, or
+ tips, please [542]send them in.
- [ [529]Top ] [ [530]Contents ] [ [531]Section Contents ] [
- [532]Previous ]
+3.20. C-KERMIT AND COHERENT
+
+ [ [543]Top ] [ [544]Contents ] [ [545]Section Contents ] [
+ [546]Previous ]
Also see:
- [533]http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg00
- 000.html
+ [547]http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg000
+ 00.html
Mark Williams COHERENT was perhaps the first commercial Unix-based
operating system for PCs, first appearing about 1983 or -84 for the
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
+4. GENERAL UNIX-SPECIFIC HINTS, LIMITATIONS, AND BUGS
- [ [534]Top ] [ [535]Contents ] [ [536]Next ] [ [537]Previous ]
+ [ [548]Top ] [ [549]Contents ] [ [550]Next ] [ [551]Previous ]
- 4.1. Modem Signals
+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
+ 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,
to be totally different on each Unix platform, since there is no
standard for this.
- 4.2. NFS Troubles
+4.2. NFS Troubles
Beginning with C-Kermit 6.0, the default C-Kermit prompt includes your
current (working) directory; for example:
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:
+ 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 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
+4.3. C-Kermit as Login Shell
You might have reason to make C-Kermit the login shell for a specific
user, by entering the pathname of Kermit (possibly with command-line
switches, such as -x to put it in server mode) into the shell field of
the /etc/passwd file. This works pretty well. In some cases, for
"ultimate security", you might want to use a version built with
- -DNOPUSH (see the [538]Configurations Options document for this, but
+ -DNOPUSH (see the [552]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
+4.4. C-Kermit versus screen and splitvt
- C-Kermit file transfers will probably not work if attemped through the
+ C-Kermit file transfers will probably not work if attempted 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.
+ 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
If it works, it will be slow.
- 4.5. C-Kermit versus DOS Emulators
+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.
+ 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
+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
+ 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):
+ 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
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...).
+ timestamp, rather than the HTTP "Last Modified" time (this can be fixed
+ by including utime.h, e.g. in SunOS and Tru64...).
- 4.8. Pseudoterminals
+4.8. Pseudoterminals
- The SSH and PTY commands work by assigning a pseudoterminal and
- reading and writing from it. Performance varies according to the
- specific platform ranging from very fast to very flow.
+ The SSH and PTY commands work by assigning a pseudoterminal and reading
+ and writing from it. Performance varies according to the specific
+ platform ranging from very fast to very flow.
- SSH and PTY commands can fail if (a) all pseudoterminals are in use;
- or (b) you do not have read/write access to the pseudoterminal that
- was assigned. An example of (b) was reported with the Zipslack
- Slackware Linux distribution, in which the pseudoterminals were
- created with crw-r--r-- permission, instead of crw-rw-rw-.
+ SSH and PTY commands can fail if (a) all pseudoterminals are in use; or
+ (b) you do not have read/write accesss to the pseudoterminal that was
+ assigned. An example of (b) was reported with the Zipslack Slackware
+ Linux distribution, in which the pseudoterminals were created with
+ crw-r--r-- permission, instead of crw-rw-rw-.
- 4.9. Miscellaneous
+4.9. Miscellaneous
* Reportedly, the Unix C-Kermit server, under some conditions, on
- certain particular systems, fails to log out its login session
- upon receipt of a BYE command. Before relying on the BYE command
+ 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
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
+5. INITIALIZATION AND COMMAND FILES
- [ [539]Top ] [ [540]Contents ] [ [541]Next ] [ [542]Previous ]
+ [ [553]Top ] [ [554]Contents ] [ [555]Next ] [ [556]Previous ]
C-Kermit's initialization file for Unix is .kermrc (lowercase, starts
with period) in your home directory, unless Kermit was built with the
- system-wide initialization-file option (see the [543]C-Kermit for Unix
+ system-wide initialization-file option (see the [557]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:
+ you log in. If C-Kermit can't find your initialization file, check your
+ HOME variable:
echo $HOME (at the Unix prompt)
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:
+ 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):
+ 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.
- ________________________________________________________________________
+ 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
+6. COMMUNICATION SPEED SELECTION
- [ [544]Top ] [ [545]Contents ] [ [546]Next ] [ [547]Previous ]
+ [ [558]Top ] [ [559]Contents ] [ [560]Next ] [ [561]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
+ 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:
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.
+ 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.
+ 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
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:
+ 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.
+ 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.
+ 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
+ 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.
+ might be). Such modems need to be engaged at a lower speed (say 2400 or
+ 9600 or even 115200 -- any speed below their autobaud threshold) and
+ then must be given a modem-specific command (which can be found in the
+ modem manual) to change their interface speed to the desired higher
+ speed, and then the software must also be told to change to the new,
+ higher speed.
- For additional information, read [548]Section 9.5 of the Installation
- Instructions, plus any platform-specific notes in [549]Section 3
- above.
- ________________________________________________________________________
+ For additional information, read [562]Section 9.5 of the Installation
+ Instructions, plus any platform-specific notes in [563]Section 3 above.
- 7. COMMUNICATIONS AND DIALING
+7. COMMUNICATIONS AND DIALING
- [ [550]Top ] [ [551]Contents ] [ [552]Next ] [ [553]Previous ]
+ [ [564]Top ] [ [565]Contents ] [ [566]Next ] [ [567]Previous ]
- 7.1. Serial Ports and Modems
+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.
+ 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
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.
+ 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.
+ 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:
+ 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").
If you are having trouble dialing:
- 1. Make sure the dialout line is configured correctly. More about
- this below.
+ 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
+ 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.
+ the modem you are actually using -- pay particular attention to SET
+ DIAL SPEED-MATCHING.
5. If MODEM HANGUP-METHOD is set to RS232-SIGNAL, change it to
MODEM-COMMAND. Or vice-versa.
6. Try SET DIAL HANGUP OFF before the DIAL command. Also, SET DIAL
- DISPLAY ON to watch what's happening. See [554]Section 8 of the
- [555]Installation Instructions.
- 7. Read pages 50-67 of [556]Using C-Kermit.
+ DISPLAY ON to watch what's happening. See [568]Section 8 of the
+ [569]Installation Instructions.
+ 7. Read pages 50-67 of [570]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).
+ 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
(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).
+ 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 accesss 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.
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
+ 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.
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.)
+ 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
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
+ 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.)
+ 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
+ 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.
+ computer -- it should be a straight-through [571]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).
+ 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,
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.
+ FLOW KEEP command will not necessarily know how to restore *all* of the
+ device's original flow-control settings.
- 7.2. Network Connections
+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
+ does not work when the Unix system is accesssed 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
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
+8. HARDWARE FLOW CONTROL
- [ [557]Top ] [ [558]Contents ] [ [559]Next ] [ [560]Previous ]
+ [ [572]Top ] [ [573]Contents ] [ [574]Next ] [ [575]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:
+ 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
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",
+ 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.
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.
+ contain -DTERMIOX or -DSTERMIOX (the latter to select <sys/termiox.h>),
+ C-Kermit will have "set flow rts/cts" and possibly other hardware
+ flow-control related commands. BUT... That does not necessarily mean
+ that they will work. In some cases, the underlying functions are simply
+ not coded into the operating system.
WARNING: When hardware flow control is available, and you enable in
Kermit on a device that is not receiving the CTS signal, Kermit can
hang waiting for CTS to come up. This is most easily seen when the
local serial port has nothing plugged in to it, or is connected to an
external modem that is powered off.
- ________________________________________________________________________
- 9. TERMINAL CONNECTION AND KEY MAPPING
+9. TERMINAL CONNECTION AND KEY MAPPING
- [ [561]Top ] [ [562]Contents ] [ [563]Next ] [ [564]Previous ]
+ [ [576]Top ] [ [577]Contents ] [ [578]Next ] [ [579]Previous ]
- C-Kermit is not a terminal emulator. Refer to page 147 of [565]Using
- C-Kermit, 2nd Edition: "Most versions of C-Kermit -- Unix, VMS,
- AOS/VS, VOS, etc -- provide terminal connection without emulation.
- These versions act as a 'semitransparent pipe' between the remote
- computer and your terminal, terminal emulator, console driver, or
- window, which in turn emulates (or is) a specific kind of terminal."
- The environment in which you run C-Kermit is up to you.
+ C-Kermit is not a terminal emulator. Refer to page 147 of [580]Using
+ C-Kermit, 2nd Edition: "Most versions of C-Kermit -- Unix, VMS, AOS/VS,
+ VOS, etc -- provide terminal connection without emulation. These
+ versions act as a 'semitransparent pipe' between the remote computer
+ and your terminal, terminal emulator, console driver, or window, which
+ in turn emulates (or is) a specific kind of terminal." The environment
+ in which you run C-Kermit is up to you.
If you are an X Windows user, you should be aware of an alternative to
xterm that supports VT220 emulation, from Thomas E. Dickey:
- [566]http://dickey.his.com/xterm/xterm.html
+ [581]http://dickey.his.com/xterm/xterm.html
Unix C-Kermit's SET KEY command currently can not be used with keys
that generate "wide" scan codes or multibyte sequences, such as
- workstation function or arrow keys, because Unix C-Kermit does not
- have direct access to the keyboard.
+ workstation function or arrow keys, because Unix C-Kermit does not have
+ direct accesss 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
+ 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
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).
- ________________________________________________________________________
+ keycodes are compatible for different keyboard types (e.g. Sun vs HP vs
+ PC, etc).
+
+10. FILE TRANSFER
- 10. FILE TRANSFER
+ [ [582]Top ] [ [583]Contents ] [ [584]Next ] [ [585]Previous ]
- [ [567]Top ] [ [568]Contents ] [ [569]Next ] [ [570]Previous ]
+ On most platforms, C-Kermit can not handle files longer than 2^31 or
+ 2^32 bytes long, because it uses the traditional file i/o APIs that use
+ 32-bit words to represent the file size. To accommodate longer files,
+ we would have to switch to a new and different API. Unfortunately, each
+ platform has a different one, a nightmare to handle in portable code.
+ The C-Kermit file code was written in the days long before files longer
+ than 2GB were supported or even contemplated in the operating systems
+ where C-Kermit ran.
If uploads (or downloads) fail immediately, give the CAUTIOUS command
to Kermit and try again. If they still fail, then try SET PREFIXING
ROBUST.
If reception (particularly of large files and/or binary files) begins
- successfully but then fail constently after a certain amount of bytes
+ successfully but then fail consistently after a certain amount of bytes
have been sent, check:
* Your ulimit ("ulimit -a")
.")
* Your personal disk quota (platform- and site-dependent)
* The maximum file size on the receiver's file system (e.g. 2GB in
- old verions the Linux VFS file system, and/or in applications that
+ old versions the Linux VFS file system, and/or in applications that
have not been recoded to use new "large file" APIs).
* If it's an NFS-mounted disk (if so, try uploading to a local disk)
* Is there an "idle limit" on the receiving end?
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.
+ 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:
+ 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
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.
+ 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
+ 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
+ (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
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.
+ -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
+ 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
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
+11. EXTERNAL FILE TRANSFER PROTOCOLS
- [ [571]Top ] [ [572]Contents ] [ [573]Next ] [ [574]Previous ]
+ [ [586]Top ] [ [587]Contents ] [ [588]Next ] [ [589]Previous ]
SECTION CONTENTS
- 11.1. [575]C-Kermit as an External Protocol
- 11.2. [576]Invoking External Protocols from C-Kermit
+ 11.1. [590]C-Kermit as an External Protocol
+ 11.2. [591]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.
+ 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
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.
+ 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
+11.1. C-KERMIT AS AN EXTERNAL PROTOCOL
- [ [577]Top ] [ [578]Contents ] [ [579]Section Contents ] [ [580]Next ]
+ [ [592]Top ] [ [593]Contents ] [ [594]Section Contents ] [ [595]Next ]
- (This section deleted; see [581]Using C-Kermit, 2nd Ed, Chapter 14.)
+ (This section deleted; see [596]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
+ 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
it:
- Send Receive
+ 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
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
+ Seyon does not give you a way to accesss 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
r - receive
s - send
- 11.2. INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
+11.2. INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
- [ [582]Top ] [ [583]Contents ] [ [584]Section Contents ] [
- [585]Previous ]
+ [ [597]Top ] [ [598]Contents ] [ [599]Section Contents ] [
+ [600]Previous ]
(This section is obsolete, but not totally useless. See Chapter 14
- of [586]Using C-Kermit, 2nd Edition).
+ of [601]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
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).
+ 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
+12. SECURITY
- [ [587]Top ] [ [588]Contents ] [ [589]Next ] [ [590]Previous ]
+ [ [602]Top ] [ [603]Contents ] [ [604]Next ] [ [605]Previous ]
As of version 7.0, C-Kermit supports a wide range of security options
for authentication and encryption: Kerberos 4, Kerberos 5 / GSSAPI,
- SSL/TLS, and SRP. See the separate [591]security document for details.
- ________________________________________________________________________
+ SSL/TLS, and SRP. See the separate [606]security document for details.
- 13. MISCELLANEOUS USER REPORTS
+13. MISCELLANEOUS USER REPORTS
- [ [592]Top ] [ [593]Contents ] [ [594]Next ] [ [595]Previous ]
+ [ [607]Top ] [ [608]Contents ] [ [609]Next ] [ [610]Previous ]
Date: Thu, 12 Mar 92 1:59:25 MEZ
From: Walter Mecky <walter@rent-a-guru.de>
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>
------------------------------
- (Note: the following problem also occurs on SGI and probably many
- other Unix systems):
+ (Note: the following problem also occurs on SGI and probably many other
+ Unix systems):
From: James Spath <spath@jhunix.hcf.jhu.edu>
To: Info-Kermit-Request@cunixf.cc.columbia.edu
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
+ VR3 running on our system. In order to allow dialout accesss 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
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.
+ 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 */
#ifdef DEBUG
fprintf(stderr, "LOCKFILE? %s?\n", lockdev);
#endif
- if (access(lockdev, 00) == 0) {
+ if (accesss(lockdev, 00) == 0) {
allow=TTY_LOCK;
break;
}
}
exit (0);
}
- ________________________________________________________________________
- 14. THIRD-PARTY DRIVERS
+14. THIRD-PARTY DRIVERS
- [ [596]Top ] [ [597]Contents ] [ [598]Next ] [ [599]Previous ]
+ [ [611]Top ] [ [612]Contents ] [ [613]Next ] [ [614]Previous ]
Unix versions, especially those for PCs (SCO, Unixware, etc) might be
augmented by third-party communication-board drivers from Digiboard,
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
+ 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."
+ the rest are supported. This will, as I mentioned earlier, be fixed
+ in the next release of our ATA software."
- World Wide Escalation Support, Stallion Technologies, Toowong
- QLD, [600]support@stallion.oz.au.
+ QLD, [615]support@stallion.oz.au.
Later (December 1997, from the same source):
* We have now released a new version of the ATA software, version
5.4.0. This version fixes the problem with the states of the DSR
- and RI signals and how they were being reported by the driver.
- This is the problem that you reported in October. The DSR signal
- is reported correctly on those cards that support the DSR signal,
- such as the early revision of the EasyIO card and the
- EasyConnection 8D4 panel, and as always asserted on those cards
- that do not support the DSR signal in the hardware. The new driver
- is available from our Web site, [601]www.stallion.com, in the
- /drivers/ata5/UnixWare directory.
-
- [ [602]Top ] [ [603]Contents ] [ [604]C-Kermit Home ] [ [605]C-Kermit
- 8.0 Overview ] [ [606]Kermit Home ]
- _________________________________________________________________
-
- C-Kermit 8.0 Unix Hints and Tips / [607]The Kermit Project /
- [608]Columbia University / [609]kermit@columbia.edu
+ 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, [616]www.stallion.com, in the /drivers/ata5/UnixWare
+ directory.
+
+ [ [617]Top ] [ [618]Contents ] [ [619]C-Kermit Home ] [ [620]C-Kermit
+ 8.0 Overview ] [ [621]Kermit Home ]
+ __________________________________________________________________
+
+ C-Kermit 8.0 Unix Hints and Tips / [622]The Kermit Project /
+ [623]Columbia University / [624]kermit@columbia.edu
References
- 1. http://www.columbia.edu/kermit/
- 2. http://www.columbia.edu/
- 3. http://www.columbia.edu/kermit/ckubwr.html
- 4. mailto:kermit-support@columbia.edu
+ 1. http://www.columbia.edu/
+ 2. mailto:kermit@columbia.edu
+ 3. http://www.columbia.edu/kermit/index.html
+ 4. http://www.columbia.edu/kermit/k95.html
5. http://www.columbia.edu/kermit/ckermit.html
- 6. http://www.columbia.edu/kermit/ckuins.html
- 7. http://www.columbia.edu/kermit/ckututor.html
- 8. http://www.columbia.edu/kermit/ckubwr.html#x1
- 9. http://www.columbia.edu/kermit/ckubwr.html#x2
- 10. http://www.columbia.edu/kermit/ckubwr.html#x3
- 11. http://www.columbia.edu/kermit/ckubwr.html#x4
- 12. http://www.columbia.edu/kermit/ckubwr.html#x5
- 13. http://www.columbia.edu/kermit/ckubwr.html#x6
- 14. http://www.columbia.edu/kermit/ckubwr.html#x7
- 15. http://www.columbia.edu/kermit/ckubwr.html#x8
- 16. http://www.columbia.edu/kermit/ckubwr.html#x9
- 17. http://www.columbia.edu/kermit/ckubwr.html#x10
- 18. http://www.columbia.edu/kermit/ckubwr.html#x11
- 19. http://www.columbia.edu/kermit/ckubwr.html#x12
- 20. http://www.columbia.edu/kermit/ckubwr.html#x13
- 21. http://www.columbia.edu/kermit/ckubwr.html#x14
- 22. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 23. http://www.columbia.edu/kermit/ckubwr.html#x3.18
- 24. http://www.columbia.edu/kermit/ckubwr.html#x3.19
- 25. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 26. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 27. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 28. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 29. http://www.columbia.edu/kermit/ckubwr.html#x3.13
- 30. http://www.columbia.edu/kermit/ckubwr.html#top
- 31. http://www.columbia.edu/kermit/ckubwr.html#contents
- 32. http://www.columbia.edu/kermit/ckubwr.html#x2
- 33. http://www.columbia.edu/kermit/ckubwr.html#x1.1
- 34. http://www.columbia.edu/kermit/ckubwr.html#x1.2
- 35. http://www.columbia.edu/kermit/ckubwr.html#x1.3
- 36. http://www.columbia.edu/kermit/ckubwr.html#x1.4
- 37. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 38. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 39. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 40. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 41. http://www.columbia.edu/kermit/ckcbwr.html
- 42. mailto:kermit-support@columbia.edu
- 43. http://www.columbia.edu/kermit/ckubwr.html#top
- 44. http://www.columbia.edu/kermit/ckubwr.html#contents
- 45. http://www.columbia.edu/kermit/ckubwr.html#x1.2
- 46. http://www.columbia.edu/kermit/ck60manual.html
- 47. http://www.columbia.edu/kermit/ckermit70.html
- 48. http://www.columbia.edu/kermit/ckermit80.html
- 49. http://www.columbia.edu/kermit/ckubwr.html#top
- 50. http://www.columbia.edu/kermit/ckubwr.html#contents
- 51. http://www.columbia.edu/kermit/ckubwr.html#x1
- 52. http://www.columbia.edu/kermit/ckubwr.html#x1.3
- 53. http://www.columbia.edu/kermit/ckubwr.html#x1.1
- 54. http://www.columbia.edu/kermit/support.html
- 55. http://www.columbia.edu/kermit/ckubwr.html#top
- 56. http://www.columbia.edu/kermit/ckubwr.html#contents
- 57. http://www.columbia.edu/kermit/ckubwr.html#x1
- 58. http://www.columbia.edu/kermit/ckubwr.html#x1.4
- 59. http://www.columbia.edu/kermit/ckubwr.html#x1.2
- 60. http://www.columbia.edu/kermit/ckubwr.html#top
- 61. http://www.columbia.edu/kermit/ckubwr.html#contents
- 62. http://www.columbia.edu/kermit/ckubwr.html#x1
- 63. http://www.columbia.edu/kermit/ckubwr.html#x1.3
- 64. http://www.columbia.edu/kermit/ckubwr.html#top
- 65. http://www.columbia.edu/kermit/ckubwr.html#contents
- 66. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 6. http://www.columbia.edu/kermit/ckscripts.html
+ 7. http://www.columbia.edu/kermit/current.html
+ 8. http://www.columbia.edu/kermit/whatsnew.html
+ 9. http://www.columbia.edu/kermit/faq.html
+ 10. http://www.columbia.edu/kermit/support.html
+ 11. http://www.columbia.edu/kermit/
+ 12. http://www.columbia.edu/
+ 13. http://www.columbia.edu/kermit/ckubwr.html
+ 14. http://www.columbia.edu/kermit/ckdaily.html
+ 15. http://www.columbia.edu/kermit/ckermit.html
+ 16. http://www.columbia.edu/kermit/ckuins.html
+ 17. http://www.columbia.edu/kermit/ckututor.html
+ 18. http://www.columbia.edu/kermit/ckubwr.html#x1
+ 19. http://www.columbia.edu/kermit/ckubwr.html#x2
+ 20. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 21. http://www.columbia.edu/kermit/ckubwr.html#x4
+ 22. http://www.columbia.edu/kermit/ckubwr.html#x5
+ 23. http://www.columbia.edu/kermit/ckubwr.html#x6
+ 24. http://www.columbia.edu/kermit/ckubwr.html#x7
+ 25. http://www.columbia.edu/kermit/ckubwr.html#x8
+ 26. http://www.columbia.edu/kermit/ckubwr.html#x9
+ 27. http://www.columbia.edu/kermit/ckubwr.html#x10
+ 28. http://www.columbia.edu/kermit/ckubwr.html#x11
+ 29. http://www.columbia.edu/kermit/ckubwr.html#x12
+ 30. http://www.columbia.edu/kermit/ckubwr.html#x13
+ 31. http://www.columbia.edu/kermit/ckubwr.html#x14
+ 32. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 33. http://www.columbia.edu/kermit/ckubwr.html#x3.18
+ 34. http://www.columbia.edu/kermit/ckubwr.html#x3.19
+ 35. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 36. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 37. http://www.columbia.edu/kermit/ckubwr.html#x3.7
+ 38. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 39. http://www.columbia.edu/kermit/ckubwr.html#top
+ 40. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 41. http://www.columbia.edu/kermit/ckubwr.html#x2
+ 42. http://www.columbia.edu/kermit/ckubwr.html#x1.1
+ 43. http://www.columbia.edu/kermit/ckubwr.html#x1.2
+ 44. http://www.columbia.edu/kermit/ckubwr.html#x1.3
+ 45. http://www.columbia.edu/kermit/ckubwr.html#x1.4
+ 46. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 47. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 48. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 49. http://www.columbia.edu/kermit/ckubwr.html#x3.7
+ 50. http://www.columbia.edu/kermit/ckcbwr.html
+ 51. mailto:kermit-support@columbia.edu
+ 52. http://www.columbia.edu/kermit/ckubwr.html#top
+ 53. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 54. http://www.columbia.edu/kermit/ckubwr.html#x1.2
+ 55. http://www.columbia.edu/kermit/ck60manual.html
+ 56. http://www.columbia.edu/kermit/ckermit70.html
+ 57. http://www.columbia.edu/kermit/ckermit80.html
+ 58. http://www.columbia.edu/kermit/ckermit90.html
+ 59. http://www.columbia.edu/kermit/ckubwr.html#top
+ 60. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 61. http://www.columbia.edu/kermit/ckubwr.html#x1
+ 62. http://www.columbia.edu/kermit/ckubwr.html#x1.3
+ 63. http://www.columbia.edu/kermit/ckubwr.html#x1.1
+ 64. http://www.columbia.edu/kermit/support.html
+ 65. http://www.columbia.edu/kermit/ckubwr.html#top
+ 66. http://www.columbia.edu/kermit/ckubwr.html#contents
67. http://www.columbia.edu/kermit/ckubwr.html#x1
- 68. http://www.columbia.edu/kermit/ckubwr.html#top
- 69. http://www.columbia.edu/kermit/ckubwr.html#contents
- 70. http://www.columbia.edu/kermit/ckubwr.html#x4
- 71. http://www.columbia.edu/kermit/ckubwr.html#x2
- 72. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 73. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 74. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 75. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 76. http://www.columbia.edu/kermit/ckubwr.html#x3.4
- 77. http://www.columbia.edu/kermit/ckubwr.html#x3.5
- 78. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 79. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 80. http://www.columbia.edu/kermit/ckubwr.html#x3.8
- 81. http://www.columbia.edu/kermit/ckubwr.html#x3.9
- 82. http://www.columbia.edu/kermit/ckubwr.html#x3.10
- 83. http://www.columbia.edu/kermit/ckubwr.html#x3.11
- 84. http://www.columbia.edu/kermit/ckubwr.html#x3.12
- 85. http://www.columbia.edu/kermit/ckubwr.html#x3.13
- 86. http://www.columbia.edu/kermit/ckubwr.html#x3.14
- 87. http://www.columbia.edu/kermit/ckubwr.html#x3.15
- 88. http://www.columbia.edu/kermit/ckubwr.html#x3.16
- 89. http://www.columbia.edu/kermit/ckubwr.html#x3.17
- 90. http://www.columbia.edu/kermit/ckubwr.html#x3.18
- 91. http://www.columbia.edu/kermit/ckubwr.html#x3.19
- 92. http://www.columbia.edu/kermit/ckubwr.html#x3.20
- 93. http://www.faqs.org/
- 94. http://aplawrence.com/Unixart/newtounix.html
- 95. http://www.columbia.edu/kermit/x3
- 96. mailto:kermit-support@columbia.edu
- 97. http://www.columbia.edu/kermit/support.html
- 98. http://www.columbia.edu/kermit/ckubwr.html#top
- 99. http://www.columbia.edu/kermit/ckubwr.html#contents
- 100. http://www.columbia.edu/kermit/ckubwr.html#x3
- 101. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 102. http://www.pcunix.com/
- 103. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
- 104. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
- 105. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
- 106. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
- 107. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
- 108. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
- 109. http://www.columbia.edu/kermit/ckubwr.html#top
- 110. http://www.columbia.edu/kermit/ckubwr.html#contents
- 111. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 112. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
- 113. http://www.columbia.edu/kermit/ckubwr.html#top
- 114. http://www.columbia.edu/kermit/ckubwr.html#contents
- 115. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 116. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
- 117. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
- 118. http://www.linmodems.org/
- 119. http://www.microsoft.com/hwdev/platform/PCdesign/LR/default.asp
- 120. http://www.columbia.edu/kermit/ckubwr.html#top
- 121. http://www.columbia.edu/kermit/ckubwr.html#contents
- 122. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 123. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
- 124. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
- 125. http://www.idir.net/~gromitkc/winmodem.html
- 126. http://www.digi.com/
- 127. http://www.columbia.edu/kermit/ckubwr.html#top
- 128. http://www.columbia.edu/kermit/ckubwr.html#contents
- 129. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 130. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
- 131. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
- 132. http://www.columbia.edu/kermit/ckubwr.html#top
- 133. http://www.columbia.edu/kermit/ckubwr.html#contents
- 134. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 135. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
- 136. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
+ 68. http://www.columbia.edu/kermit/ckubwr.html#x1.4
+ 69. http://www.columbia.edu/kermit/ckubwr.html#x1.2
+ 70. http://www.columbia.edu/kermit/ckubwr.html#top
+ 71. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 72. http://www.columbia.edu/kermit/ckubwr.html#x1
+ 73. http://www.columbia.edu/kermit/ckubwr.html#x1.3
+ 74. http://www.columbia.edu/kermit/ckubwr.html#top
+ 75. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 76. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 77. http://www.columbia.edu/kermit/ckubwr.html#x1
+ 78. http://www.columbia.edu/kermit/ckubwr.html#top
+ 79. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 80. http://www.columbia.edu/kermit/ckubwr.html#x4
+ 81. http://www.columbia.edu/kermit/ckubwr.html#x2
+ 82. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 83. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 84. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 85. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 86. http://www.columbia.edu/kermit/ckubwr.html#x3.4
+ 87. http://www.columbia.edu/kermit/ckubwr.html#x3.5
+ 88. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 89. http://www.columbia.edu/kermit/ckubwr.html#x3.7
+ 90. http://www.columbia.edu/kermit/ckubwr.html#x3.8
+ 91. http://www.columbia.edu/kermit/ckubwr.html#x3.9
+ 92. http://www.columbia.edu/kermit/ckubwr.html#x3.10
+ 93. http://www.columbia.edu/kermit/ckubwr.html#x3.11
+ 94. http://www.columbia.edu/kermit/ckubwr.html#x3.12
+ 95. http://www.columbia.edu/kermit/ckubwr.html#x3.13
+ 96. http://www.columbia.edu/kermit/ckubwr.html#x3.14
+ 97. http://www.columbia.edu/kermit/ckubwr.html#x3.15
+ 98. http://www.columbia.edu/kermit/ckubwr.html#x3.16
+ 99. http://www.columbia.edu/kermit/ckubwr.html#x3.17
+ 100. http://www.columbia.edu/kermit/ckubwr.html#x3.18
+ 101. http://www.columbia.edu/kermit/ckubwr.html#x3.19
+ 102. http://www.columbia.edu/kermit/ckubwr.html#x3.20
+ 103. http://www.faqs.org/
+ 104. http://aplawrence.com/Unixart/newtounix.html
+ 105. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 106. mailto:kermit-support@columbia.edu
+ 107. http://www.columbia.edu/kermit/support.html
+ 108. http://www.columbia.edu/kermit/ckubwr.html#top
+ 109. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 110. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 111. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 112. http://www.pcunix.com/
+ 113. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
+ 114. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
+ 115. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
+ 116. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
+ 117. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
+ 118. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
+ 119. http://www.columbia.edu/kermit/ckubwr.html#top
+ 120. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 121. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 122. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
+ 123. http://www.columbia.edu/kermit/ckubwr.html#top
+ 124. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 125. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 126. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
+ 127. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
+ 128. http://www.linmodems.org/
+ 129. http://www.microsoft.com/hwdev/platform/PCdesign/LR/default.asp
+ 130. http://www.columbia.edu/kermit/ckubwr.html#top
+ 131. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 132. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 133. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
+ 134. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
+ 135. http://www.idir.net/~gromitkc/winmodem.html
+ 136. http://www.digi.com/
137. http://www.columbia.edu/kermit/ckubwr.html#top
138. http://www.columbia.edu/kermit/ckubwr.html#contents
139. http://www.columbia.edu/kermit/ckubwr.html#x3.0
140. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
- 141. http://www.columbia.edu/kermit/ckubwr.html#top
- 142. http://www.columbia.edu/kermit/ckubwr.html#contents
- 143. http://www.columbia.edu/kermit/ckubwr.html#x3
- 144. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 145. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 146. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1
- 147. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
- 148. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
- 149. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
- 150. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5
- 151. http://www.emerson.emory.edu/services/aix-faq/
- 152. http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
- 153. http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html
- 154. http://aixpdslib.seas.ucla.edu/
- 155. http://www.rootvg.net (AIX history)/
- 156. ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
- 157. ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix
- 158. news:comp.unix.aix
- 159. http://www.columbia.edu/kermit/ckubwr.html#top
- 160. http://www.columbia.edu/kermit/ckubwr.html#contents
- 161. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 162. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
- 163. http://www.columbia.edu/kermit/ckubwr.html#top
- 164. http://www.columbia.edu/kermit/ckubwr.html#contents
- 165. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 166. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
- 167. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1
- 168. http://www.columbia.edu/kermit/security.html#servers
+ 141. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
+ 142. http://www.columbia.edu/kermit/ckubwr.html#top
+ 143. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 144. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 145. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
+ 146. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
+ 147. http://www.columbia.edu/kermit/ckubwr.html#top
+ 148. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 149. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 150. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
+ 151. http://www.columbia.edu/kermit/ckubwr.html#top
+ 152. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 153. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 154. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 155. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 156. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1
+ 157. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
+ 158. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
+ 159. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
+ 160. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5
+ 161. http://www.emerson.emory.edu/services/aix-faq/
+ 162. http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
+ 163. http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html
+ 164. http://aixpdslib.seas.ucla.edu/
+ 165. http://www.rootvg.net(AIXhistory)/
+ 166. ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
+ 167. ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix
+ 168. news:comp.unix.aix
169. http://www.columbia.edu/kermit/ckubwr.html#top
170. http://www.columbia.edu/kermit/ckubwr.html#contents
171. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 172. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
- 173. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
- 174. http://service.software.ibm.com/rs6000/
- 175. http://www.columbia.edu/kermit/ckubwr.html#top
- 176. http://www.columbia.edu/kermit/ckubwr.html#contents
- 177. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 178. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5
- 179. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
- 180. http://www.columbia.edu/kermit/ckubwr.html#top
- 181. http://www.columbia.edu/kermit/ckubwr.html#contents
- 182. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 183. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
- 184. http://www.columbia.edu/kermit/ckubwr.html#top
- 185. http://www.columbia.edu/kermit/ckubwr.html#contents
- 186. http://www.columbia.edu/kermit/ckubwr.html#x3
- 187. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 188. http://www.columbia.edu/kermit/ckubwr.html#x3.1
- 189. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
- 190. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
- 191. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
- 192. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
- 193. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
- 194. http://www.columbia.edu/kermit/ckubwr.html#x3.2.5
- 195. news:comp.sys.hp.hpux
- 196. http://www.columbia.edu/kermit/ckubwr.html#top
- 197. http://www.columbia.edu/kermit/ckubwr.html#contents
- 198. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 199. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
- 200. http://www.columbia.edu/kermit/ckubwr.html#top
- 201. http://www.columbia.edu/kermit/ckubwr.html#contents
- 202. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 203. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
- 204. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
- 205. ftp://kermit.columbia.edu/kermit/f/makefile
+ 172. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
+ 173. http://www.columbia.edu/kermit/ckubwr.html#top
+ 174. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 175. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 176. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
+ 177. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1
+ 178. http://www.columbia.edu/kermit/security.html#servers
+ 179. http://www.columbia.edu/kermit/ckubwr.html#top
+ 180. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 181. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 182. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
+ 183. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
+ 184. http://service.software.ibm.com/rs6000/
+ 185. http://www.columbia.edu/kermit/ckubwr.html#top
+ 186. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 187. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 188. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5
+ 189. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
+ 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.1
+ 193. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
+ 194. http://www.columbia.edu/kermit/ckubwr.html#top
+ 195. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 196. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 197. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 198. http://www.columbia.edu/kermit/ckubwr.html#x3.1
+ 199. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
+ 200. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
+ 201. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
+ 202. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
+ 203. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
+ 204. http://www.columbia.edu/kermit/ckubwr.html#x3.2.5
+ 205. news:comp.sys.hp.hpux
206. http://www.columbia.edu/kermit/ckubwr.html#top
207. http://www.columbia.edu/kermit/ckubwr.html#contents
208. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 209. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
- 210. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
- 211. http://www.columbia.edu/kermit/ckubwr.html#top
- 212. http://www.columbia.edu/kermit/ckubwr.html#contents
- 213. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 214. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
- 215. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
- 216. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1
- 217. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
- 218. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
- 219. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
- 220. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
+ 209. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
+ 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
+ 213. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
+ 214. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
+ 215. ftp://kermit.columbia.edu/kermit/f/makefile
+ 216. http://www.columbia.edu/kermit/ckubwr.html#top
+ 217. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 218. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 219. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
+ 220. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
221. http://www.columbia.edu/kermit/ckubwr.html#top
222. http://www.columbia.edu/kermit/ckubwr.html#contents
223. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 224. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
+ 224. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
225. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
- 226. http://www.columbia.edu/kermit/ckubwr.html#top
- 227. http://www.columbia.edu/kermit/ckubwr.html#contents
- 228. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
- 229. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
- 230. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1
+ 226. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1
+ 227. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
+ 228. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
+ 229. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
+ 230. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
231. http://www.columbia.edu/kermit/ckubwr.html#top
232. http://www.columbia.edu/kermit/ckubwr.html#contents
- 233. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
- 234. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
- 235. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
+ 233. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 234. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
+ 235. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
236. http://www.columbia.edu/kermit/ckubwr.html#top
237. http://www.columbia.edu/kermit/ckubwr.html#contents
238. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
- 239. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
- 240. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
+ 239. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
+ 240. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1
241. http://www.columbia.edu/kermit/ckubwr.html#top
242. http://www.columbia.edu/kermit/ckubwr.html#contents
243. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
244. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
- 245. http://www.columbia.edu/kermit/ckubwr.html#top
- 246. http://www.columbia.edu/kermit/ckubwr.html#contents
- 247. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 245. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
+ 246. http://www.columbia.edu/kermit/ckubwr.html#top
+ 247. http://www.columbia.edu/kermit/ckubwr.html#contents
248. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
- 249. http://www.columbia.edu/kermit/ckubwr.html#top
- 250. http://www.columbia.edu/kermit/ckubwr.html#contents
- 251. http://www.columbia.edu/kermit/ckubwr.html#x3
- 252. http://www.columbia.edu/kermit/ckubwr.html#x3.4
- 253. http://www.columbia.edu/kermit/ckubwr.html#x3.2
- 254. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
- 255. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
- 256. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
- 257. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
- 258. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
- 259. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
- 260. news:comp.os.linux.misc
- 261. news:comp.os.linux.answers
- 262. http://www.tldp.org/
- 263. http://www.tldp.org/FAQ/Linux-FAQ.html
- 264. http://www.tldp.org/HOWTO/Serial-HOWTO.html
- 265. http://tldp.org/HOWTO/Modem-HOWTO.html
- 266. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
- 267. ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
- 268. http://www.tldp.org/HOWTO/
- 269. http://www.tldp.org/hmirrors.html
- 270. http://www.redhat.com/apps/support/
- 271. http://www.debian.org/support
- 272. http://www.slackware.com/support/
- 273. http://www.caldera.com/support/
- 274. http://www.suse.com/support/
- 275. http://www.mandrake.com/support/
- 276. http://www.turbolinux.com/support/
- 277. http://www.linmodems.org/
- 278. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 279. http://linux.dreamtime.org/decnet/
- 280. mailto:kermit-support@columbia.edu
- 281. http://www.linmodems.org/
- 282. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
- 283. http://www.columbia.edu/kermit/security.html#servers
- 284. http://www.columbia.edu/kermit/sshclient.html
- 285. http://www.columbia.edu/kermit/ckubwr.html#top
- 286. http://www.columbia.edu/kermit/ckubwr.html#contents
- 287. http://www.columbia.edu/kermit/ckubwr.html#x3
- 288. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
- 289. http://www.columbia.edu/kermit/ckubwr.html#top
- 290. http://www.columbia.edu/kermit/ckubwr.html#contents
- 291. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 292. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
- 293. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
- 294. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 295. http://www.columbia.edu/kermit/ckubwr.html#x6
- 296. http://www.columbia.edu/kermit/ckubwr.html#x7
- 297. http://www.columbia.edu/kermit/ckubwr.html#x8
- 298. http://www.columbia.edu/kermit/ckuins.html#x10
- 299. http://www.columbia.edu/kermit/ckuins.html#x11
- 300. http://www.columbia.edu/kermit/ckuins.html
- 301. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 302. http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
- 303. http://www.columbia.edu/kermit/ckubwr.html#top
- 304. http://www.columbia.edu/kermit/ckubwr.html#contents
- 305. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 306. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
- 307. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
- 308. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
- 309. http://www.columbia.edu/kermit/ckfaq.html#term
- 310. http://dickey.his.com/xterm/xterm.html
- 311. http://dickey.his.com/xterm/xterm.html
- 312. ftp://kermit.columbia.edu/kermit/f/xmodmap.txt
- 313. http://www.columbia.edu/kermit/ckubwr.html#top
- 314. http://www.columbia.edu/kermit/ckubwr.html#contents
- 315. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 316. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
- 317. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
- 318. http://www.columbia.edu/kermit/ckubwr.html#top
- 319. http://www.columbia.edu/kermit/ckubwr.html#contents
- 320. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 321. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
- 322. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
- 323. http://www.columbia.edu/kermit/ckermit.html
- 324. mailto:kermit-support@columbia.edu
- 325. http://www.redhat.com/support/errata/RHBA-2001-153.html
- 326. news:comp.protocols.kermit.misc
- 327. http://www.columbia.edu/kermit/ckubwr.html#top
- 328. http://www.columbia.edu/kermit/ckubwr.html#contents
- 329. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 330. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
- 331. http://www.columbia.edu/kermit/ckubwr.html#top
- 332. http://www.columbia.edu/kermit/ckubwr.html#contents
- 333. http://www.columbia.edu/kermit/ckubwr.html#x3
- 334. http://www.columbia.edu/kermit/ckubwr.html#x3.5
- 335. http://www.columbia.edu/kermit/ckubwr.html#x3.3
- 336. http://www.columbia.edu/kermit/ckubwr.html#top
- 337. http://www.columbia.edu/kermit/ckubwr.html#contents
- 338. http://www.columbia.edu/kermit/ckubwr.html#x3
- 339. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 340. http://www.columbia.edu/kermit/ckubwr.html#x3.4
- 341. news:comp.os.qnx
- 342. http://www.columbia.edu/kermit/gkermit.html
- 343. http://www.columbia.edu/kermit/ckuins.html#x10
- 344. http://www.columbia.edu/kermit/ckuins.html
- 345. http://www.columbia.edu/kermit/ckubwr.html#top
- 346. http://www.columbia.edu/kermit/ckubwr.html#contents
- 347. http://www.columbia.edu/kermit/ckubwr.html#x3
- 348. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 349. http://www.columbia.edu/kermit/ckubwr.html#x3.5
- 350. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
- 351. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
- 352. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
- 353. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
- 354. http://www.columbia.edu/kermit/ckubwr.html#x3.10
- 355. http://aplawrence.com/SCOFAQ/
- 356. http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
- 357. http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
- 358. http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
- 359. http://pcunix.com/Unixart/modems.html
- 360. http://www.freebird.org/faq/
- 361. http://www.freebird.org/faq/developer.html
- 362. http://support.caldera.com/caldera
- 363. http://stage.caldera.com/ta/
- 364. http://aplawrence.com/newtosco.html
- 365. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
- 366. http://www.columbia.edu/kermit/ckfaq.html#term
- 367. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 368. http://www.columbia.edu/kermit/ckubwr.html#top
- 369. http://www.columbia.edu/kermit/ckubwr.html#contents
- 370. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 371. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
- 372. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 373. http://www.columbia.edu/kermit/ckubwr.html#top
- 374. http://www.columbia.edu/kermit/ckubwr.html#contents
- 375. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 376. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
- 377. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
- 378. http://www.digi.com/
- 379. ftp://ftp.fu-berlin.de/pub/unix/driver/fas
- 380. http://www.columbia.edu/kermit/ckubwr.html#x14
- 381. http://www.sco.com/
- 382. ftp://ftp.sco.com/
- 383. http://www.columbia.edu/kermit/ckubwr.html#top
- 384. http://www.columbia.edu/kermit/ckubwr.html#contents
- 385. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 386. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
- 387. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
- 388. http://www.columbia.edu/kermit/ckubwr.html#x3.10
- 389. http://www.columbia.edu/kermit/ckubwr.html#top
- 390. http://www.columbia.edu/kermit/ckubwr.html#contents
- 391. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 392. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
- 393. http://www.columbia.edu/kermit/ckubwr.html#top
- 394. http://www.columbia.edu/kermit/ckubwr.html#contents
- 395. http://www.columbia.edu/kermit/ckubwr.html#x3
- 396. http://www.columbia.edu/kermit/ckubwr.html#x3.8
- 397. http://www.columbia.edu/kermit/ckubwr.html#x3.6
- 398. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
- 399. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
- 400. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
- 401. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
- 402. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
- 403. news:comp.unix.solaris
- 404. http://access1.sun.com/
- 405. http://docs.sun.com/
- 406. http://www.sunhelp.com/
- 407. http://www.wins.uva.nl/pub/solaris/solaris2/
- 408. http://www.wins.uva.nl/cgi-bin/sfaq.cgi
- 409. ftp://ftp.wins.uva.nl/pub/solaris
- 410. http://www.science.uva.nl/pub/solaris/solaris2.html
- 411. http://www.stokely.com/
- 412. http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
- 413. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 414. http://www.columbia.edu/kermit/ckubwr.html#top
- 415. http://www.columbia.edu/kermit/ckubwr.html#contents
- 416. http://www.columbia.edu/kermit/ckubwr.html#x3
- 417. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 418. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
- 419. http://www.columbia.edu/kermit/ckubwr.html#top
- 420. http://www.columbia.edu/kermit/ckubwr.html#contents
- 421. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 422. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
- 423. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
- 424. http://www.columbia.edu/kermit/ckubwr.html#top
- 425. http://www.columbia.edu/kermit/ckubwr.html#contents
- 426. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 427. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
- 428. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
- 429. http://www.columbia.edu/kermit/ckubwr.html#top
- 430. http://www.columbia.edu/kermit/ckubwr.html#contents
- 431. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 432. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
+ 249. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
+ 250. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
+ 251. http://www.columbia.edu/kermit/ckubwr.html#top
+ 252. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 253. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
+ 254. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
+ 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.2
+ 258. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
+ 259. http://www.columbia.edu/kermit/ckubwr.html#top
+ 260. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 261. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 262. http://www.columbia.edu/kermit/ckubwr.html#x3.4
+ 263. http://www.columbia.edu/kermit/ckubwr.html#x3.2
+ 264. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
+ 265. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
+ 266. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
+ 267. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
+ 268. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
+ 269. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
+ 270. http://en.wikipedia.org/wiki/Avahi_(software)
+ 271. news:comp.os.linux.misc
+ 272. news:comp.os.linux.answers
+ 273. http://www.tldp.org/
+ 274. http://www.tldp.org/FAQ/Linux-FAQ.html
+ 275. http://www.tldp.org/HOWTO/Serial-HOWTO.html
+ 276. http://tldp.org/HOWTO/Modem-HOWTO.html
+ 277. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
+ 278. ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
+ 279. http://www.tldp.org/HOWTO/
+ 280. http://www.tldp.org/hmirrors.html
+ 281. http://www.redhat.com/apps/support/
+ 282. http://www.debian.org/support
+ 283. http://www.slackware.com/support/
+ 284. http://www.caldera.com/support/
+ 285. http://www.novell.com/support/microsites/microsite.do
+ 286. http://www.mandrake.com/support/
+ 287. http://www.turbolinux.com/support/
+ 288. http://www.linmodems.org/
+ 289. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 290. http://linux.dreamtime.org/decnet/
+ 291. mailto:kermit-support@columbia.edu
+ 292. http://www.linmodems.org/
+ 293. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
+ 294. http://www.columbia.edu/kermit/security.html#servers
+ 295. http://www.columbia.edu/kermit/sshclient.html
+ 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.3.2
+ 300. http://www.columbia.edu/kermit/ckubwr.html#top
+ 301. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 302. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 303. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
+ 304. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
+ 305. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 306. http://www.columbia.edu/kermit/ckubwr.html#x6
+ 307. http://www.columbia.edu/kermit/ckubwr.html#x7
+ 308. http://www.columbia.edu/kermit/ckubwr.html#x8
+ 309. http://www.columbia.edu/kermit/ckuins.html#x10
+ 310. http://www.columbia.edu/kermit/ckuins.html#x11
+ 311. http://www.columbia.edu/kermit/ckuins.html
+ 312. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 313. http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
+ 314. http://www.columbia.edu/kermit/ckubwr.html#top
+ 315. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 316. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 317. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
+ 318. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
+ 319. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
+ 320. http://www.columbia.edu/kermit/ckfaq.html#term
+ 321. http://dickey.his.com/xterm/xterm.html
+ 322. http://dickey.his.com/xterm/xterm.html
+ 323. ftp://kermit.columbia.edu/kermit/f/xmodmap.txt
+ 324. http://www.columbia.edu/kermit/ckubwr.html#top
+ 325. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 326. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 327. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
+ 328. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
+ 329. http://www.columbia.edu/kermit/ckubwr.html#top
+ 330. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 331. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 332. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
+ 333. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
+ 334. http://www.columbia.edu/kermit/ckermit.html
+ 335. mailto:kermit-support@columbia.edu
+ 336. http://www.redhat.com/support/errata/RHBA-2001-153.html
+ 337. news:comp.protocols.kermit.misc
+ 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.3
+ 341. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
+ 342. http://www.columbia.edu/kermit/ckubwr.html#top
+ 343. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 344. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 345. http://www.columbia.edu/kermit/ckubwr.html#x3.5
+ 346. http://www.columbia.edu/kermit/ckubwr.html#x3.3
+ 347. http://www.columbia.edu/kermit/ckubwr.html#top
+ 348. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 349. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 350. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 351. http://www.columbia.edu/kermit/ckubwr.html#x3.4
+ 352. news:comp.os.qnx
+ 353. http://www.columbia.edu/kermit/gkermit.html
+ 354. http://www.columbia.edu/kermit/ckuins.html#x10
+ 355. http://www.columbia.edu/kermit/ckuins.html
+ 356. http://www.columbia.edu/kermit/ckubwr.html#top
+ 357. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 358. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 359. http://www.columbia.edu/kermit/ckubwr.html#x3.7
+ 360. http://www.columbia.edu/kermit/ckubwr.html#x3.5
+ 361. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
+ 362. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
+ 363. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
+ 364. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
+ 365. http://www.columbia.edu/kermit/ckubwr.html#x3.10
+ 366. http://aplawrence.com/SCOFAQ/
+ 367. http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
+ 368. http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
+ 369. http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
+ 370. http://pcunix.com/Unixart/modems.html
+ 371. http://www.freebird.org/faq/
+ 372. http://www.freebird.org/faq/developer.html
+ 373. http://support.caldera.com/caldera
+ 374. http://stage.caldera.com/ta/
+ 375. http://aplawrence.com/newtosco.html
+ 376. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
+ 377. http://www.columbia.edu/kermit/ckfaq.html#term
+ 378. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 379. http://www.columbia.edu/kermit/ckubwr.html#top
+ 380. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 381. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 382. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
+ 383. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 384. http://www.columbia.edu/kermit/ckubwr.html#top
+ 385. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 386. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 387. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
+ 388. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
+ 389. http://www.digi.com/
+ 390. ftp://ftp.fu-berlin.de/pub/unix/driver/fas
+ 391. http://www.columbia.edu/kermit/ckubwr.html#x14
+ 392. http://www.sco.com/
+ 393. ftp://ftp.sco.com/
+ 394. http://www.columbia.edu/kermit/ckubwr.html#top
+ 395. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 396. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 397. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
+ 398. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
+ 399. http://www.columbia.edu/kermit/ckubwr.html#x3.10
+ 400. http://www.columbia.edu/kermit/ckubwr.html#top
+ 401. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 402. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 403. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
+ 404. http://www.columbia.edu/kermit/ckubwr.html#top
+ 405. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 406. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 407. http://www.columbia.edu/kermit/ckubwr.html#x3.8
+ 408. http://www.columbia.edu/kermit/ckubwr.html#x3.6
+ 409. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
+ 410. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
+ 411. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
+ 412. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
+ 413. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
+ 414. news:comp.unix.solaris
+ 415. http://accesss1.sun.com/
+ 416. http://docs.sun.com/
+ 417. http://www.sunhelp.com/
+ 418. http://www.wins.uva.nl/pub/solaris/solaris2/
+ 419. http://www.wins.uva.nl/cgi-bin/sfaq.cgi
+ 420. ftp://ftp.wins.uva.nl/pub/solaris
+ 421. http://www.science.uva.nl/pub/solaris/solaris2.html
+ 422. http://www.stokely.com/
+ 423. http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
+ 424. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 425. http://www.columbia.edu/kermit/ckubwr.html#top
+ 426. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 427. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 428. http://www.columbia.edu/kermit/ckubwr.html#x3.7
+ 429. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
+ 430. http://www.columbia.edu/kermit/ckubwr.html#top
+ 431. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 432. http://www.columbia.edu/kermit/ckubwr.html#x3.7
433. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
- 434. news:comp.os.vms
+ 434. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
435. http://www.columbia.edu/kermit/ckubwr.html#top
436. http://www.columbia.edu/kermit/ckubwr.html#contents
437. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 438. http://www.columbia.edu/kermit/ckubwr.html#x3.7.6
- 439. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
+ 438. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
+ 439. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
440. http://www.columbia.edu/kermit/ckubwr.html#top
441. http://www.columbia.edu/kermit/ckubwr.html#contents
442. http://www.columbia.edu/kermit/ckubwr.html#x3.7
443. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
- 444. http://www.columbia.edu/kermit/ckubwr.html#top
- 445. http://www.columbia.edu/kermit/ckubwr.html#contents
- 446. http://www.columbia.edu/kermit/ckubwr.html#x3
- 447. http://www.columbia.edu/kermit/ckubwr.html#x3.9
+ 444. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
+ 445. news:comp.os.vms
+ 446. http://www.columbia.edu/kermit/ckubwr.html#top
+ 447. http://www.columbia.edu/kermit/ckubwr.html#contents
448. http://www.columbia.edu/kermit/ckubwr.html#x3.7
- 449. http://www.stokely.com/
- 450. http://access1.sun.com/
- 451. http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
- 452. ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
- 453. ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref
- 454. http://www.columbia.edu/kermit/ckubwr.html#top
- 455. http://www.columbia.edu/kermit/ckubwr.html#contents
- 456. http://www.columbia.edu/kermit/ckubwr.html#x3
- 457. http://www.columbia.edu/kermit/ckubwr.html#x3.10
- 458. http://www.columbia.edu/kermit/ckubwr.html#x3.8
- 459. news:comp.unix.ultrix
- 460. news:comp.sys.dec
- 461. http://www.columbia.edu/kermit/ckubwr.html#top
- 462. http://www.columbia.edu/kermit/ckubwr.html#contents
- 463. http://www.columbia.edu/kermit/ckubwr.html#x3
- 464. http://www.columbia.edu/kermit/ckubwr.html#x3.11
- 465. http://www.columbia.edu/kermit/ckubwr.html#x3.9
- 466. http://www.freebird.org/
- 467. http://www.freebird.org/faq/
- 468. news:comp.unix.unixware.misc
- 469. news:comp.unix.sco.misc
- 470. http://www.columbia.edu/kermit/ckubwr.html#x3.0
- 471. ftp://kermit.columbia.edu/kermit/f/ckutio.c
+ 449. http://www.columbia.edu/kermit/ckubwr.html#x3.7.6
+ 450. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
+ 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.7
+ 454. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
+ 455. http://www.columbia.edu/kermit/ckubwr.html#top
+ 456. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 457. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 458. http://www.columbia.edu/kermit/ckubwr.html#x3.9
+ 459. http://www.columbia.edu/kermit/ckubwr.html#x3.7
+ 460. http://www.stokely.com/
+ 461. http://accesss1.sun.com/
+ 462. http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
+ 463. ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
+ 464. ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref
+ 465. http://www.columbia.edu/kermit/ckubwr.html#top
+ 466. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 467. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 468. http://www.columbia.edu/kermit/ckubwr.html#x3.10
+ 469. http://www.columbia.edu/kermit/ckubwr.html#x3.8
+ 470. news:comp.unix.ultrix
+ 471. news:comp.sys.dec
472. http://www.columbia.edu/kermit/ckubwr.html#top
473. http://www.columbia.edu/kermit/ckubwr.html#contents
474. http://www.columbia.edu/kermit/ckubwr.html#x3
- 475. http://www.columbia.edu/kermit/ckubwr.html#x3.12
- 476. http://www.columbia.edu/kermit/ckubwr.html#x3.10
- 477. http://www.columbia.edu/kermit/ckubwr.html#top
- 478. http://www.columbia.edu/kermit/ckubwr.html#contents
- 479. http://www.columbia.edu/kermit/ckubwr.html#x3
- 480. http://www.columbia.edu/kermit/ckubwr.html#x3.13
- 481. http://www.columbia.edu/kermit/ckubwr.html#x3.11
- 482. http://www.columbia.edu/kermit/ckubwr.html#top
- 483. http://www.columbia.edu/kermit/ckubwr.html#contents
- 484. http://www.columbia.edu/kermit/ckubwr.html#x3
- 485. http://www.columbia.edu/kermit/ckubwr.html#x3.14
+ 475. http://www.columbia.edu/kermit/ckubwr.html#x3.11
+ 476. http://www.columbia.edu/kermit/ckubwr.html#x3.9
+ 477. http://www.freebird.org/
+ 478. http://www.freebird.org/faq/
+ 479. news:comp.unix.unixware.misc
+ 480. news:comp.unix.sco.misc
+ 481. http://www.columbia.edu/kermit/ckubwr.html#x3.0
+ 482. ftp://kermit.columbia.edu/kermit/f/ckutio.c
+ 483. http://www.columbia.edu/kermit/ckubwr.html#top
+ 484. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 485. http://www.columbia.edu/kermit/ckubwr.html#x3
486. http://www.columbia.edu/kermit/ckubwr.html#x3.12
- 487. http://www.columbia.edu/kermit/ckubwr.html#top
- 488. http://www.columbia.edu/kermit/ckubwr.html#contents
- 489. http://www.columbia.edu/kermit/ckubwr.html#x3
- 490. http://www.columbia.edu/kermit/ckubwr.html#x3.15
+ 487. http://www.columbia.edu/kermit/ckubwr.html#x3.10
+ 488. http://www.columbia.edu/kermit/ckubwr.html#top
+ 489. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 490. http://www.columbia.edu/kermit/ckubwr.html#x3
491. http://www.columbia.edu/kermit/ckubwr.html#x3.13
- 492. news:comp.sys.sgi.misc
- 493. news:comp.sys.sgi.admin
- 494. http://www.sgi.com/
- 495. http://www-viz.tamu.edu/~sgi-faq/
- 496. ftp://viz.tamu.edu/pub/sgi/faq/
- 497. http://www.columbia.edu/kermit/ckuins.html
- 498. http://freeware.sgi.com/Installable/gcc-2.95.2.html
- 499. http://freeware.sgi.com/Installable/gcc-2.95.2.html
- 500. http://www.columbia.edu/kermit/ckubwr.html#top
- 501. http://www.columbia.edu/kermit/ckubwr.html#contents
- 502. http://www.columbia.edu/kermit/ckubwr.html#x3
- 503. http://www.columbia.edu/kermit/ckubwr.html#x3.16
- 504. http://www.columbia.edu/kermit/ckubwr.html#x3.14
- 505. news:comp.sys.be
- 506. http://www.columbia.edu/kermit/ckubwr.html#top
- 507. http://www.columbia.edu/kermit/ckubwr.html#contents
- 508. http://www.columbia.edu/kermit/ckubwr.html#x3
- 509. http://www.columbia.edu/kermit/ckubwr.html#x3.17
- 510. http://www.columbia.edu/kermit/ckubwr.html#x3.15
+ 492. http://www.columbia.edu/kermit/ckubwr.html#x3.11
+ 493. http://www.columbia.edu/kermit/ckubwr.html#top
+ 494. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 495. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 496. http://www.columbia.edu/kermit/ckubwr.html#x3.14
+ 497. http://www.columbia.edu/kermit/ckubwr.html#x3.12
+ 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#x3
+ 501. http://www.columbia.edu/kermit/ckubwr.html#x3.15
+ 502. http://www.columbia.edu/kermit/ckubwr.html#x3.13
+ 503. news:comp.sys.sgi.misc
+ 504. news:comp.sys.sgi.admin
+ 505. http://www.sgi.com/
+ 506. http://www-viz.tamu.edu/~sgi-faq/
+ 507. ftp://viz.tamu.edu/pub/sgi/faq/
+ 508. http://www.columbia.edu/kermit/ckuins.html
+ 509. http://freeware.sgi.com/Installable/gcc-2.95.2.html
+ 510. http://freeware.sgi.com/Installable/gcc-2.95.2.html
511. http://www.columbia.edu/kermit/ckubwr.html#top
512. http://www.columbia.edu/kermit/ckubwr.html#contents
513. http://www.columbia.edu/kermit/ckubwr.html#x3
- 514. http://www.columbia.edu/kermit/ckubwr.html#x3.18
- 515. http://www.columbia.edu/kermit/ckubwr.html#x3.16
- 516. http://www.columbia.edu/kermit/ckubwr.html#top
- 517. http://www.columbia.edu/kermit/ckubwr.html#contents
- 518. http://www.columbia.edu/kermit/ckubwr.html#x3
- 519. http://www.columbia.edu/kermit/ckubwr.html#x3.19
+ 514. http://www.columbia.edu/kermit/ckubwr.html#x3.16
+ 515. http://www.columbia.edu/kermit/ckubwr.html#x3.14
+ 516. news:comp.sys.be
+ 517. http://www.columbia.edu/kermit/ckubwr.html#top
+ 518. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 519. http://www.columbia.edu/kermit/ckubwr.html#x3
520. http://www.columbia.edu/kermit/ckubwr.html#x3.17
- 521. http://www.columbia.edu/kermit/ckubwr.html#top
- 522. http://www.columbia.edu/kermit/ckubwr.html#contents
- 523. http://www.columbia.edu/kermit/ckubwr.html#x3
- 524. http://www.columbia.edu/kermit/ckubwr.html#x3.20
+ 521. http://www.columbia.edu/kermit/ckubwr.html#x3.15
+ 522. http://www.columbia.edu/kermit/ckubwr.html#top
+ 523. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 524. http://www.columbia.edu/kermit/ckubwr.html#x3
525. http://www.columbia.edu/kermit/ckubwr.html#x3.18
- 526. http://www.keyspan.com/products/usb/adapter/
- 527. http://www.columbia.edu/kermit/ckuins.html
- 528. http://cerebus.sandiego.edu/~jerry/UnixTips/
- 529. http://www.columbia.edu/kermit/ckubwr.html#top
- 530. http://www.columbia.edu/kermit/ckubwr.html#contents
- 531. http://www.columbia.edu/kermit/ckubwr.html#x3
- 532. http://www.columbia.edu/kermit/ckubwr.html#x3.19
- 533. http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg00000.html
- 534. http://www.columbia.edu/kermit/ckubwr.html#top
- 535. http://www.columbia.edu/kermit/ckubwr.html#contents
- 536. http://www.columbia.edu/kermit/ckubwr.html#x5
- 537. http://www.columbia.edu/kermit/ckubwr.html#x3
- 538. http://www.columbia.edu/kermit/ckccfg.html
- 539. http://www.columbia.edu/kermit/ckubwr.html#top
- 540. http://www.columbia.edu/kermit/ckubwr.html#contents
- 541. http://www.columbia.edu/kermit/ckubwr.html#x6
- 542. http://www.columbia.edu/kermit/ckubwr.html#x4
- 543. http://www.columbia.edu/kermit/ckuins.html
- 544. http://www.columbia.edu/kermit/ckubwr.html#top
- 545. http://www.columbia.edu/kermit/ckubwr.html#contents
- 546. http://www.columbia.edu/kermit/ckubwr.html#x7
- 547. http://www.columbia.edu/kermit/ckubwr.html#x5
- 548. http://www.columbia.edu/kermit/ckuins.html#9.5
- 549. http://www.columbia.edu/kermit/ckubwr.html#x3
- 550. http://www.columbia.edu/kermit/ckubwr.html#top
- 551. http://www.columbia.edu/kermit/ckubwr.html#contents
- 552. http://www.columbia.edu/kermit/ckubwr.html#x8
- 553. http://www.columbia.edu/kermit/ckubwr.html#x6
- 554. http://www.columbia.edu/kermit/ckuins.html#x8
- 555. http://www.columbia.edu/kermit/ckuins.html
- 556. http://www.columbia.edu/kermit/ck60manual.html
- 557. http://www.columbia.edu/kermit/ckubwr.html#top
- 558. http://www.columbia.edu/kermit/ckubwr.html#contents
- 559. http://www.columbia.edu/kermit/ckubwr.html#x9
+ 526. http://www.columbia.edu/kermit/ckubwr.html#x3.16
+ 527. http://www.columbia.edu/kermit/ckubwr.html#top
+ 528. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 529. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 530. http://www.columbia.edu/kermit/ckubwr.html#x3.19
+ 531. http://www.columbia.edu/kermit/ckubwr.html#x3.17
+ 532. http://www.columbia.edu/kermit/ckubwr.html#top
+ 533. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 534. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 535. http://www.columbia.edu/kermit/ckubwr.html#x3.20
+ 536. http://www.columbia.edu/kermit/ckubwr.html#x3.18
+ 537. http://www.columbia.edu/kermit/mac.html
+ 538. http://www.amazon.com/gp/product/B0000VYJRY?ie=UTF8&tag=aleidmoreldom-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B0000VYJRY
+ 539. http://www.columbia.edu/kermit/ckuins.html#x10
+ 540. http://www.columbia.edu/kermit/ckuins.html
+ 541. http://www.amazon.com/gp/product/B000FX61MS?ie=UTF8&tag=aleidmoreldom-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B000FX61MS
+ 542. mailto:kermit@columbia.edu
+ 543. http://www.columbia.edu/kermit/ckubwr.html#top
+ 544. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 545. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 546. http://www.columbia.edu/kermit/ckubwr.html#x3.19
+ 547. http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg00000.html
+ 548. http://www.columbia.edu/kermit/ckubwr.html#top
+ 549. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 550. http://www.columbia.edu/kermit/ckubwr.html#x5
+ 551. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 552. http://www.columbia.edu/kermit/ckccfg.html
+ 553. http://www.columbia.edu/kermit/ckubwr.html#top
+ 554. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 555. http://www.columbia.edu/kermit/ckubwr.html#x6
+ 556. http://www.columbia.edu/kermit/ckubwr.html#x4
+ 557. http://www.columbia.edu/kermit/ckuins.html
+ 558. http://www.columbia.edu/kermit/ckubwr.html#top
+ 559. http://www.columbia.edu/kermit/ckubwr.html#contents
560. http://www.columbia.edu/kermit/ckubwr.html#x7
- 561. http://www.columbia.edu/kermit/ckubwr.html#top
- 562. http://www.columbia.edu/kermit/ckubwr.html#contents
- 563. http://www.columbia.edu/kermit/ckubwr.html#x10
- 564. http://www.columbia.edu/kermit/ckubwr.html#x8
- 565. http://www.columbia.edu/kermit/ck60manual.html
- 566. http://dickey.his.com/xterm/xterm.html
- 567. http://www.columbia.edu/kermit/ckubwr.html#top
- 568. http://www.columbia.edu/kermit/ckubwr.html#contents
- 569. http://www.columbia.edu/kermit/ckubwr.html#x11
- 570. http://www.columbia.edu/kermit/ckubwr.html#x9
- 571. http://www.columbia.edu/kermit/ckubwr.html#top
- 572. http://www.columbia.edu/kermit/ckubwr.html#contents
- 573. http://www.columbia.edu/kermit/ckubwr.html#x12
- 574. http://www.columbia.edu/kermit/ckubwr.html#x10
- 575. http://www.columbia.edu/kermit/ckubwr.html#x11.1
- 576. http://www.columbia.edu/kermit/ckubwr.html#x11.2
- 577. http://www.columbia.edu/kermit/ckubwr.html#top
- 578. http://www.columbia.edu/kermit/ckubwr.html#contents
- 579. http://www.columbia.edu/kermit/ckubwr.html#x11
- 580. http://www.columbia.edu/kermit/ckubwr.html#x11.2
- 581. http://www.columbia.edu/kermit/ck60manual.html
+ 561. http://www.columbia.edu/kermit/ckubwr.html#x5
+ 562. http://www.columbia.edu/kermit/ckuins.html#9.5
+ 563. http://www.columbia.edu/kermit/ckubwr.html#x3
+ 564. http://www.columbia.edu/kermit/ckubwr.html#top
+ 565. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 566. http://www.columbia.edu/kermit/ckubwr.html#x8
+ 567. http://www.columbia.edu/kermit/ckubwr.html#x6
+ 568. http://www.columbia.edu/kermit/ckuins.html#x8
+ 569. http://www.columbia.edu/kermit/ckuins.html
+ 570. http://www.columbia.edu/kermit/ck60manual.html
+ 571. http://www.columbia.edu/kermit/cable.html
+ 572. http://www.columbia.edu/kermit/ckubwr.html#top
+ 573. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 574. http://www.columbia.edu/kermit/ckubwr.html#x9
+ 575. http://www.columbia.edu/kermit/ckubwr.html#x7
+ 576. http://www.columbia.edu/kermit/ckubwr.html#top
+ 577. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 578. http://www.columbia.edu/kermit/ckubwr.html#x10
+ 579. http://www.columbia.edu/kermit/ckubwr.html#x8
+ 580. http://www.columbia.edu/kermit/ck60manual.html
+ 581. http://dickey.his.com/xterm/xterm.html
582. http://www.columbia.edu/kermit/ckubwr.html#top
583. http://www.columbia.edu/kermit/ckubwr.html#contents
584. http://www.columbia.edu/kermit/ckubwr.html#x11
- 585. http://www.columbia.edu/kermit/ckubwr.html#x11.1
- 586. http://www.columbia.edu/kermit/ck60manual.html
- 587. http://www.columbia.edu/kermit/ckubwr.html#top
- 588. http://www.columbia.edu/kermit/ckubwr.html#contents
- 589. http://www.columbia.edu/kermit/ckubwr.html#x13
- 590. http://www.columbia.edu/kermit/ckubwr.html#x11
- 591. http://www.columbia.edu/kermit/security.html
+ 585. http://www.columbia.edu/kermit/ckubwr.html#x9
+ 586. http://www.columbia.edu/kermit/ckubwr.html#top
+ 587. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 588. http://www.columbia.edu/kermit/ckubwr.html#x12
+ 589. http://www.columbia.edu/kermit/ckubwr.html#x10
+ 590. http://www.columbia.edu/kermit/ckubwr.html#x11.1
+ 591. http://www.columbia.edu/kermit/ckubwr.html#x11.2
592. http://www.columbia.edu/kermit/ckubwr.html#top
593. http://www.columbia.edu/kermit/ckubwr.html#contents
- 594. http://www.columbia.edu/kermit/ckubwr.html#x14
- 595. http://www.columbia.edu/kermit/ckubwr.html#x12
- 596. http://www.columbia.edu/kermit/ckubwr.html#top
- 597. http://www.columbia.edu/kermit/ckubwr.html#contents
- 598. http://www.columbia.edu/kermit/ckubwr.html#x15
- 599. http://www.columbia.edu/kermit/ckubwr.html#x14
- 600. mailto:support@stallion.oz.au
- 601. http://www.stallion.com/
+ 594. http://www.columbia.edu/kermit/ckubwr.html#x11
+ 595. http://www.columbia.edu/kermit/ckubwr.html#x11.2
+ 596. http://www.columbia.edu/kermit/ck60manual.html
+ 597. http://www.columbia.edu/kermit/ckubwr.html#top
+ 598. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 599. http://www.columbia.edu/kermit/ckubwr.html#x11
+ 600. http://www.columbia.edu/kermit/ckubwr.html#x11.1
+ 601. http://www.columbia.edu/kermit/ck60manual.html
602. http://www.columbia.edu/kermit/ckubwr.html#top
603. http://www.columbia.edu/kermit/ckubwr.html#contents
- 604. http://www.columbia.edu/kermit/ckermit.html
- 605. http://www.columbia.edu/kermit/ck80.html
- 606. http://www.columbia.edu/kermit/index.html
- 607. http://www.columbia.edu/kermit/index.html
- 608. http://www.columbia.edu/
- 609. mailto:kermit@columbia.edu
+ 604. http://www.columbia.edu/kermit/ckubwr.html#x13
+ 605. http://www.columbia.edu/kermit/ckubwr.html#x11
+ 606. http://www.columbia.edu/kermit/security.html
+ 607. http://www.columbia.edu/kermit/ckubwr.html#top
+ 608. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 609. http://www.columbia.edu/kermit/ckubwr.html#x14
+ 610. http://www.columbia.edu/kermit/ckubwr.html#x12
+ 611. http://www.columbia.edu/kermit/ckubwr.html#top
+ 612. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 613. http://www.columbia.edu/kermit/ckubwr.html#x15
+ 614. http://www.columbia.edu/kermit/ckubwr.html#x14
+ 615. mailto:support@stallion.oz.au
+ 616. http://www.stallion.com/
+ 617. http://www.columbia.edu/kermit/ckubwr.html#top
+ 618. http://www.columbia.edu/kermit/ckubwr.html#contents
+ 619. http://www.columbia.edu/kermit/ckermit.html
+ 620. http://www.columbia.edu/kermit/ck80.html
+ 621. http://www.columbia.edu/kermit/index.html
+ 622. http://www.columbia.edu/kermit/index.html
+ 623. http://www.columbia.edu/
+ 624. mailto:kermit@columbia.edu
projects / ckermit.git / blobdiff