C-Kermit 8.0 Unix Hints and Tips
Frank da Cruz
[1]The Kermit Project, [2]Columbia University
As of: C-Kermit 8.0.211 10 April 2004 This page last updated: Fri Apr 16 16:13:14 2004 (New York USA Time)
IF YOU ARE READING A PLAIN-TEXT version of this document, note it
is a plain-text dump of a Web page. You can visit the original (and
possibly more up-to-date) Web page here:
[3]http://www.columbia.edu/kermit/ckubwr.html
Since the material in this file has been accumulating since 1985,
some (much) of it might be dated. [4]Feedback from experts on
particular OS's and platforms is always welcome.
[ [5]C-Kermit ] [ [6]Installation Instructions ] [ [7]TUTORIAL ]
CONTENTS
- [8]INTRODUCTION
- [9]PREBUILT C-KERMIT BINARIES
- [10]PLATFORM-SPECIFIC NOTES
- [11]GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
- [12]INITIALIZATION AND COMMAND FILES
- [13]COMMUNICATION SPEED SELECTION
- [14]COMMUNICATIONS AND DIALING
- [15]HARDWARE FLOW CONTROL
- [16]TERMINAL CONNECTION AND KEY MAPPING
- [17]FILE TRANSFER
- [18]EXTERNAL FILE TRANSFER PROTOCOLS
- [19]SECURITY
- [20]MISCELLANEOUS USER REPORTS
- [21]THIRD-PARTY DRIVERS
Quick Links: [ [22]Linux ] [ [23]*BSD ] [[24]Mac OS X] [ [25]AIX ] [ [26]HP-UX ] [ [27]Solaris ] [ [28]SCO ] [ [29]DEC/Compaq ]
- INTRODUCTION
[ [30]Top ] [ [31]Contents ] [ [32]Next ]
SECTION CONTENTS
1.1. [33]Documentation
1.2. [34]Technical Support
1.3. [35]The Year 2000
1.4. [36]The Euro
THIS IS WHAT USED TO BE CALLED the "beware file" for the Unix version of C-Kermit, previously distributed as ckubwr.txt and, before that, as ckuker.bwr, after the fashion of old Digital Equipment Corporation (DEC) software releases that came with release notes (describing what had changed) and a "beware file" listing known bugs, limitations, "non-goals", and things to watch out for. The C-Kermit beware file has been accumulating since 1985, and it applies to many different hardware platforms and operating systems, and many versions of them, so it is quite large. Prior to C-Kermit 8.0, it was distributed only in plain-text format. Now it is available as a Web document with links, internal cross references, and so on, to make it easier to use.
This document applies to Unix C-Kermit in general, as well as to specific Unix variations like [37]Linux, [38]AIX, [39]HP-UX, [40]Solaris, and so on, and should be read in conjunction with the [41]platform-independent C-Kermit beware file, which contains similar information, but applying to all versions of C-Kermit (VMS, Windows, OS/2, AOS/VS, VOS, etc, as well as to Unix).
There is much in this document that is (only) of historical interest. The navigation links should help you skip directly to the sections that are relevant to you. Numerous offsite Web links are supposed to lead to further information but, as you know, Web links go stale frequently and without warning. If you can supply additional, corrected, updated, or better Web links, please feel free to [42]let us know.
1.1. Documentation
[ [43]Top ] [ [44]Contents ] [ [45]Next ]
C-Kermit 6.0 is documented in the book [46]Using C-Kermit, Second Edition, by Frank da Cruz and Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1 (1997), 622 pages. This remains the definitive C-Kermit documentation. Until the third edition is published (sorry, there is no firm timeframe for this), please also refer to:
[47]Supplement to Using C-Kermit, Second Edition, For C-Kermit 7.0
Thorough documentation of features new to version 7.0.
[48]Supplement to Using C-Kermit, Second Edition, For C-Kermit 8.0
Thorough documentation of features new to version 8.0.
1.2. Technical Support
[ [49]Top ] [ [50]Contents ] [ [51]Section Contents ] [ [52]Next ] [ [53]Previous ]
For information on how to get technical support, please visit:
[54]http://www.columbia.edu/kermit/support.html
1.3. The Year 2000
[ [55]Top ] [ [56]Contents ] [ [57]Section Contents ] [ [58]Next ] [ [59]Previous ]
The Unix version of C-Kermit, release 6.0 and later, is "Year 2000 compliant", but only if the underlying operating system is too. Contact your Unix operating system vendor to find out which operating system versions, patches, hardware, and/or updates are required. (Quite a few old Unixes are still in operation in the new millenium, but with their date set 28 years in the past so at least the non-year parts of the calendar are correct.)
As of C-Kermit 6.0 (6 September 1996), post-millenium file dates are recognized, transmitted, received, and reproduced correctly during the file transfer process in C-Kermit's File Attribute packets. If post-millenium dates are not processed correctly on the other end, file transfer still takes place, but the modification or creation date of the received file might be incorrect. The only exception would be if the "file collision update" feature is being used to prevent unnecessary transfer of files that have not changed since the last time a transfer took place; in this case, a file might be transferred unnecessarily, or it might not be transferred when it should have been. Correct operation of the update feature depends on both Kermit programs having the correct date and time.
Of secondary importance are the time stamps in the transaction and/or debug logs, and the date-related script programming constructs, such as \v(date), \v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time) and \v(ntime), insofar as they might be affected by the date. The \v(ndate) is a numeric-format date of the form yyyymmdd, suitable for both lexical and numeric comparison and sorting: e.g. 19970208 or 20011231. If the underlying operating system returns the correct date information, these variables will have the proper values. If not, then scripts that make decisions based on these variables might not operate correctly.
Most date-related code is based upon the C Library asctime() string, which always has a four-digit year. In Unix, the one bit of code in C-Kermit that is an exception to this rule is several calls to localtime(), which returns a pointer to a tm struct, in which the year is presumed to be expressed as "years since 1900". The code depends on this assumption. Any platforms that violate it will need special coding. As of this writing, no such platforms are known.
Command and script programming functions that deal with dates use C-Kermit specific code that always uses full years.
1.4. The Euro
[ [60]Top ] [ [61]Contents ] [ [62]Section Contents ] [ [63]Previous ]
C-Kermit 7.0 and later support Unicode (ISO 10646), ISO 8859-15 Latin Alphabet 9, PC Code Page 858, Windows Code Pages 1250 and 1251, and perhaps other character sets, that encode the Euro symbol, and can translate among them as long as no intermediate character-set is involved that does not include the Euro.
2. PREBUILT C-KERMIT BINARIES
[ [64]Top ] [ [65]Contents ] [ [66]Next ] [ [67]Previous ]
It is often dangerous to run a binary C-Kermit (or any other) program built on a different computer. Particularly if that computer had a different C compiler, libraries, operating system version, processor features, etc, and especially if the program was built with shared libraries, because as soon as you update the libraries on your system, they no longer match the ones referenced in the binary, and the binary might refuse to load when you run it, in which case you'll see error messages similar to:
Could not load program kermit
Member shr4.o not found or file not an archive
Could not load library libcurses.a[shr4.o]
Error was: No such file or directory
(These samples are from AIX.) To avoid this problem, we try to build C-Kermit with statically linked libraries whenever we can, but this is increasingly impossible as shared libraries become the norm.
It is often OK to run a binary built on an earlier OS version, but it is rarely possible (or safe) to run a binary built on a later one, for example to run a binary built under Solaris 8 on Solaris 2.6. Sometimes even the OS-or-library patch/ECO level makes a difference.
A particularly insidious problem occurs when a binary was built on a version of the OS that has patches from the vendor (e.g. to libraries); in many cases you won't be able to run such a binary on an unpatched version of the same platform.
When in doubt, build C-Kermit from the source code on the computer where it is to be run (if possible!). If not, ask us for a binary specific to your configuration. We might have one, and if we don't, we might be able to find somebody who will build one for you.
3. NOTES ON SPECIFIC UNIX VERSIONS
[ [68]Top ] [ [69]Contents ] [ [70]Next ] [ [71]Previous ]
SECTION CONTENTS
3.0. [72]C-KERMIT ON PC-BASED UNIXES
3.1. [73]C-KERMIT AND AIX
3.2. [74]C-KERMIT AND HP-UX
3.3. [75]C-KERMIT AND LINUX
3.4. [76]C-KERMIT AND NEXTSTEP
3.5. [77]C-KERMIT AND QNX
3.6. [78]C-KERMIT AND SCO
3.7. [79]C-KERMIT AND SOLARIS
3.8. [80]C-KERMIT AND SUNOS
3.9. [81]C-KERMIT AND ULTRIX
3.10. [82]C-KERMIT AND UNIXWARE
3.11. [83]C-KERMIT AND APOLLO SR10
3.12. [84]C-KERMIT AND TANDY XENIX 3.0
3.13. [85]C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
3.14. [86]C-KERMIT AND SGI IRIX
3.15. [87]C-KERMIT AND THE BEBOX
3.16. [88]C-KERMIT AND DG/UX
3.17. [89]C-KERMIT AND SEQUENT DYNIX
3.18. [90]C-KERMIT AND {FREE,OPEN,NET}BSD
3.19. [91]C-KERMIT AND MAC OS X
3.20. [92]C-KERMIT AND COHERENT
The following sections apply to specific Unix versions. Most of them contain references to FAQs (Frequently Asked Questions), but these tend to be ephemeral. For possibly more current information see:
[93]http://www.faqs.org
[94]http://aplawrence.com/Unixart/newtounix.html
One thread that runs through many of them, and implicitly perhaps through all, concerns the problems that occur when trying to dial out on a serial device that is (also) enabled for dialing in. The "solutions" to this problem are many, varied, diverse, and usually gross, involving configuring the device for bidirectional use. This is done in a highly OS-dependent and often obscure manner, and the effects (good or evil) are also highly dependent on the particular OS (and getty variety, etc). Many examples are given in the [95]OS-specific sections below.
An important point to keep in mind is that C-Kermit is a cross-platform, portable software program. It was not designed specifically and only for your particular Unix version, or for that matter, for Unix in particular at all. It also runs on VMS, AOS/VS, VOS, and other non-Unix platforms. All the Unix versions of C-Kermit share common i/o modules, with compile-time #ifdef constructions used to account for the differences among the many Unix products and releases. If you think that C-Kermit is behaving badly or missing something on your particular Unix version, you might be right -- we can't claim to be expert in hundreds of different OS / version / hardware / library combinations. If you're a programmer, take a look at the source code and [96]send us your suggested fixes or changes. Or else just [97]send us a report about what seems to be wrong and we'll see what we can do.
3.0. C-KERMIT ON PC-BASED UNIXES
[ [98]Top ] [ [99]Contents ] [ [100]Section Contents ] [ [101]Next ]
Also see: [102]http://www.pcunix.com/.
SECTION CONTENTS
3.0.1. [103]Interrupt Conflicts
3.0.2. [104]Windows-Specific Hardware
3.0.3. [105]Modems
3.0.4. [106]Character Sets
3.0.5. [107]Keyboard, Screen, and Mouse Access
3.0.6. [108]Laptops
3.0.1. Interrupt Conflicts
[ [109]Top ] [ [110]Contents ] [ [111]Section Contents ] [ [112]Next ]
PCs are not the best platform for real operating systems like Unix. The architecture suffers from numerous deficiencies, not the least of which is the stiflingly small number of hardware interrupts (either 7 or 15, many of which are preallocated). Thus adding devices, using multiple serial ports, etc, is always a challenge and often a nightmare. The free-for-all nature of the PC market and the lack of standards combined with the diversity of Unix OS versions make it difficult to find drivers for any particular device on any particular version of Unix.
Of special interest to Kermit users is the fact that there is no standard provision in the PC architecture for more than 2 communication (serial) ports. COM3 and COM4 (or higher) will not work unless you (a) find out the hardware address and interrupt for each, (b) find out how to provide your Unix version with this information, and (c) actually set up the configuration in the Unix startup files (or whatever other method is used). Watch out for interrupt conflicts, especially when using a serial mouse, and don't expect to be able to use more than two serial ports.
The techniques for resolving interrupt conflicts are different for each operating system (Linux, NetBSD, etc). In general, there is a configuration file somewhere that lists COM ports, something like
- this
com0 at isa? port 0x3f8 irq 4 # DOS COM1 com1 at isa? port 0x2f8 irq 3 # DOS COM2
The address and IRQ values in this file must agree with the values in the PC BIOS and with the ports themselves, and there must not be more than one device with the same interrupt. Unfortunately, due to the small number of available interrupts, installing new devices on a PC almost always creates a conflict. Here is a typical tale from a Linux user (Fred Smith) about installing a third serial port:
...problems can come from a number of causes. The one I fought with
for some time, and finally conquered, was that my modem is on an
add-in serial port, cua3/IRQ5. By default IRQ5 has a very low
priority, and does not get enough service in times when the system
is busy to prevent losing data. This in turn causes many resends.
There are two 'fixes' that I know of, one is to relax hard disk
interrupt hogging by using the correct parameter to hdparm, but I
don't like that one because the hdparm man page indicates it is
risky to use. The other one, the one I used, was to get 'irqtune'
and use it to give IRQ5 the highest priority instead of nearly the
lowest. Completely cured the problem.
Here's another one from a newsgroup posting:
After much hair pulling, I've discovered why my serial port won't
work. Apparently my [PC] has three serial devices (two comm ports
and an IR port), of which only two at a time can be active. I
looked in the BIOS setup and noticed that the IR port was
activated, but didn't realize at the time that this meant that COM2
was thereby de-activated. I turned off the IR port and now the
serial port works as advertised.
3.0.2. Windows-Specific Hardware
[ [113]Top ] [ [114]Contents ] [ [115]Section Contents ] [ [116]Next ] [ [117]Previous ]
To complicate matters, the PC platform is becoming increasingly and inexorably Windows-oriented. More and more add-on devices are "Windows only" -- meaning they are incomplete and rely on proprietary Windows-based software drivers to do the jobs that you would expect the device itself to do. PCMCIA, PCI, or "Plug-n-Play" devices are rarely supported on PC-based Unix versions such as SCO; Winmodems, Winprinters, and the like are not supported on any Unix variety (with [118]a few exceptions). The self-proclaimed Microsoft PC 97 (or later) standard only makes matters worse since its only purpose to ensure that PCs are "optimized to run Windows 95 and Windows NT 4.0 and future versions of these operating systems".
With the exception noted (the Lucent modem, perhaps a handful of others by the time you read this), drivers for "Win" devices are available only for Windows, since the Windows market dwarfs that of any particular Unix brand, and for that matter all Unixes (or for that matter, all non-Windows operating systems) combined. If your version of Unix (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular device, then C-Kermit can't use it either. C-Kermit, like any Unix application, must access all devices through drivers and not directly because Unix is a real operating system.
Don't waste time thinking that you, or anybody else, could write a Linux (or other Unix) driver for a Winmodem or other "Win" device. First of all, these devices generally require realtime control, but since Unix is a true multitasking operating system, realtime device control is not possible outside the kernel. Second, the specifications for these devices are secret and proprietary, and each one (and each version of each one) is potentially different. Third, a Winmodem driver would be enormously complex; it would take years to write and debug, by which time it would be obsolete.
A more recent generation of PCs (circa 1999-2000) is marketed as "Legacy Free". One can only speculate what that could mean. Most likely it means it will ONLY run the very latest versions of Windows, and is made exclusively of Winmodems, Winprinters, Winmemory, and Win-CPU-fans (Legacy Free is a concept [119]pioneered by Microsoft).
Before you buy a new PC or add-on equipment, especially serial ports, internal modems, or printers, make sure they are compatible with your version of Unix. This is becoming an ever-greater challenge; only a huge company like Microsoft can afford to be constantly cranking out and/or verifying drivers for the thousands of video boards, sound cards, network adapters, SCSI adapters, buses, etc, that spew forth in an uncontrolled manner from all corners of the world on a daily basis. With very few exceptions, makers of PCs assemble the various components and then verify them only with Windows, which they must do since they are, no doubt, preloading the PC with Windows. To find a modern PC that is capable of running a variety of non-Windows operating systems (e.g. Linux, SCO OpenServer, Unixware, and Solaris) is a formidable challenge requiring careful study of each vendor's "compatibility lists" and precise attention to exact component model numbers and revision levels.
3.0.3. Modems
[ [120]Top ] [ [121]Contents ] [ [122]Section Contents ] [ [123]Next ] [ [124]Previous ]
External modems are recommended:
- They don't need any special drivers.
- You can use the lights and speaker to troubleshoot dialing.
- You can share them among all types of computers.
- You can easily turn them off and on when power-cycling seems warranted.
- They are more likely to have manuals.
Internal PC modems (even when they are not Winmodems, which is increasingly unlikely in new PCs) are always trouble, especially in Unix. Even when they work for dialing out, they might not work for dialing in, etc. Problems that occur when using an internal modem can almost always be eliminated by switching to an external one. Even when an internal modem is not a Winmodem or Plug-n-Play, it is often a no-name model of unknown quality -- not the sort of thing you want sitting directly on your computer's bus. (Even if it does not cause hardware problems, it probably came without a command list, so no Unix software will know how to control it.) For more about Unix compatible modems, see:
[125]http://www.idir.net/~gromitkc/winmodem.html
Remember that PCs, even now -- more than two decades after they were first introduced -- are not (in general) capable of supporting more than 2 serial devices. Here's a short success story from a recent newsgroup posting: "I have a Diamond SupraSonic II dual modem in my machine. What I had to end up doing is buying a PS/2 mouse and port and install it. Had to get rid of my serial mouse. I also had to disable PnP in my computer bios. I was having IRQ conflicts between my serial mouse and 'com 3'. Both modems work fine for me. My first modem is ttyS0 and my second is ttyS1." Special third-party multiport boards such as [126]DigiBoard are available for certain Unix platforms (typically SCO, maybe Linux) that come with special platform-specific drivers.
3.0.4. Character Sets
[ [127]Top ] [ [128]Contents ] [ [129]Section Contents ] [ [130]Next ] [ [131]Previous ]
PCs generally have PC code pages such as CP437 or CP850, and these are often used by PC-based Unix operating systems, particularly on the console. These are supported directly by C-Kermit's SET FILE CHARACTER-SET and SET TERMINAL CHARACTER-SET commands. Some PC-based Unix versions, such as recent Red Hat Linux releases, might also support Microsoft Windows code pages such as CP1252, or even Latin Alphabet 1 itself (perhaps displayed with CP437 glyphs). (And work is in progress to support Unicode UTF8 in Linux.)
Certain Windows code pages are not supported directly by C-Kermit, but since they are ISO Latin Alphabets with nonstandard "extensions" in the C1 control range, you can substitute the corresponding Latin alphabet (or other character set) in any C-Kermit character-set related commands:
Windows Code Page Substitution
CP 1004 Latin-1 CP 1051 HP Roman-8
Other Windows code pages are mostly (or totally) incompatible with their Latin Alphabet counterparts (e.g. CP1250 and Latin-2), and several of these are already supported by C-Kermit 7.0 and later (1250, 1251, and 1252).
3.0.5. Keyboard, Screen, and Mouse Access
[ [132]Top ] [ [133]Contents ] [ [134]Section Contents ] [ [135]Next ] [ [136]Previous ]
Finally, note that as a real operating system, Unix (unlike Windows) does not provide the intimate connection to the PC keyboard, screen, and mouse that you might expect. Unix applications can not "see" the keyboard, and therefore can not be programmed to understand F-keys, Editing keys, Arrow keys, Alt-key combinations, and the like. This is
- because
-
- Unix is a portable operating system, not only for PCs;
- Unix sessions can come from anywhere, not just the PC's own keyboard and screen; and:
- even though it might be possible for an application that actually
is running on the PC's keyboard and screen to access these devices
directly, there are no APIs (outside of X) for this.
3.0.6. Laptops
[ [137]Top ] [ [138]Contents ] [ [139]Section Contents ] [ [140]Previous ]
(To be filled in . . .)
3.1. C-KERMIT AND AIX
[ [141]Top ] [ [142]Contents ] [ [143]Section Contents ] [ [144]Next ] [ [145]Previous ]
SECTION CONTENTS
3.1.1. [146]AIX: General
3.1.2. [147]AIX: Network Connections
3.1.3. [148]AIX: Serial Connections
3.1.4. [149]AIX: File Transfer
3.1.5. [150]AIX: Xterm Key Map
For additional information see:
- [151]http://www.emerson.emory.edu/services/aix-faq/
- [152]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
- [153]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/to p.html
- [154]http://aixpdslib.seas.ucla.edu/
- [155]http://www.rootvg.net (AIX history)
- [156]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
- [157]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/ aix
and/or read the [158]comp.unix.aix newsgroup.
3.1.1. AIX: General
[ [159]Top ] [ [160]Contents ] [ [161]Section Contents ] [ [162]Next ]
About AIX version numbers: "uname -a" tells the two-digit version number, such as 3.2 or 4.1. The three-digit form can be seen with the "oslevel" command (this information is unavailable at the API level and is reportedly obtained by scanning the installed patch list). Supposedly all three-digit versions within the same two-digit version (e.g. 4.3.1, 4.3.2) are binary compatible; i.e. a binary built on any one of them should run on all others, but who knows. Most AIX advocates tell you that any AIX binary will run on any AIX version greater than or equal to the one under which it was built, but experience with C-Kermit suggests otherwise. It is always best to run a binary built under your exact same AIX version, down to the third decimal place, if possible. Ideally, build it from source code yourself. Yes, this advice would be easier to follow if AIX came with a C compiler.
3.1.2. AIX: Network Connections
[ [163]Top ] [ [164]Contents ] [ [165]Section Contents ] [ [166]Next ] [ [167]Previous ]
File transfers into AIX 4.2 or 4.3 through the AIX Telnet or Rlogin server have been observed to fail (or accumulate huge numbers of correctable errors, or even disconnect the session), when exactly the same kind of transfers into AIX 4.1 work without incident, as do such transfers into all non-AIX platforms on the same kind of connections (with a few exceptions noted elsewhere in this document). AIX 4.3.3 seems to be particularly fragile in this regard; the weakness seems to be in its pseudoterminal (pty) driver. High-speed streaming transfers work perfectly, however, if the AIX Telnet server and pty driver are removed from the picture; e.g, by using "set host * 3000" on AIX.
The problem can be completely cured by replacing the IBM Telnet server with [168]MIT's Kerberos Telnet server -- even if you don't actually use the Kerberos part. Diagnosis: AIX pseudoterminals (which are controlled by the Telnet server to give you a login terminal for your session) have quirks that not even IBM knows about. The situation with AIX 5.x is not known, but if it has the same problem, the same cure is available.
Meanwhile, the only remedy when going through the IBM Telnet server is to cut back on Kermit's performance settings until you find a combination that works:
- SET STREAMING OFF
- SET WINDOW-SIZE small-number
- SET { SEND, RECEIVE } PACKET-LENGTH small-number
- SET PREFIXING { CAUTIOUS, ALL }
In some cases, severe cutbacks are required, e.g. those implied by the ROBUST command. Also be sure that the AIX C-Kermit on the remote end has "set flow none" (which is the default). NOTE: Maybe this one can also be addressed by starting AIX telnetd with the "-a" option. The situation with SSH connections is not known, but almost certainly the same.
When these problems occur, the system error log contains:
LABEL: TTY_TTYHOG IDENTIFIER: 0873CF9F Type: TEMP
Resource Name: pts/1
Description
TTYHOG OVER-RUN
Failure Causes
EXCESSIVE LOAD ON PROCESSOR
Recommended Actions
REDUCE SYSTEM LOAD.
REDUCE SERIAL PORT BAUD RATE
Before leaving the topic of AIX pseudoterminals, it is very likely that Kermit's PTY and SSH commands do not work well either, for the same reason that Telnet connections into AIX don't work well. A brief test with "pty rlogin somehost" got a perfectly usable terminal (CONNECT) session, but file-transfer problems like those just described.
Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports does not work unless the port number is in the /etc/services file; it's not clear from the report whether this is a problem with AIX Telnet (in which case it would not affect Kermit), or with the sockets library (in which case it would). The purported fix is IBM APAR IX61523.
C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to another won't work right unless you set your local terminal type to something other than AIXTERM. When your terminal type is AIXTERM, AIX TELNET sends two escapes whenever you type one, and the AIX telnet server swallows one of them. This has something to do with the "hft" device. This behavior seems to be removed in AIX 3.2 and later.
3.1.3. AIX: Serial Connections
[ [169]Top ] [ [170]Contents ] [ [171]Section Contents ] [ [172]Next ] [ [173]Previous ]
In AIX 3, 4, or 5, C-Kermit won't be able to "set line /dev/tty0" (or any other dialout device) if you haven't installed "cu" or "uucp" on your system, because installing these is what creates the UUCP lockfile directory. If SET LINE commands always result in "Sorry, access to lock denied", even when C-Kermit has been given the same owner, group, and permissions as cu:
-r-sr-xr-x 1 uucp uucp 67216 Jul 27 1999 cu
and even when you run it as root, then you must go back and install "cu" from your AIX installation media.
According to IBM's "From Strength to Strength" document (21 April 1998), in AIX 4.2 and later "Async supports speeds on native serial ports up to 115.2kbps". However, no API is documented to achieve serial speeds higher than 38400 bps. Apparently the way to do this -- which might or might not work only on the IBM 128-port multiplexer --
- is
cxma-stty fastbaud /dev/tty0
which, according to "man cxma-stty":
fastbaud Alters the baud rate table, so 50 baud becomes 57600 baud.
-fastbaud Restores the baud rate table, so 57600 baud becomes 50
baud.
Presumably (but not certainly) this extrapolates to 110 "baud" becomes 76800 bps, and 150 becomes 115200 bps. So to use high serial speeds in AIX 4.2 or 4.3, the trick would be to give the "cxma-stty fastbaud" command for the desired tty device before starting Kermit, and then use "set speed 50", "set speed 110", or "set speed 150" to select 56700, 76800, or 115200 bps. It is not known whether cxma-stty requires privilege.
According to one report, "Further investigation with IBM seems to indicate that the only hardware capable of doing this is the 128-port multiplexor with one (or more) of the 16 port breakout cables (Enhanced Remote Async Node 16-Port EIA-232). We are looking at about CDN$4,000 in hardware just to hang a 56kb modem on there. Of course, we can then hang 15 more, if we want. This hardware combo is described to be good to 230.4kbps."
Another report says (quote from AIX newsgroup, March 1999):
The machine type and the adapter determine the speed that one can
actually run at. The older microchannel machines have much slower
crystal frequencies and may not go beyond 76,800. A feature put
into AIX 421 allows one to key in non-POSIX baud rates and if the
uart can support that speed, it will get set. this applies also to
43p's and beyond. 115200 is the max for the 43P's native serial
port. As crytal frequencies continue to increase, the built-in
serial ports speeds will improve. To use 'uucp' or 'ate' at the
higher baud rates, configure the port for the desired speed, but
set the speed of uucp or ate to 50. Any non-POSIX speeds set in the
ttys configuration will the be used. In the case of the 128-port
adapters or the ISA 8-port or PCI 8-port adapter, there are only a
few higher baud rates.
- Change the port to enable high baud rates:
+ B50 for 57600 + B75 for 76800 + B110 for 115200 + B200 for 230000
- chdev -l ttyX -a fastbaud=enable
+ For the 128 ports original style rans, only 57600 bps is supported. + For the new enhanced RANs, up to 230Kbps is supported.
In AIX 2.2.1 on the RT PC with the 8-port multiplexer, SET SPEED 38400 gives 9600 bps, but SET SPEED 19200 gives 19200 (on the built-in S1 port).
Note that some RS/6000s (e.g. the IBM PowerServer 320) have nonstandard rectangular 10-pin serial ports; the DB-25 connector is NOT a serial port; it is a parallel printer port. IBM cables are required for the serial ports, (The IBM RT PC also had rectangular serial ports -- perhaps the same as these, perhaps different.)
If you dial in to AIX through a modem that is connected directly to an AIX port (e.g. on the 128-port multiplexer) and find that data is lost, especially when uploading files to the AIX system (and system error logs report buffer overruns on the port):
- Make sure the port and modem are BOTH configured for hardware (RTS/CTS) flow control. The port is configured somewhere in the system configuration, outside of Kermit.
- 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).
- Fixes for bugs in the original AIX 4.2 tty (serial i/o) support
and other AIX bugs are available from IBM at:
[174]http://service.software.ibm.com/rs6000/
Downloads -> Software Fixes -> Download FixDist gets an application for looking up known problems.
Many problems reported with bidirectional terminal lines on AIX 3.2.x on the RS/6000. Workaround: don't use bidirectional terminal lines, or write a shell-script wrapper for Kermit that turns getty off on the line before starting Kermit, or before Kermit attempts to do the SET LINE. (But note: These problems MIGHT be fixed in C-Kermit 6.0 and later.) The commands for turning getty off and on (respectively) are /usr/sbin/pdisable and /usr/sbin/penable.
3.1.4. AIX: File Transfer
[ [175]Top ] [ [176]Contents ] [ [177]Section Contents ] [ [178]Next ] [ [179]Previous ]
Evidently AIX 4.3 (I don't know about earlier versions) does not allow open files to be overwritten. This can cause Kermit transfers to fail when FILE COLLISION is OVERWRITE, where they might work on other Unix varieties or earlier AIX versions.
Transfer of binary -- and maybe even text -- files can fail in AIX if the AIX terminal has particular port can have character-set translation done for it by the tty driver. The following advice from a knowledgeable AIX user:
[This feature] has to be checked (and set/cleared) with a separate
command, unfortunately stty doesn't handle this. To check:
$ setmaps
input map: none installed
output map: none installed
If it says anything other than "none installed" for either one, it
is likely to cause a problem with kermit. To get rid of installed
maps:
$ setmaps -t NOMAP
However, I seem to recall that with some versions of AIX before
3.2.5, only root could change the setting. I'm not sure what
versions - it might have only been under AIX 3.1 that this was
true. At least with AIX 3.2.5 an ordinary user can set or clear the
maps.
On the same problem, another knowledgeable AIX user says:
The way to get information on the NLS mapping under AIX (3.2.5
anyway) is as follows. From the command line type:
lsattr -l tty# -a imap -a omap -E -H
Replace the tty number for the number sign above. This will give a
human readable output of the settings that looks like this;
# lsattr -l tty2 -a imap -a omap -E -H attribute value description user_settable
imap none INPUT map file True
omap none OUTPUT map file True
If you change the -H to a -O, you get output that can easily be
processed by another program or a shell script, for example:
# lsattr -l tty2 -a imap -a omap -E -O
#imap:omap
none:none
To change the settings from the command line, the chdev command is
used with the following syntax.
chdev -l tty# -a imap='none' -a omap='none'
Again substituting the appropriate tty port number for the number
sign, "none" being the value we want for C-Kermit. Of course, the
above can also be changed by using the SMIT utility and selecting
devices - tty. (...end quote)
______________________________________________________________________
3.1.5. AIX: Xterm Key Map
[ [180]Top ] [ [181]Contents ] [ [182]Section Contents ] [ [183]Previous ]
Here is a sample configuration for setting up an xterm keyboard for VT220 or higher terminal emulation on AIX, courtesy of Bruce Momjian, Drexel Hill, PA. Xterm can be started like this:
xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220 \
-title vt220 -tn xterm-220 "$@" &
XTerm*VT100.Translations: #override \n\
<Key>Home: string(0x1b) string("[3~") \n \
<Key>End: string(0x1b) string("[4~") \n
vt220*VT100.Translations: #override \n\
Shift <Key>F1: string("[23~") \n \
Shift <Key>F2: string("[24~") \n \
Shift <Key>F3: string("[25~") \n \
Shift <Key>F4: string("[26~") \n \
Shift <Key>F5: string("[K~") \n \
Shift <Key>F6: string("[31~") \n \
Shift <Key>F7: string("[31~") \n \
Shift <Key>F8: string("[32~") \n \
Shift <Key>F9: string("[33~") \n \
Shift <Key>F10: string("[34~") \n \
Shift <Key>F11: string("[28~") \n \
Shift <Key>F12: string("[29~") \n \
<Key>Print: string(0x1b) string("[32~") \n\
<Key>Cancel: string(0x1b) string("[33~") \n\
<Key>Pause: string(0x1b) string("[34~") \n\
<Key>Insert: string(0x1b) string("[2~") \n\
<Key>Delete: string(0x1b) string("[3~") \n\
<Key>Home: string(0x1b) string("[1~") \n\
<Key>End: string(0x1b) string("[4~") \n\
<Key>Prior: string(0x1b) string("[5~") \n\
<Key>Next: string(0x1b) string("[6~") \n\
<Key>BackSpace: string(0x7f) \n\
<Key>Num_Lock: string(0x1b) string("OP") \n\
<Key>KP_Divide: string(0x1b) string("Ol") \n\
<Key>KP_Multiply: string(0x1b) string("Om") \n\
<Key>KP_Subtract: string(0x1b) string("OS") \n\
<Key>KP_Add: string(0x1b) string("OM") \n\
<Key>KP_Enter: string(0x1b) string("OM") \n\
<Key>KP_Decimal: string(0x1b) string("On") \n\
<Key>KP_0: string(0x1b) string("Op") \n\
<Key>KP_1: string(0x1b) string("Oq") \n\
<Key>KP_2: string(0x1b) string("Or") \n\
<Key>KP_3: string(0x1b) string("Os") \n\
<Key>KP_4: string(0x1b) string("Ot") \n\
<Key>KP_5: string(0x1b) string("Ou") \n\
<Key>KP_6: string(0x1b) string("Ov") \n\
<Key>KP_7: string(0x1b) string("Ow") \n\
<Key>KP_8: string(0x1b) string("Ox") \n\
<Key>KP_9: string(0x1b) string("Oy") \n
! <Key>Up: string(0x1b) string("[A") \n\
! <Key>Down: string(0x1b) string("[B") \n\
! <Key>Right: string(0x1b) string("[C") \n\
! <Key>Left: string(0x1b) string("[D") \n\
visualBell: true
saveLines: 1000
cursesemul: true
scrollKey: true
*scrollBar: true
3.2. C-KERMIT AND HP-UX
[ [184]Top ] [ [185]Contents ] [ [186]Section Contents ] [ [187]Next ] [ [188]Previous ]
SECTION CONTENTS
3.2.0. [189]Common Problems
3.2.1. [190]Building C-Kermit on HP-UX
3.2.2. [191]File Transfer
3.2.3. [192]Dialing Out and UUCP Lockfiles in HP-UX
3.2.4. [193]Notes on Specific HP-UX Releases
3.2.5. [194]HP-UX and X.25
REFERENCES
For further information, read the [195]comp.sys.hp.hpux newsgroup.
C-Kermit is included as part of the HP-UX operating system by contract between Hewlett Packard and Columbia University for HP-UX 10.00 and later. Each level of HP-UX includes a freshly built C-Kermit binary in /bin/kermit, which should work correctly. Binaries built for regular HP-UX may be used on Trusted HP-UX and vice-versa, except for use as IKSD because of the different authentication methods.
Note that HP does not update C-Kermit versions for any but its most current HP-UX release. So, for example, HP-UX 10.20 has C-Kermit 6.0; 11.00 has C-Kermit 7.0, and 11.22 has 8.0. Of course, as with all software, older Kermit versions have bugs (such as buffer overflow vulnerabilities) that are fixed in later versions. From time to time, HP discovers one of these (long-ago fixed) bugs and issues a security alert for the older OS's, recommending some draconian measure to avoid the problem. The true fix in each situation is to install the current release of C-Kermit.
3.2.0. Common Problems
[ [196]Top ] [ [197]Contents ] [ [198]Section Contents ] [ [199]Next ]
Some HP workstations have a BREAK/RESET key. If you hit this key while C-Kermit is running, it might kill or suspend the C-Kermit process. C-Kermit arms itself against these signals, but evidently the BREAK/RESET key is -- at least in some circumstances, on certain HP-UX versions -- too powerful to be caught. (Some report that the first BREAK/RESET shows up as SIGINT and is caught by C-Kermit's former SIGINT handler even when SIGINT is currently set to SIG_IGN; the second kills Kermit; other reports suggest the first BREAK/RESET sends a SIGTSTP (suspend signal) to Kermit, which it catches and suspends itself. You can tell C-Kermit to ignore suspend signals with SET SUSPEND OFF. You can tell C-Kermit to ignore SIGINT with SET COMMAND INTERRUPTION OFF. It is not known whether these commands also grant immunity to the BREAK/RESET key (one report states that with SET SUSPEND OFF, the BREAK/RESET key is ignored the first four times, but kills Kermit the 5th time). In any case:
- If this key is mapped to SIGINT or SIGTSTP, C-Kermit catches or ignores it, depending on which mode (CONNECT, command, etc) Kermit is in.
- If it causes HP-UX to kill C-Kermit, there is nothing C-Kermit can do to prevent it.
When HP-UX is on the remote end of the connection, it is essential that HP-UX C-Kermit be configured for Xon/Xoff flow control (this is the default, but in case you change it and then experience file-transfer failures, this is a likely reason).
3.2.1. Building C-Kermit on HP-UX
[ [200]Top ] [ [201]Contents ] [ [202]Section Contents ] [ [203]Next ] [ [204]Previous ]
This section applies mainly to old (pre-10.20) HP-UX version on
old, slow, and/or memory-constrained hardware.
During the C-Kermit 6.0 Beta cycle, something happened to ckcpro.w (or, more precisely, the ckcpro.c file that is generated from it) which causes HP optimizing compilers under HP-UX versions 7.0 and 8.0 (apparently on all platforms) as well as under HP-UX 9.0 on Motorola platforms only, to blow up. In versions 7.0 and 8.0 the problem has spread to other modules.
The symptoms vary from the system grinding to a halt, to the compiler crashing, to the compilation of the ckcpro.c module taking very long periods of time, like 9 hours. This problem is handled by compiling the modules that tickle it without optimization; the new C-Kermit makefile takes care of this, and shows how to do it in case the same thing begins happening with other modules.
On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment size), seems to be important. On Motorola systems, it is 16MB by default, whereas on RISC systems the default is much bigger. Increasing maxdsiz to about 80MB seems to make the problem go away, but only if the system also has a lot of physical memory -- otherwise it swaps itself to death.
The optimizing compiler might complain about "some optimizations skipped" on certain modules, due to lack of space available to the optimizer. You can increase the space (the incantation depends on the particular compiler version -- see the [205]makefile), but doing so tends to make the compilations take a much longer time. For example, the "hpux0100o+" makefile target adds the "+Onolimit" compiler flag, and about an hour to the compile time on an HP-9000/730. But it does produce an executable that is about 10K smaller :-)
In the makefile, all HP-UX entries automatically skip optimization of problematic modules.
3.2.2. File Transfer
[ [206]Top ] [ [207]Contents ] [ [208]Section Contents ] [ [209]Next ] [ [210]Previous ]
Telnet connections into HP-UX versions up to and including 11.11 (and possibly 11.20) tend not to lend themselves to file transfer due to limitations, restrictions, and/or bugs in the HP-UX Telnet server and/or pseudoterminal (pty) driver.
In C-Kermit 6.0 (1996) an unexpected slowness was noted when transferring files over local Ethernet connections when an HP-UX system (9.05 or 10.00) was on the remote end. The following experiment was conducted to determine the cause. C-Kermit 6.0 was used; the situation is slightly better using C-Kermit 7.0's streaming feature and HP-UX 10.20 on the far end.
The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20), both on the same local 10Mbps Ethernet, packet length 4096, parity none, control prefixing "cautious", using only local disks on each machine -- no NFS. In the C-Kermit 6.0 (ACK/NAK) case, the window size was 20; in the streaming case there is no window size (i.e. it is infinite). The test file was C-Kermit executable, transferred in binary mode. Conditions were relatively poor: the Sun and the local net heavily loaded; the HP system is old, slow, and memory-constrained.
C-Kermit 6.0... C-Kermit 7.0...
Local Remote ACK/NAK........ Streaming......
Client Server Send Receive Send Receive
Sun HP 36 18 64 18
HP HP 25 15 37 16
HP Sun 77 83 118 92
Sun Sun 60 60 153 158
So whenever HP is the remote we have poor performance. Why?
- Changing file display to CRT has no effect (so it's not the curses library on the client side).
- Changing TCP RECV-BUFFER or SEND-BUFFER has little effect.
- Telling the client to make a binary-mode connection (SET TELNET BINARY REQUESTED, which successfully negotiates a binary connection) has no effect on throughput.
BUT... If I start HP-UX C-Kermit as a TCP service:
set host * 3000
server
and then from the client "set host xxx 3000", I get:
C-Kermit 6.0... C-Kermit 7.0...
Local Remote ACK/NAK........ Streaming......
Client Server Send Receive Send Receive
Sun HP 77 67 106 139
HP HP 50 50 64 62
HP Sun 57 85 155 105
Sun Sun 57 50 321 314
Therefore the HP-UX telnet server or pty driver seems to be adding more overhead than the SunOS one, and most others. When going through this type of connection (a remote telnet server) there is little Kermit can do improve matters, since the telnet server and pty driver are between the two Kermits, and neither Kermit program can have any influence over them (except putting the Telnet connection in binary mode, but that doesn't help).
(The numbers for the HP-HP transfers are lower than the others since both Kermit processes are running on the same slow 33MHz CPU.)
Matters seem to have deteriorated in HP-UX 11. Now file transfers over Telnet connections fail completely, rather than just being slow. In the following trial, a Telnet connection was made from Kermit 95 to HP-UX 11.11 on an HP-9000/785/B2000 over local 10Mbps Ethernet running C-Kermit 8.00 in server mode (under the HP-UX Telnet server):
Text........ Binary......
Stream Pktlen GET SEND GET SEND
On 4000 Fail Fail Fail Fail
Off 4000 Fail Fail Fail Fail
Off 2000 OK Fail OK Fail
On 2000 OK Fail OK Fail
On 3000 Fail Fail Fail Fail
On 2500 Fail Fail Fail Fail
On 2047 OK Fail OK Fail
On 2045 OK Fail OK Fail
Off 500 OK OK OK OK
On 500 OK Fail OK Fail
On 240 OK Fail OK Fail
As you can see, downloads are problematic unless the receiver's Kermit packet length is 2045 or less, but uploads work only with streaming disabled and the packet length restricted to 500. To force file transfers to work on this connection, the desktop Kermit must be told
- to
set streaming off
set receive packet-length 2000
set send packet-length 500
However, if a connection is made between the same two programs on the same two computers over the same network, but this time a direct socket-to-socket connection bypassing the HP-UX Telnet server and pty driver (tell HP-UX C-Kermit to "set host /server * 3000 /raw"; tell desktop client program to "set host blah 3000 /raw"), everything works perfectly with the default Kermit settings (streaming, 4K packets, liberal control-character unprefixing, 8-bit transparency, etc):
Text........ Binary......
Stream Pktlen GET SEND GET SEND
On 4000 OK OK OK OK
And in this case, transfer rates were approximately 900,000 cps. To verify that the behavior reported here is not caused by the new Kermit release, the same experiment was performed on a Telnet connection from the same PC over the same network to the old 715/33 running HP-UX 10.20 and C-Kermit 8.00. Text and binary uploads and downloads worked perfectly (albeit slowly) with all the default settings -- streaming, 4K packets, etc.
3.2.3. Dialing Out and UUCP Lockfiles in HP-UX
[ [211]Top ] [ [212]Contents ] [ [213]Section Contents ] [ [214]Next ] [ [215]Previous ]
HP workstations do not come with dialout devices configured; you have to do it yourself (as root). First look in /dev to see what's there; for example in HP-UX 10.00 or later:
ls -l /dev/cua
ls -l /dev/tty
If you find a tty0p0 device but no cua0p0, you'll need to creat one if you want to dial out; the tty0p0 does not work for dialing out. It's easy: start SAM; in the main Sam window, double-click on Peripheral Device, then in the Peripheral Devices window, double-click on Terminals and Modems. In the Terminals and Modems dialog, click on Actions, then choose "Add modem" and fill in the blanks. For example: Port number 0, speed 57600 (higher speeds tend not to work reliably), "Use device for calling out", do NOT "Receive incoming calls" (unless you know what you are doing), leave "CCITT modem" unchecked unless you really have one, and do select "Use hardware flow control (RTS/CTS)". Then click OK. This creates cua0p0 as well as cul0p0 and ttyd0p0
If the following sequence:
set line /dev/cua0p0 ; or other device set speed 115200 ; or other normal speed
produces the message "?Unsupported line speed". This means either that the port is not configured for dialout (go into SAM as described above and make sure "Use device for calling out" is selected), or else that speed you have given (such as 460800) is supported by the operating system but not by the physical device (in which case, use a lower speed like 57600).
In HP-UX 9.0, serial device names began to change. The older names looked like "/dev/cua00", "/dev/tty01", etc (sometimes with only one digit). The newer names have two digits with the letter "p" in between. HP-UX 8.xx and earlier have the older form, HP-UX 10.00 and later have the newer form. HP-UX 9.xx has the newer form on Series 800 machines, and the older form on other hardware models. The situation is summarized in the following table (the Convio 10.0 column applies to HP-UX 10 and 11).
Converged HP-UX Serial I/O Filenames : TTY Mux Naming
General meaning Old Form S800 9.0 Convio 10.0
tty* hardwired ports tty<YY> tty<X>p<Y> tty<D>p<p>
diag:mux<X> diag:mux<D>
---------------------------------------------------------------------
ttyd* dial-in modems ttyd<YY> ttyd<X>p<Y> ttyd<D>p<p>
diag:ttyd<X>p<Y> diag:ttyd<D>p<p>
---------------------------------------------------------------------
cua* auto-dial out cua<YY> cua<X>p<Y> cua<D>p<p>
diag:cua<X>p<Y>
---------------------------------------------------------------------
cul* dial-out cul<YY> cul<X>p<Y> cul<D>p<p>
diag:cul<X>p<Y>
<X>= LU (Logical Unit) <D>= Devspec (decimal card instance) <Y> or <YY> = Port <p>= Port
For dialing out, you should use the cua or cul devices. When C-Kermit's CARRIER setting is AUTO or ON, C-Kermit should pop back to its prompt automatically if the carrier signal drops, e.g. when you log out from the remote computer or service. If you use the tty<D>p<d> (e.g. tty0p0) device, the carrier signal should be ignored. The tty<D>p<d> device should be used for direct connections where the carrier signal does not follow RS-232 conventions (use the cul device for hardwired connections through a true null modem). Do not use the ttyd<D>p<d> device for dialing out.
Kermit's access to serial devices is controlled by "UUCP lockfiles", which are intended to prevent different users using different software programs (Kermit, cu, etc, and UUCP itself) from accessing the same serial device at the same time. When a device is in use by a particular user, a file with a special name is created in:
/var/spool/locks (HP-UX 10.00 and later) /usr/spool/uucp (HP-UX 9.xx and earlier)
The file's name indicates the device that is in use, and its contents indicates the process ID (pid) of the process that is using the device. Since serial devices and the locks directory are not both publicly readable and writable, Kermit and other communication software must be installed setuid to the owner (bin) of the serial device and setgid to the group (daemon) of the /var/spool/locks directory. Kermit's setuid and setgid privileges are enabled only when opening the device and accessing the lockfiles.
Let's say "unit" means a string of decimal digits (the interface instance number) followed (in HP-UX 10.00 and later) by the letter "p" (lowercase), followed by another string of decimal digits (the port number on the interface), e.g.:
"0p0", "0p1", "1p0", etc (HP-UX 10.00 and later) "0p0", "0p1", "1p0", etc (HP-UX 9.xx on Series 800)
"00", "01", "10", "0", etc (HP-UX 9.xx not on Series 800) "00", "01", "10", "0", etc (HP-UX 8.xx and earlier)
Then a normal serial device (driver) name consists of a prefix ("tty", "ttyd", "cua", "cul", or possibly "cuad" or "culd") followed by a unit, e.g. "cua0p0". Kermit's treatment of UUCP lockfiles is as close as possible to that of the HP-UX "cu" program. Here is a table of the lockfiles that Kermit creates for unit 0p0:
Selection Lockfile 1 Lockfile 2
/dev/tty0p0 LCK..tty0p0 (none)
* /dev/ttyd0p0 LCK..ttyd0p0 (none)
/dev/cua0p0 LCK..cua0p0 LCK..ttyd0p0
/dev/cul0p0 LCK..cul0p0 LCK..ttyd0p0
/dev/cuad0p0 LCK..cuad0p0 LCK..ttyd0p0
/dev/culd0p0 LCK..culd0p0 LCK..ttyd0p0
<other> LCK..<other> (none)
(* = Dialin device, should not be used.)
In other words, if the device name begins with "cu", a second lockfile for the "ttyd" device, same unit, is created, which should prevent dialin access on that device.
The <other> case allows for symbolic links, etc, but of course it is not foolproof since we have no way of telling which device is really being used.
When C-Kermit tries to open a dialout device whose name ends with a "unit", it searches the lockfile directory for all possible names for the same unit. For example, if user selects /dev/cul2p3, Kermit looks for lockfiles named:
LCK..tty2p3
LCK..ttyd2p3
LCK..cua2p3
LCK..cul2p3
LCK..cuad2p3
LCK..culd2p3
If any of these files are found, Kermit opens them to find out the ID (pid) of the process that created them; if the pid is still valid, the process is still active, and so the SET LINE command fails and the user is informed of the pid so s/he can use "ps" to find out who is using the device.
If the pid is not valid, the file is deleted. If all such files (i.e. with same "unit" designation) are successfully removed, then the SET LINE command succeeds; up to six messages are printed telling the user which "stale lockfiles" are being removed.
When the "set line" command succeeds in HP-UX 10.00 and later, C-Kermit also creates a Unix System V R4 "advisory lock" as a further precaution (but not guarantee) against any other process obtaining access to the device while you are using it.
If the selected device was in use by "cu", Kermit can't open it, because "cu" has changed its ownership, so we never get as far as looking at the lockfiles. In the normal case, we can't even look at the device to see who the owner is because it is visible only to its (present) owner. In this case, Kermit says (for example):
/dev/cua0p0: Permission denied
When Kermit releases a device it has successfully opened, it removes all the lockfiles that it created. This also happens whenever Kermit exits "under its own power".
If Kermit is killed with a device open, the lockfile(s) are left behind. The next Kermit program that tries to assign the device, under any of its various names, will automatically clean up the stale lockfiles because the pids they contain are invalid. The behavior of cu and other communication programs under these conditions should be the same.
Here, by the way, is a summary of the differences between the HP-UX port driver types from John Pezzano of HP:
There are three types of device files for each port.
The ttydXXX device file is designed to work as follows:
- 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.
- Once CD is asserted, the port is controlled by getty (or the process handling an incoming call) if there was no process using the port. The ? in the "ps" command now shows the port. At this point, the port accepts data.
Therefore you should use either the callout culXXX device file
(immediate control but no data until CD is asserted) or the direct
device file ttyXXX which gives immediate control and immediate data
and which ignores by default modem control signals.
The ttydXXX device should be used only for callin and my
recommendation is to use it only for getty and uugetty.
3.2.4 Notes on Specific HP-UX Releases
SECTION CONTENTS
3.2.4.1. [216]HP-UX 11
3.2.4.2. [217]HP-UX 10
3.2.4.3. [218]HP-UX 9
3.2.4.4. [219]HP-UX 8
3.2.4.5. [220]HP-UX 7 and Earlier
3.2.4.1. HP-UX 11
[ [221]Top ] [ [222]Contents ] [ [223]Section Contents ] [ [224]Next ]
As noted in [225]Section 3.2.2, the HP-UX 11 Telnet server and/or pseudoterminal driver are a serious impediment to file transfer over Telnet connections into HP-UX. If you have a Telnet connection into HP-UX 11, tell your desktop Kermit program to:
set streaming off
set receive packet-length 2000
set send packet-length 500
File transfer speeds over connections from HP-UX 11 (dialed or Telnet) are not impeded whatsoever, and can go at whatever speed is allowed by the connection and the Kermit partner on the far end.
PA-RISC binaries for HP-UX 10.20 or later should run on any PA-RISC system, S700 or S800, as long as the binary was not built under a later HP-UX version than the host operating system. HP-UX 11.00 and 11.11 are only for PA-RISC systems. HP-UX 11.20 is only for IA64 (subsequent HP-UX releases will be for both PA-RISC and IA64). To check binary compatibility, the following C-Kermit 8.0 binaries were run successfully on an HP-9000/785 with HP-UX 11.11:
- Model 7xx HP-UX 10.20
- Model 8xx HP-UX 10.20
- Model 7xx HP-UX 11.00
- Model 8xx HP-UX 11.00
- Model 7xx HP-UX 11.11
- Model 8xx HP-UX 11.11
Binaries built under some of the earlier HP-UX releases, such as 9.05, might also work, but only if built for the same hardware family (e.g. s700).
3.2.4.2. HP-UX 10
[ [226]Top ] [ [227]Contents ] [ [228]Section Contents ] [ [229]Next ] [ [230]Previous ]
Beginning in HP-UX 10.10, libcurses is linked to libxcurses, the new UNIX95 (X/Open) version of curses, which has some serious bugs; some routines, when called, would hang and never return, some would dump core. Evidently libxcurses contains a select() routine, and whenever C-Kermit calls what it thinks is the regular (sockets) select(), it gets the curses one, causing a segmentation fault. There is a patch for this from HP, PHCO_8086, "s700_800 10.10 libcurses patch", "shared lib curses program hangs on 10.10", "10.10 enhanced X/Open curses core dumps due to using wrong select call", 96/08/02 (you can tell if the patch is installed with "what /usr/lib/libxcurses.1"; the unpatched version is 76.20, the patched one is 76.20.1.2). It has been verified that C-Kermit works OK with the patched library, but results are not definite for HP-UX 10.20 or higher.
To ensure that C-Kermit works even on non-patched HP-UX 10.10 systems, separate makefile entries are provided for HP-UX 10.00/10.01, 10.10, 10.20, etc, in which the entries for 10.10 and above link with libHcurses, which is "HP curses", the one that was used in 10.00/10.01. HP-UX 11.20 and later, however, link with libcurses, as libHcurses disappeared in 11.20.
3.2.4.3. HP-UX 9
[ [231]Top ] [ [232]Contents ] [ [233]Section Contents ] [ [234]Next ] [ [235]Previous ]
HP-UX 9.00 and 9.01 need patch PHNE_10572 (note: this replaces PHNE_3641) for hptt0.o, asio0.o, and ttycomn.o in libhp-ux.a. Contact Hewlett Packard if you need this patch. Without it, the dialout device (tty) will be hung after first use; subsequent attempts to use will return an error like "device busy". (There are also equivalent patches for s700 9.03 9.05 9.07 (PHNE_10573) and s800 9.00 9.04 (PHNE_10416).
When C-Kermit is in server mode, it might have trouble executing REMOTE HOST commands. This problem happens under HP-UX 9.00 (Motorola) and HP-UX 9.01 (RISC) IF the C-Shell is the login shell AND with the C-Shell Revision 70.15. Best thing is to install HP's Patch PHCO_4919 for Series 300/400 and PHCO_5015 for the Series 700/800. PHCO_5015 is called "s700_800 9.X cumulative csh(1) patch with memory leak fix" which works for HP-UX 9.00, 9.01, 9.03, 9.04, 9.05 and 9.07. At least you need C-Shell Revision 72.12!
C-Kermit works fine -- including its curses-based file-transfer display -- on the console terminal, in a remote session (e.g. when logged in to the HP 9000 on a terminal port or when telnetted or rlogin'd), and in an HP-VUE hpterm window or an xterm window.
3.2.4.4. HP-UX 8
[ [236]Top ] [ [237]Contents ] [ [238]Section Contents ] [ [239]Next ] [ [240]Previous ]
To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install HP-UX patch PHNE_0899. This patch deals with a lot of driver issues, particularly related to communication at higher speeds.
One user reports:
On HP-UX 8 DON'T install 'tty patch' PHKL_4656, install PHKL_3047
instead! Yesterday I tried this latest tty patch PHKL_4656 and had
terrible problems. This patch should fix RTS/CTS problems. With
text transver all looks nice. But when I switched over to binary
files the serial interface returned only rubish to C-Kermit. All
sorts of protocol, CRC and packed errors I had. After several tests
and after uninstalling that patch, all transvers worked fine. MB's
of data without any errors. So keep your fingers away from that
patch. If anybody needs the PHKL_3047 patch I have it here. It is
no longer availabel from HP's patch base.
3.2.4.5. HP-UX 7 and Earlier
[ [241]Top ] [ [242]Contents ] [ [243]Section Contents ] [ [244]Previous ]
When transferring files into HP-UX 5 or 6 over a Telnet connection, you must not use streaming, and you must not use a packet length greater than 512. However, you can use streaming and longer packets when sending files from HP-UX on a Telnet connection. In C-Kermit 8.0, the default receive packet length for HP-UX 5 and 6 was changed to 500 (but you can still increase it with SET RECEIVE PACKET-LENGTH if you wish, e.g. for non-Telnet connections). Disable streaming with SET STREAMING OFF.
The HP-UX 5.00 version of C-Kermit does not include the fullscreen file-transfer because of problems with the curses library.
If HP-UX 5.21 with Wollongong TCP/IP is on the remote end of a Telnet connection, streaming transfers to HP-UX invariably fail. Workaround: SET STREAMING OFF. Packets longer than about 1000 should not be used. Transfers from these systems, however, can use streaming and/or longer packets.
Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on the HP-9000 series 500 computers. It only occurs when the controlling terminal is using an HP-27140 six-port modem mux. The problem is not present if the controlling terminal is logged into an HP-27130 eight-port mux. The symptom is that just after dialing successfully and connecting Kermit locks up and the port is unusable until both forks of Kermit and the login shell are killed." (This report predates C-Kermit 6.0 and might no longer apply.)
3.2.5. HP-UX and X.25
[ [245]Top ] [ [246]Contents ] [ [247]Section Contents ] [ [248]Previous ]
Although C-Kermit presently does not include built-in support for HP-UX X.25 (as it does for the Sun and IBM X.25 products), it can still be used to make X.25 connections as follows: start Kermit and then telnet to localhost. After logging back in, start padem as you would normally do to connect over X.25. Padem acts as a pipe between Kermit and X.25. In C-Kermit 7.0, you might also be able to avoid the "telnet localhost" step by using:
C-Kermit> pty padem address
This works if padem uses standard i/o (who knows?).
3.3. C-KERMIT AND LINUX
[ [249]Top ] [ [250]Contents ] [ [251]Section Contents ] [ [252]Next ] [ [253]Previous ]
SECTION CONTENTS
3.3.1. [254]Problems Building C-Kermit for Linux
3.3.2. [255]Problems with Serial Devices in Linux
3.3.3. [256]Terminal Emulation in Linux
3.3.4. [257]Dates and Times
3.3.5. [258]Startup Errors
3.3.6. [259]The Fullscreen File Transfer Display
REFERENCES
For further information, read the [260]comp.os.linux.misc, [261]comp.os.linux.answers, and other Linux-oriented newsgroups, and
- see
The Linux Document Project (LDP)
[262]http://www.tldp.org/
The Linux FAQ
[263]http://www.tldp.org/FAQ/Linux-FAQ.html
The Linux HOWTOs (especially the Serial HOWTO)
[264]http://www.tldp.org/HOWTO/Serial-HOWTO.html
[265]http://tldp.org/HOWTO/Modem-HOWTO.html
[266]ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
[267]ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
[268]http://www.tldp.org/HOWTO/
[269]http://www.tldp.org/hmirrors.html
Linux Vendor Tech Support Pages:
[270]http://www.redhat.com/apps/support/
[271]http://www.debian.org/support
[272]http://www.slackware.com/support/
[273]http://www.caldera.com/support/
[274]http://www.suse.com/support/
[275]http://www.mandrake.com/support/
[276]http://www.turbolinux.com/support/
Linux Winmodem Support
[277]http://www.linmodems.org/
Also see general comments on PC-based Unixes in [278]Section 3.0.
What Linux version is it? -- "uname -a" supplies only kernel information, but these days it's the distribution that matters: Red Hat 7.3, Debian 2.2, Slackware 8.0, etc. Unfortunately there's no consistent way to get the distribution version. Usually it's in a distribution-specific file:
Red Hat: /etc/issue or /etc/redhat-release
Debian: /etc/debian_version
Slackware: /etc/slackware-version (at least in later versions)
Did you know: DECnet is available for Linux? See:
[279]http://linux.dreamtime.org/decnet/
(But there is no support for it in C-Kermit -- anybody interested in adding it, please [280]let us know).
Before proceeding, let's handle the some of the most frequently asked question in the Linux newsgroups:
- 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.
- "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.
- (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.
- (Any question that has the word "FTP" in it...) The knee-jerk
reaction being "Don't use FTP, use SCP!" (or SFTP). Same answer as
above, but moreso. SCP and SFTP are not only not platform neutral,
they're diversity-hostile. They transfer files only in binary
mode, which mangles text files across different platforms, to the
same degree the platform's text-file record format and character
set differ. An extreme example would be an Variable-Block format
EBCDIC text file on an IBM mainframe, binary transfer of which to
Unix would do you little good indeed. FTP was designed with
diversity in mind and secure versions are available.
3.3.1. Problems Building C-Kermit for Linux
[ [285]Top ] [ [286]Contents ] [ [287]Section Contents ] [ [288]Next ]
Modern Linux distributions like Red Hat give you a choice at installation whether to include "developer tools". Obviously, you can't build C-Kermit or any other C program from source code if you have not installed the developer tools. But to confuse matters, you might also have to choose (separately) to install the "curses" or "ncurses" terminal control library; thus it is possible to install the C compiler and linker, but omit the (n)curses library and headers. If curses is not installed, you will not be able to build a version of C-Kermit that supports the fullscreen file-transfer display, in which case you'll need to use the "linuxnc" makefile target (nc = No Curses) or else install ncurses before building.
There are all sorts of confusing issues caused by the many and varied Linux distributions. Some of the worst involve the curses library and header files: where are they, what are they called, which ones are they really? Other vexing questions involve libc5 vs libc6 vs glibc vs glibc2 (C libraries), gcc vs egcs vs lcc (compilers), plus using or avoiding features that were added in a certain version of Linux or a library or a distribution, and are not available in others. As of C-Kermit 8.0, these questions should be resolved by the "linux" makefile target itself, which does a bit of looking around to see what's what, and then sets the appropriate CFLAGS.
3.3.2. Problems with Serial Devices in Linux
[ [289]Top ] [ [290]Contents ] [ [291]Section Contents ] [ [292]Next ] [ [293]Previous ]
Also see: "man setserial", "man irqtune".
And: [294]Sections 3.0, [295]6, [296]7, and [297]8 of this
document.
NOTE: Red Hat Linux 7.2 and later include a new API that allows
serial-port arbitration by non-setuid/gid programs. This API has
not yet been added to C-Kermit. If C-Kermit is to be used for
dialing out on Red Hat 7.2 or later, it must still be installed as
described in in Sections [298]10 and [299]11 of the
[300]Installation Instructions.
Don't expect it to be easy. Queries like the following are posted to the Linux newsgroups almost daily:
Problem of a major kind with my Compaq Presario 1805 in the sense
that the pnpdump doesn't find the modem and the configuration tells
me that the modem is busy when I set everything by hand!
I have <some recent SuSE distribution>, kernel 2.0.35. Using the
Compaq tells me that the modem (which is internal) is on COM2, with
the usual IRQ and port numbers. Running various Windows diagnostics
show me AT-style commands exchanged so I have no reason to beleive
that it is a Winmodem. Also, the diagnostics under Win98 tell me
that I am talking to an NS 16550AN.
[Editor's note: This does not necessarily mean it isn't a Winmodem.]
Under Linux, no joy trying to talk to the modem on /dev/cua1
whether via minicom, kppp, or chat; kppp at least tells me that
tcgetattr() failed.
Usage of setserial:
setserial /dev/cua1 port 0x2F8 irq 3 autoconfig setserial -g /dev/cua1
tells me that the uart is 'unknown'. I have tried setting the UART
manullay via. setserial to 16550A, 16550, and the other one (8550?)
(I didn't try 16540). None of these manual settings resulted in any
success.
A look at past articles leads me to investigate PNP issues by
calling pnpdump but pnpdump returns "no boards found". I have
looked around on my BIOS (Phoenix) and there is not much evidence
of it being PNP aware. However for what it calls "Serial port A",
it offers a choice of Auto, Disabled or Manual settings (currently
set to Auto), but using the BIOS interface I tried to change to
'manual' and saw the default settings offered to be were 0x3F8 and
IRQ 4 (COM1). The BIOS menus did not give me any chance to
configure COM2 or any "modem". I ended up not saving any BIOS
changes in the course of my investigations.
You can also find out a fair amount about your PC's hardware configuration in the text files in /proc, e.g.:
-r--r--r-- 1 root 0 Sep 4 14:00 /proc/devices -r--r--r-- 1 root 0 Sep 4 14:00 /proc/interrupts -r--r--r-- 1 root 0 Sep 4 14:00 /proc/ioports -r--r--r-- 1 root 0 Sep 4 14:00 /proc/pci
From the directory listing they look like empty files, but in fact they are text files that you "cat":
$ cat /proc/pci
Bus 0, device 14, function 0:
Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 1).
IRQ 10.
I/O at 0x1050 [0x1057].
$ setserial -g /dev/ttyS4
/dev/ttyS4, UART: 16550A, Port: 0x1050, IRQ: 10
$ cat /proc/ioports
1050-1057 : US Robotics/3Com 56K FaxModem Model 5610
1050-1057 : serial(auto)
$ cat /proc/interrupts
CPU0
0: 7037515 XT-PIC timer
1: 2 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 0 XT-PIC serial
8: 1 XT-PIC rtc
9: 209811 XT-PIC usb-uhci, eth0
14: 282015 XT-PIC ide0
15: 6 XT-PIC ide1
Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the like (see cautions in [301]Section 3.0 Linux supports Plug-n-Play devices to some degree via the isapnp and pnpdump programs; read the man pages for them. (If you don't have them, look on your installation CD for isapnptool or download it from sunsite or a sunsite mirror or other politically correct location du jour).
PCI modems do not use standard COM port addresses. The I/O address and IRQ are assigned by the BIOS. All you need to do to get one working, find out the I/O address and interrupt number with (as root) "lspci -v | more" and then give the resulting address and interrupt number to setserial.
Even when you have a real serial port, always be wary of interrupt conflicts and similar PC hardware configuration issues: a PC is not a real computer like other Unix workstations -- it is generally pieced together from whatever random components were the best bargain on the commodity market the week it was built. Once it's assembled and boxed, not even the manufacturer will remember what it's made of or how it was put together because they've moved on to a new model. Their job is to get it (barely) working with Windows; for Linux and other OS's you are on your own.
"set line /dev/modem" or "set line /dev/ttyS2", etc, results in an error, "/dev/modem is not a tty". Cause unknown, but obviously a driver issue, not a Kermit one (Kermit uses "isatty()" to check that the device is a tty, so it knows it will be able to issue all the tty-related ioctl's on it, like setting the speed & flow control). Try a different name (i.e. driver) for the same port, e.g. "set line /dev/cua2" or whatever.
To find what serial ports were registered at the most recent system boot, type (as root): "grep tty /var/log/dmesg".
"set modem type xxx" (where xxx is the name of a modem) followed by
"set line /dev/modem" or "set
line /dev/ttyS2", etc, hangs (but can be interrupted with Ctrl-C).
Experimentation shows that if the modem is configured to always assert
carrier (&C0) the same command does not hang. Again, a driver issue.
Use /dev/cua2 (or whatever) instead. (Or not -- hopefully none of
these symptoms occurs in C-Kermit 7.0 or later.)
"set line /dev/cua0" reports "Device is busy", but "set line /dev/ttyS0" works OK.
In short: If the cua device doesn't work, try the corresponding ttyS device. If the ttyS device doesn't work, try the corresponding cua device -- but note that Linux developers do not recommend this, and are phasing out the cua devices. From /usr/doc/faq/howto/Serial-HOWTO:
12.4. What's The Real Difference Between the /dev/cuaN And /dev/ttySN
Devices?
The only difference is the way that the devices are opened. The
dialin devices /dev/ttySN are opened in blocking mode, until CD
is asserted (ie someone connects). So, when someone wants to
use the /dev/cuaN device, there is no conflict with a program
watching the /dev/ttySN device (unless someone is connected of
course). The multiple /dev entries, allow operation of the same
physical device with different operating characteristics. It
also allows standard getty programs to coexist with any other
serial program, without the getty being retrofitted with
locking of some sort. It's especially useful since standard
Unix kernel file locking, and UUCP locking are both advisory
and not mandatory.
It was discovered during development of C-Kermit 7.0 that rebuilding C-Kermit with -DNOCOTFMC (No Close/Open To Force Mode Change) made the aforementioned problem with /dev/ttyS0 go away. It is not yet clear, however, what its affect might be on the /dev/cua* devices. As of 19 March 1998, this option has been added to the CFLAGS in the makefile entries for Linux ("make linux").
Note that the cua device is now "deprecated", and new editions of Linux will phase (have phased) it out in favor of the ttyS device. See (if it's still there):
[302]http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
(no, of course it isn't; you'll have to use your imagination). One user reported that C-Kermit 7.0, when built with egcs 1.1.2 and run on Linux 2.2.6 with glibc 2.1 (hardware unknown but probably a PC) dumps core when given a "set line /dev/ttyS1" command. When rebuilt with gcc, it works fine.
All versions of Linux seem to have the following deficiency: When a modem call is hung up and CD drops, Kermit can no longer read the modem signals; SHOW COMMUNICATIONS says "Modem signals not available". The TIOCMGET ioctl() returns -1 with errno 5 ("I/O Error").
The Linux version of POSIX tcsendbreak(), which is used by C-Kermit to send regular (275msec) and long (1.5sec) BREAK signals, appears to ignore its argument (despite its description in the man page and info topic), and always sends a regular 275msec BREAK. This has been observed in Linux versions ranging from Debian 2.1 to Red Hat 7.1.
3.3.3. Terminal Emulation in Linux
[ [303]Top ] [ [304]Contents ] [ [305]Section Contents ] [ [306]Next ] [ [307]Previous ]
C-Kermit is not a terminal emulator. For a brief explanation of why not, see [308]Section 3.0.5. For a fuller explanation, [309]ClICK HERE.
In Unix, terminal emulation is supplied by the Window in which you run Kermit: the regular console screen, which provides Linux Console "emulation" via the "console" termcap entry, or under X-Windows in an xterm window, which gives VTxxx emulation. An xterm that includes color ANSI and VT220 emulation is available with Xfree86:
[310]http://dickey.his.com/xterm/xterm.html
Before starting C-Kermit in an xterm window, you might need to tell the xterm window's shell to "stty sane".
To set up your PC console keyboard to send VT220 key sequences when using C-Kermit as your communications program in an X terminal window (if it doesn't already), create a file somewhere (e.g. in /root/) called .xmodmaprc, containing something like the following:
keycode 77 = KP_F1 ! Num Lock => DEC Gold (PF1) keycode 112 = KP_F2 ! Keypad / => DEC PF1 keycode 63 = KP_F3 ! Keypad * => DEC PF3 keycode 82 = KP_F4 ! Keypad - => DEC PF4 keycode 111 = Help ! Print Screen => DEC Help keycode 78 = F16 ! Scroll Lock => DEC Do keycode 110 = F16 ! Pause => DEC Do keycode 106 = Find ! Insert => DEC Find keycode 97 = Insert ! Home => DEC Insert keycode 99 = 0x1000ff00 ! Page Up => DEC Remove keycode 107 = Select ! Delete => DEC Select keycode 103 = Page_Up ! End => DEC Prev Screen keycode 22 = Delete ! Backspace sends Delete (127)
Then put "xmodmap filename" in your .xinitrc file (in your login directory), e.g.
xmodmap /root/.xmodmaprc
Of course you can move things around. Use the xev program to find out key codes.
Console-mode keys are mapped separately using loadkeys, and different keycodes are used. Find out what they are with showkey.
For a much more complete VT220/320 key mapping for [311]Xfree86 xterm, [312]CLICK HERE.
3.3.4. Dates and Times
[ [313]Top ] [ [314]Contents ] [ [315]Section Contents ] [ [316]Next ] [ [317]Previous ]
If C-Kermit's date-time (e.g. as shown by its DATE command) differs from the system's date and time:
- 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.
- If you have changed your TZ environment variable, make sure it is
exported. This is normally done in /etc/profile or /etc/TZ.
3.3.5. Startup Errors
[ [318]Top ] [ [319]Contents ] [ [320]Section Contents ] [ [321]Next ] [ [322]Previous ]
C-Kermit should work on all versions of Linux current through March 2003, provided it was built on the same version you have, with the same libraries and header files (just get the source code and "make linux"). Binaries tend not to travel well from one Linux machine to another, due to their many differences. There is no guarantee that a particular C-Kermit binary will not stop working at a later date, since Linux tends to change out from under its applications. If that happens, rebuild C-Kermit from source. If something goes wrong with the build process, look on the [323]C-Kermit website for a newer version. If you have the latest version, then [324]report the problem to us.
Inability to transfer files in Red Hat 7.2: the typical symptom would be if you start Kermit and tell it to RECEIVE, it fails right away with "?/dev/tty: No such device or address" or "?Bad file descriptor". One report says this is because of csh, and if you change your shell to bash or other shell, it doesn't happen. Another report cite bugs in Red Hat 7.2 Telnetd "very seldom (if ever) providing a controlling tty, and lots of other people piled on saying they have the same problem.") A third theory is that this happens only when Linux has been installed without "virtual terminal support".
A search of RedHat's errata pages shows a bug advisory (RHBA-2001-153) issued 13 November 2001, but updated 6 December, about this same symptom (but with tcsh and login.) Seems that login was not always assigning a controlling TTY for the session, which would make most use of "/dev/tty" somewhat less than useful.
[325]http://www.redhat.com/support/errata/RHBA-2001-153.html
Quoting: "Due to terminal handling problems in /bin/login, tcsh would not find the controlling terminal correctly, and a shell in single user mode would exhibit strange terminal input characteristics. This update fixes both of these problems."
Since the Red Hat 5.1 release (circa August 1998), there have been numerous reports of prebuilt Linux executables, and particularly the Kermit RPM for Red Hat Linux, not working; either it won't start at all, or it gives error messages about "terminal type unknown" and refuses to initialize its curses support. The following is from the [326]Kermit newsgroup:
From: rchandra@hal9000.buf.servtech.com
Newsgroups: comp.protocols.kermit.misc
Subject: Red Hat Linux/Intel 5.1 and ncurses: suggestions
Date: 22 Aug 1998 15:54:46 GMT
Organization: Verio New York
Keywords: RedHat RPM 5.1
Several factors can influence whether "linux" is recognized as a
terminal type on many Linux systems.
- 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.)
- 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).
- Your program, or the libraries...are looking for a terminfo file
that is stored at a pathname that isn't expected by your program,
the libraries--and so on. I forgot if I read this in the errata
Web page or where exactly I discovered this (Netscape install?
Acrobat install?), but it may just be that one libc (let's say for
sake of argument, libc5, but I don't know this to be true) expects
your terminfo to be in /usr/share/terminfo, and the other (let's
say libc6/glibc) expects /usr/lib/terminfo. I remember that the
specific instructions in this bugfix/workaround were to do the
following or equivalent:
cd /usr/lib
ln -s ../share/terminfo ./terminfo
- or
- ln -s /usr/share/terminfo /usr/lib/terminfo
So what this says is that the terminfo database/directory structure
can be accessed by either path. When something goes to reference
/usr/lib/terminfo, the symlink redirects it to essentially
/usr/share/terminfo, which is where it really resides on your
system. I personally prefer wherever possible to use relative
symlinks, because they still hold, more often than break, across
mount points, particularly NFS mounts, where the directory
structure may be different on the different systems.
Evidently the terminfo file moved between Red Hat 5.0 and 5.1, but Red Hat did not include a link to let applications built prior to 5.1 find it. Users reported that installing the link fixes the problem.
3.3.6. The Fullscreen File Transfer Display
[ [327]Top ] [ [328]Contents ] [ [329]Section Contents ] [ [330]Previous ]
Starting with ncurses versions dated 1998-12-12 (about a year before ncurses 5.0), ncurses sets the terminal for buffered i/o, but unfortunately is not able to restore it upon exit from curses (via endwin()). Thus after a file transfer that uses the fullscreen file transfer display, the terminal no longer echos nor responds immediately to Tab, ?, and other special command characters. The same thing happens on other platforms that use ncurses, e.g. FreeBSD.
- Workarounds
-
- Use SET XFER DISPLAY BRIEF, CRT, SERIAL, or NONE instead of FULLSCREEN; or:
- Rebuild with KFLAGS=-DNONOSETBUF (C-Kermit 8.0)
In Red Hat 7.1, when using C-Kermit in a Gnome terminal window, it was noticed that when the fullscreen file transfer display exits (via endwin()), the previous (pre-file-transfer-display) screen is restored. Thus you can't look at the completed display to see what happened. This is a evidently a new feature of xterm. I can only speculate that initscreen() and endwin() must send some kind of special escape sequences that command xterm to save and restore the screen. To defeat this effect, tell Linux you have a vt100 or other xterm-compatible terminal that is not actually an xterm, or else tell Kermit to SET TRANSFER DISPLAY to something besides FULLSCREEN.
3.4. C-KERMIT AND NEXTSTEP
[ [331]Top ] [ [332]Contents ] [ [333]Section Contents ] [ [334]Next ] [ [335]Previous ]
Run C-Kermit in a Terminal, Stuart, or xterm window, or when logged in remotely through a serial port or TELNET connection. C-Kermit does not work correctly when invoked directly from the NeXTSTEP File Viewer or Dock. This is because the terminal-oriented gtty, stty, & ioctl calls don't work on the little window that NeXTSTEP pops up for non-NeXTSTEP applications like Kermit. CBREAK and No-ECHO settings do not take effect in the command parser -- commands are parsed strictly line at a time. "set line /dev/cua" works. During CONNECT mode, the console stays in cooked mode, so characters are not transmitted until carriage return or linefeed is typed, and you can't escape back. If you want to run Kermit directly from the File Viewer, then launch it from a shell script that puts it in the desired kind of window, something like this (for "Terminal"):
Terminal -Lines 24 -Columns 80 -WinLocX 100 -WinLocY 100 $FONT $FONTSIZE \ -SourceDotLogin -Shell /usr/local/bin/kermit &
C-Kermit does not work correctly on a NeXT with NeXTSTEP 3.0 to which you have established an rlogin connection, due to a bug in NeXTSTEP 3.0, which has been reported to NeXT.
The SET CARRIER command has no effect on the NeXT -- this is a limitation of the NeXTSTEP serial-port device drivers.
Hardware flow control on the NeXT is selected not by "set flow rts/cts" in Kermit (since NeXTSTEP offers no API for this), but rather, by using a specially-named driver for the serial device: /dev/cufa instead /dev/cua; /dev/cufb instead of /dev/cub. This is available only on 68040-based NeXT models (the situation for Intel NeXTSTEP implementations is unknown).
NeXT-built 68030 and 68040 models have different kinds of serial interfaces; the 68030 has a Macintosh-like RS-422 interface, which lacks RTS and CTS signals; the 68040 has an RS-423 (RS-232 compatible) interface, which supports the commonly-used modem signals. WARNING: the connectors look exactly the same, but the pins are used in completely DIFFERENT ways -- different cables are required for the two kinds of interfaces.
IF YOU GET LOTS OF RETRANSMISSIONS during file transfer, even when
using a /dev/cuf* device and the modem is correctly configured for
RTS/CTS flow control, YOU PROBABLY HAVE THE WRONG KIND OF CABLE.
On the NeXT, Kermit reportedly (by TimeMon) causes the kernel to use a lot of CPU time when using a "set line" connection. That's because there is no DMA channel for the NeXT serial port, so the port must interrupt the kernel for each character in or out.
One user reported trouble running C-Kermit on a NeXT from within NeXT's Subprocess class under NeXTstep 3.0, and/or when rlogin'd from one NeXT to another: Error opening /dev/tty:, congm: No such device or address. Diagnosis: Bug in NeXTSTEP 3.0, cure unknown.
3.5. C-KERMIT AND QNX
[ [336]Top ] [ [337]Contents ] [ [338]Section Contents ] [ [339]Next ] [ [340]Previous ]
See also: The [341]comp.os.qnx newsgroup.
Support for QNX 4.x was added in C-Kermit 5A(190). This is a full-function implementation, thoroughly tested on QNX 4.21 and later, and verified to work in both 16-bit and 32-bit versions. The 16-bit version was dropped in C-Kermit 7.0 since it can no longer be built successfully (after stripping most most features, I succeeded in getting it to compile and link without complaint, but the executable just beeps when you run it); for 16-bit QNX 4.2x, use C-Kermit 6.0 or earlier, or else [342]G-Kermit.
The 32-bit version (and the 16-bit version prior to C-Kermit 7.0) supports most of C-Kermit's advanced features including TCP/IP, high serial speeds, hardware flow-control, modem-signal awareness, curses support, etc.
BUG: In C-Kermit 6.0 on QNX 4.22 and earlier, the fullscreen file transfer display worked fine the first time, but was fractured on subsequent file transfers. Cause and cure unknown. In C-Kermit 7.0 and QNX 4.25, this no longer occurs. It is not known if it would occur in C-Kermit 7.0 or later on earlier QNX versions.
Dialout devices are normally /dev/ser1, /dev/ser2, ..., and can be opened explicitly with SET LINE. Reportedly, "/dev/ser" (no unit number) opens the first available /dev/sern device.
Like all other Unix C-Kermit implementations, QNX C-Kermit does not provide any kind of terminal emulation. Terminal specific functions are provided by your terminal, terminal window (e.g. QNX Terminal or xterm), or emulator.
QNX C-Kermit, as distributed, does not include support for UUCP line-locking; the QNX makefile entries (qnx32 and qnx16) include the -DNOUUCP switch. This is because QNX, as distributed, does not include UUCP, and its own communications software (e.g. qterm) does not use UUCP line locking. If you have a UUCP product installed on your QNX system, remove the -DNOUUCP switch from the makefile entry and rebuild. Then check to see that Kermit's UUCP lockfile conventions are the same as those of your UUCP package; if not, read the [343]UUCP lockfile section of the [344]Installation Instructions and make the necessary changes to the makefile entry (e.g. add -DHDBUUCP).
QNX does, however, allow a program to get the device open count. This can not be a reliable form of locking unless all applications do it, so by default, Kermit uses this information only for printing a warning message such as:
C-Kermit>set line /dev/ser1
WARNING - "/dev/ser1" looks busy...
However, if you want to use it as a lock, you can do so with:
SET QNX-PORT-LOCK { ON, OFF }
This is OFF by default; if you set in ON, C-Kermit will fail to open any dialout device when its open count indicates that another process has it open. SHOW COMM (in QNX only) displays the setting, and if you have a port open, it also shows the open count.
As of C-Kermit 8.0, C-Kermit's "open-count" form of line locking works only in QNX4, not in QNX6 (this might change in a future C-Kermit release).
3.6. C-KERMIT AND SCO
[ [345]Top ] [ [346]Contents ] [ [347]Section Contents ] [ [348]Next ] [ [349]Previous ]
SECTION CONTENTS
3.6.1. [350]SCO XENIX
3.6.2. [351]SCO UNIX and OSR5
3.6.3. [352]Unixware
3.6.4. [353]Open UNIX 8
REFERENCES
- The comp.unix.sco.* newsgroups.
- [354]Section 3.10 below for Unixware.
- The following FAQs:
The comp.sco.misc FAQ:
[355]http://aplawrence.com/SCOFAQ/
Caldera (SCO) comp.unix.sco.programmer FAQ:
[356]http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
The UnixWare 7/OpenUNIX 8 FAQ:
[357]http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
[358]http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
High Speed Modems for SCO Unix:
[359]http://pcunix.com/Unixart/modems.html
The UnixWare FAQ
[360]http://www.freebird.org/faq/
The UnixWare 1.x and 2.0 Programmer FAQ
[361]http://www.freebird.org/faq/developer.html
Caldera Support Knowledge Base
[362]http://support.caldera.com/caldera
[363]http://stage.caldera.com/ta/
Caldera (SCO) Technical Article Search Center
[364]http://aplawrence.com/newtosco.html
New to SCO (Tony Lawrence)
The same comments regarding terminal emulation and key mapping apply to SCO operating systems as to all other Unixes. C-Kermit is not a terminal emulator, and you can't use it to map F-keys, Arrow keys, etc. The way to do this is with xmodmap (xterm) or loadkeys (console). For a brief explanation, see [365]Section 3.0.5. For a fuller explanation, [366]ClICK HERE.
Also see general comments on PC-based Unixes in [367]Section 3.0.
3.6.1. SCO XENIX
[ [368]Top ] [ [369]Contents ] [ [370]Section Contents ] [ [371]Next ]
Old Xenix versions... Did you know: Xenix 3.0 is older than Xenix 2.0?
In Xenix 2.3.4 and probably other Xenix versions, momentarily dropping DTR to hang up a modem does not work. DTR goes down but does not come up again. Workaround: Use SET MODEM HANGUP-METHOD MODEM-COMMAND. Anybody who would like to fix this is welcome to take a look at tthang() in [372]ckutio.c. Also: modem signals can not be read in Xenix, and the maximum serial speed is 38400.
There is all sorts of confusion among SCO versions, particularly when third- party communications boards and drivers are installed, regarding lockfile naming conventions, as well as basic functionality. As far as lockfiles go, all bets are off if you are using a third-party multiport board. At least you have the source code. Hopefully you also have a C compiler :-)
Xenix 2.3.0 and later claim to support RTSFLOW and CTSFLOW, but this is not modern bidirectional hardware flow control; rather it implements the original RS-232 meanings of these signals for unidirectional half-duplex line access: If both RTSFLOW and CTSFLOW bits are set, Xenix asserts RTS when it wants to send data and waits for CTS assertion before it actually starts sending data (also, reportedly, even this is broken in Xenix 2.3.0 and 2.3.1).
3.6.2. SCO UNIX AND OSR5
[ [373]Top ] [ [374]Contents ] [ [375]Section Contents ] [ [376]Next ] [ [377]Previous ]
SCO systems tend to use different names (i.e. drivers) for the same device. Typically /dev/tty1a refers to a terminal device that has no modem control; open, read, write, and close operations do not depend on carrier. On the other hand, /dev/tty1A (same name, but with final letter upper case), is the same device with modem control, in which carrier is required (the SET LINE command does not complete until carrier appears, read/write operations fail if there is no carrier, etc).
SCO OpenServer 5.0.5 and earlier do not support the reading of modem signals. Thus "show comm" does not list modem signals, and C-Kermit does not automatically pop back to its prompt when the modem hangs up the connection (drops CD). The ioctl() call for this is simply not implmented, at least not in the standard drivers. OSR5.0.6 attempts to deal with modem signals but fails; however OSR5.0.6a appears to function properly.
Dialing is likely not to work well in SCO OpenServer 5.0.x because many of the serial-port APIs simply do not operate when using the standard drivers. For example, if DTR is dropped by the recommended method (setting speed to 0 for half a seconds, then restoring the speed), DTR and RTS go down but never come back up. When in doubt SET MODEM HANGUP-METHOD MODEM-COMMAND or SET DIAL HANGUP OFF.
On the other hand, certain functions that might not (do not) work right or at all when using SCO drivers (e.g. high serial speeds, hardware flow control, and/or reading of modem signals) might work right when using third-party drivers. (Example: hardware flow control works, reportedly, only on uppercase device like tty1A -- not tty1a -- and only when CLOCAL is clear when using the SCO sio driver, but there are no such restrictions in, e.g., [378]Digiboard drivers).
One user reports that he can't transfer large files with C-Kermit under SCO OSR5.0.0 and 5.0.4 -- after the first 5K, everything falls apart. Same thing without Kermit -- e.g. with ftp over a PPP connection. Later, he said that replacing SCO's SIO driver with FAS, an alternative communications driver, made the problem go away:
[379]ftp://ftp.fu-berlin.de/pub/unix/driver/fas
With regard to bidirectional serial ports on OpenServer 5.0.4, the following advice appeared on an SCO-related newsgroup:
No amount of configuration information is going to help you on
5.0.4 unless it includes the kludge for the primary problem. With
almost every modem, the 5.0.4 getty will barf messages and may or
may not connect. There are 2 solutions and only one works on 5.0.4.
Get the atdialer binary from a 5.0.0 system and substitute it for
the native 5.0.4 atdialer. The other solution is to upgrade to
5.0.5. And, most of all, on any OpenServer products, do NOT run the
badly broken Modem Manager. Configure the modems in the time
honored way that dates back to Xenix.
Use SCO-provided utilities for switching the directionality of a modem line, such as "enable" and "disable" commands. For example, to dial out on tty1a, which is normally set up for logins:
disable tty1a
kermit -l /dev/tty1a
enable tty1a
If a tty device is listed as an ACU in /usr/lib/uucp/Devices and is enabled, getty resets the ownership and permissions to uucp.uucp and 640 every time the device is released. If you want to use the device only for dialout, and you want to specify other owners or permissions, you should disable it in /usr/lib/uucp/Devices; this will prevent getty from doing things to it. You should also changes the device's file modes in /etc/conf/node.d/sio by changing fields 5-7 for the desired device(s); this determines how the devices are set if you relink the kernel.
One SCO user of C-Kermit 5A(190) reported that only one copy of Kermit can run at a time when a Stallion Technologies multiport boards are installed. Cause, cure, and present status unknown (see [380]Section 14 for more info regarding Stallion).
Prior to SCO OpenServer 5.0.4, the highest serial port speed supported by SCO was 38400. However, in some SCO versions (e.g. OSR5) it is possible to map rarely-used lower speeds (like 600 and 1800) to higher ones like 57600 and 115200. To find out how, go to [381]http://www.sco.com/ and search for "115200". In OSR5.0.4, serial speeds up to 921600 are supported through the POSIX interface; C-Kermit 6.1.193 or later, when built for OSR5.0.4 using /bin/cc (NOT the UDK, which hides the high-speed definitions from CPP), supports these speeds, but you might be able to run this binary on earlier releases to get the high serial speeds, depending on various factors, described by Bela Lubkin of SCO:
Serial speeds under SCO Unix / Open Desktop / OpenServer
Third party drivers (intelligent serial boards) may provide any speeds they desire; most support up to 115.2Kbps.
SCO's "sio" driver, which is used to drive standard serial ports with 8250/16450/16550 and similar UARTs, was limited to 38400bps in older releases. Support for rates through 115.2Kbps was added in the following releases:
SCO OpenServer Release 5.0.0 (requires supplement "rs40b") SCO OpenServer Release 5.0.2 (requires supplement "rs40a" or "rs40b") SCO OpenServer Release 5.0.4 or later SCO Internet FastStart Release 1.0.0 or later
SCO supplements are at [382]ftp://ftp.sco.com/; the "rs40" series are under directory /Supplements/internet
Kermit includes the high serial speeds in all OSR5 builds, but that does not necessarily mean they work. For example, on our in-house 5.0.5 system, SET SPEED 57600 or higher seems to succeed (no error occurs) but when we read the speed back the driver says it is 50. Similarly, 76800 becomes 75, and 115200 becomes 110. Testing shows the resulting speed is indeed the low one we read back, not the high one we asked for. Moral: Use speeds higher than 38400 with caution on SCO OSR5.
Reportedly, if you have a script that makes a TCP/IP SET HOST (e.g. Telnet) connection to SCO 3.2v4.2 with TCP/IP 1.2.1, and then does the
- following
script $ exit
hangup
this causes a pseudoterminal (pty) to be consumed on the SCO system; if you do it enough times, it will run out of ptys. An "exit" command is being sent to the SCO shell, and a HANGUP command is executed locally, so the chances are good that both sides are trying to close the connection at once, perhaps inducing a race condition in which the remote pty is not released. It was speculated that this would be fixed by applying SLS net382e, but it did not. Meanwhile, the workaround is to insert a "pause" between the SCRIPT and HANGUP commands. (The situation with later SCO releases is not known.)
SCO UNIX and OpenServer allow their console and/or terminal drivers to be configured to translate character sets for you. DON'T DO THIS WHEN USING KERMIT! First of all, you don't need it -- Kermit itself already does this for you. And second, it will (a) probably ruin the formatting of your screens (depending on which emulation you are using); and (b) interfere with all sorts of other things -- legibility of non-ASCII text on the terminal screen, file transfer, etc. Use:
mapchan -n
to turn off this feature.
Note that there is a multitude of SCO entries in the makefile, many of them exhibiting an unusually large number of compiler options. Some people actually understand all of this. Reportedly, things are settling down with SCO OpenServer 5.x and Unixware 7 (and Open UNIX 8 and who knows what the next one will be -- Linux probably) -- the SCO UDK compiler is said to generate binaries that will run on either platform, by default, automatically. When using gcc or egcs, on the other hand, differences persist, plus issues regarding the type of binary that is generated (COFF, ELF, etc), and where and how it can run. All of this could stand further clarification by SCO experts.
3.6.3. Unixware
[ [383]Top ] [ [384]Contents ] [ [385]Section Contents ] [ [386]Next ] [ [387]Previous ]
Unixware changed hands several times before landing at SCO, and so has its [388]own section in this document. (Briefly: AT&T UNIX Systems Laboratories sold the rights to the UNIX name and to System V R4 (or R5?) to Novell; later Novell spun its UNIX division off into a new company called Univel, which eventually was bought by SCO, which later was bought by Caldera, which later sort of semi-spun-off SCO...)
3.6.4. Open UNIX 8
[ [389]Top ] [ [390]Contents ] [ [391]Section Contents ] [ [392]Previous ]
SCO was bought by Caldera in 2000 or 2001 and evolved Unixware 7.1 into Caldera Open UNIX 8.00. It's just like Unixware 7.1 as far as Kermit is concerned (the Unixware 7.1 makefile target works for Open UNIX 8.00, and in fact a Unixware 7.1 Kermit binary built on Unixware 7.1 runs under OU8; a separate OU8 makefile target exists simply to generate an appropriate program startup herald). Open Unix is now defunct; subsequent releases are called UnixWare again (e.g. UnixWare 7.1.3).
3.7. C-KERMIT AND SOLARIS
[ [393]Top ] [ [394]Contents ] [ [395]Section Contents ] [ [396]Next ] [ [397]Previous ]
SECTION CONTENTS
3.7.1. [398]Serial Port Configuration
3.7.2. [399]Serial Port Problems
3.7.3. [400]SunLink X.25
3.7.4. [401]Sun Workstation Keyboard Mapping
3.7.5. [402]Solaris 2.4 and Earlier
REFERENCES
- The [403]comp.unix.solaris newsgroup
- [404]http://access1.sun.com/
- [405]http://docs.sun.com/
- [406]http://www.sunhelp.com/
- [407]http://www.wins.uva.nl/pub/solaris/solaris2/
- [408]http://www.wins.uva.nl/cgi-bin/sfaq.cgi
- [409]ftp://ftp.wins.uva.nl/pub/solaris
- [410]http://www.science.uva.nl/pub/solaris/solaris2.html
And about serial communications in particular, see "Celeste's Tutorial on Solaris 2.x Modems and Terminals":
In particular:
[412]http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
For PC-based Solaris, also see general comments on PC-based Unixes in [413]Section 3.0. Don't expect Solaris or any other kind of Unix to work right on a PC until you resolve all interrupt conflicts. Don't expect to be able to use COM3 or COM4 (or even COM2) until you have configured their addresses and interrupts.
3.7.1. Serial Port Configuration
[ [414]Top ] [ [415]Contents ] [ [416]Section Contents ] [ [417]Section Contents ] [ [418]Next ]
Your serial port can't be used -- or at least won't work right -- until it is enabled in Solaris. For example, you get a message like "SERIAL: Operation would block" when attempting to dial. This probably indicates that the serial port has not been enabled for use with modems. You'll need to follow the instructions in your system setup or management manual, such as (e.g.) the Desktop SPARC Sun System & Network Manager's Guide, which should contain a section "Setting up Modem Software"; read it and follow the instructions. These might (or might not) include running a program called "eeprom", editing some system configuration file (such as, for example:
/platform/i86pc/kernel/drv/asy.conf
and then doing a configuration reboot, or running some other programs like drvconfig and devlinks. "man eeprom" for details.
Also, on certain Sun models like IPC, the serial port hardware might need to have a jumper changed to make it an RS-232 port rather than RS-423.
eeprom applies only to real serial ports, not to "Spiff" devices (serial port expander), in which case setup with Solaris' admintool is required.
Another command you might need to use is pmadm, e.g.:
pmadm -d -p zsmon -s tty3
pmadm -e -p zsmon -s tty3
You can use the following command to check if a process has the device
- open
fuser -f /dev/term/3
In some cases, however (according to Sun support, May 2001) "It is still possible that a zombie process has hold of the port EVEN IF there is no lock file and the fuser command comes up empty. In that case, the only way to resolve the problem is by rebooting."
If you can't establish communication through a serial port to a device that is not asserting CD (Carrier Detect), try setting the environment variable "ttya-ignore-cd" to "true" (replace "ttya" with the port name).
3.7.2. Serial Port Problems
[ [419]Top ] [ [420]Contents ] [ [421]Section Contents ] [ [422]Next ] [ [423]Previous ]
Current advice from Sun is to always the /dev/cua/x devices for dialing out, rather than the /dev/term/x. Nevertheless, if you have trouble dialing out with one, try the other.
Reporte