通讯/手机编程

开发平台：

Windows_Unix

ckubwr.txt：源码内容

CKUBWR.TXT "Beware File" for C-Kermit Version 7.0 -*- text -*-
C-KERMIT FOR UNIX
As of C-Kermit version: 7.0.197
This file last updated: 8 February 2000
Authors: Frank da Cruz and Christine M. Gianone, Columbia University.
Trustees of Columbia University in the City of New York.
copyright text in the ckcmai.c module for disclaimer and permissions.
WHAT IS IN THIS FILE
This is the "beware file" for the UNIX version of C-Kermit. It contains hints
and tips, frequently asked questions (and answers), troubleshooting advice,
limitations and restrictions, known bugs, unresolved reports, etc, that apply
to all UNIX variations, as well as to specific ones like HP-UX, AIX, Solaris,
SunOS, Unixware, NeXTSTEP, etc etc.
This file should be read in conjunction with the system-independent C-Kermit
beware file, ckcbwr.txt, which contains similar information, but applying to
all versions of C-Kermit (VMS, OS/2, AOS/VS, VOS, etc, as well as to UNIX).
CONTENTS
(0) DOCUMENTATION AND TECHNICAL SUPPORT
(0.1) THE C-KERMIT USER MANUAL
(0.2) TECHNICAL SUPPORT
(0.3) THE YEAR 2000
(0.4) THE EURO SYMBOL
(1) IMPORTANT FILES
(2) BINARIES
(3) NOTES ON SPECIFIC UNIX VERSIONS
(3.0) C-KERMIT ON PC-BASED UNIXES
(3.1) C-KERMIT AND AIX
(3.2) C-KERMIT AND HP-UX
3.2.0. Common Problems
3.2.1. Building C-Kermit on HP-UX
3.2.2. Performance
3.2.3. Dialing Out and UUCP Lockfiles in HP-UX
3.2.4. HP-UX 5.00
3.2.5. HP-UX 8.00
3.2.6. HP-UX 9.00 AND LATER
3.2.7. HP-UX 10.10 AND LATER
3.2.8. HP-UX and X.25
(3.3) C-KERMIT AND LINUX
3.3.1. Problems Building C-Kermit for Linux
3.3.2. Problems with Serial Devices in Linux
3.3.3. Terminal Emulation in Linux
3.3.4. Dates and Times
3.3.5. Startup Errors
(3.4) C-KERMIT AND NEXTSTEP
(3.5) C-KERMIT AND QNX
(3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER
(3.7) C-KERMIT AND SOLARIS
(3.8) C-KERMIT AND SUNOS
(3.9) C-KERMIT AND ULTRIX
(3.10) C-KERMIT AND UNIXWARE
(3.11) C-KERMIT AND APOLLO SR10
(3.12) C-KERMIT AND TANDY XENIX 3.0
(3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX)
(3.14) C-KERMIT AND SGI IRIX
(3.15) C-KERMIT AND THE BEBOX
(3.16) C-KERMIT AND DG/UX
(3.17) C-KERMIT AND SEQUENT DYNIX
(3.18) C-KERMIT AND {FREE,OPEN,NET}BSD
(4) GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
(5) INITIALIZATION AND COMMAND FILES
(6) COMMUNICATION SPEED SELECTION
(7) COMMUNICATIONS AND DIALING
(8) HARDWARE FLOW CONTROL
(9) TERMINAL CONNECTION AND KEY MAPPING
(10) FILE TRANSFER
(11) EXTERNAL FILE TRANSFER PROTOCOLS
(11.1) C-KERMIT AS AN EXTERNAL PROTOCOL
(11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
(11.3) USING C-KERMIT WITH TERM
(12) SECURITY
(13) MISCELLANEOUS USER REPORTS
(14) THIRD-PARTY DRIVERS
(0) DOCUMENTATION AND TECHNICAL SUPPORT
(0.1) THE C-KERMIT USER MANUAL
C-Kermit is documented in the book "Using C-Kermit" by Frank da Cruz and
Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1.
Price: US $44.95. To order, call Columbia University, New York City, at
+1 (212) 854-3703, or Digital Press / Butterworth-Heinemann at:
+1 800 366-2665 (Massachusetts office for USA & Canada)
+441 1993 414414 (Rushden, England office for Europe)
+61 2 372-5511 (Chatswood, NSW, office for Australia & New Zealand)
+65 220-3684 (Singapore office for Asia)
Or visit the Kermit website at http://www.columbia.edu/kermit/.
A German edition is available from Verlag Heinz Heise in Hannover, Germany,
Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 52-1 29.
If you do not have the manual, please purchase it. It explains how to use
C-Kermit, from getting started through advanced use and scripting, and sales
of the manual are the primary source of funding for C-Kermit development and
support.
New features added since "Using C-Kermit", 2nd Ed, was published are
documented in the ckermit2.txt file, which should be used as a supplement to
the manual until the 3rd edition is published.
(0.2) TECHNICAL SUPPORT
Please consult the manual, plus the ckcbwr.txt file and this file itself,
before submitting questions, reporting problems, etc, to:
E-Mail: kermit-support@columbia.edu
Web: http://www.columbia.edu/kermit/support.html
News: comp.protocols.kermit.misc
Post: The Kermit Project
Columbia University
612 West 115th Street
New York NY 10025-7799
USA
Fax: +1 212 663-8202
Telephone support is also available:
+1 212 854-5126, cost: $25.00 per call, payable via Visa or MC.
(0.3) THE YEAR 2000
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.
As of C-Kermit 6.0, 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 will still take 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.
(0.4) THE EURO SYMBOL
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.
(1) IMPORTANT FILES
In addition to the published documentation, the following files are useful
in troubleshooting:
ckaaaa.txt: Overview, file naming conventions, list of files, etc.
ckuins.txt: Installation instructions for UNIX C-Kermit.
ckccfg.txt: C-Kermit program configuration information.
ckcbwr.txt: C-Kermit "beware file" for all platforms.
ckubwr.txt: C-Kermit "beware file" for UNIX (this file).
ckcplm.txt: C-Kermit program logic manual.
ckermit2.txt: User documentation for features added since 6.0.192, and
since the 2nd Edition of "Using C-Kermit" was published.
ckcXXX.txt: Program edit history for edit XXX, e.g. ckc196.txt.
ckuker.mak: (or makefile) Makefile for UNIX C-Kermit.
ck[cuw]*.[chw]: Source code for UNIX C-Kermit.
Note that all of the *.txt files are renamed from their pre-7.0 names due
to Microsoft's usurpation of traditional text filetypes like .hlp and .doc
for its own purposes.
(2) BINARIES
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 refuses 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 many of the binaries are
contributed from elsewhere (after all, we don't have several hundred different
machines in-house to build them on), and in any case some platforms do not
even offer the option of static linking.
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 SunOS 4.1.2 on a SunOS 4.1.1 system. Sometimes
even the system-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 most 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 system 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
The following sections apply to specific UNIX versions.
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 system-dependent and often
obscure manner, and the effects (good or evil) are also highly system-
dependent. Many examples are given in the system-specific sections below.
An important point to keep in mind is that C-Kermit is a CROSS-PLATFORM,
PORTABLE 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 many 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 700+ different platforms. If you're a programmer,
take a look at the source code and send us your suggested fixes or changes.
Or else just send us a report about what seems to be wrong (see the TECHNICAL
SUPPORT section above for details).
(3.0) C-KERMIT ON PC-BASED UNIXES
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, most of which
are preallocated). Thus adding devices, using multiple serial ports, etc, is
always a challenge and usually a nightmare. The free-for-all nature of the PC
market and the lack of standards combined with the diversity of UNIX OS
versions makes 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, and don't expect to be able to use more than two serial ports at
the same time.
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."
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 or
"Plug-n-Play" devices are rarely supported on PC-based UNIX versions such as
SCO; Winmodems, Winprinters, and the like are not supported at all on any UNIX
to our knowledge (except Lucent has released a Linux-only driver for one of
its PCI "software" modems). The self-proclaimed Microsoft PC 97 (or later)
standard will probably only make 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), 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.
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 (unlike Windows) is
a true multitasking 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.
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.
Modems: External modems are recommended. 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:
http://www.o2.net/~gromitkc/winmodem.html
Multiple modems: Remember that PCs, even now -- 2 decades after the PC was
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 DigiBoard are available for certain UNIX platforms
(typically SCO, maybe Linux) that come with special platform-specific drivers.
Character sets: 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).
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), but several of these
are supported by C-Kermit 7.0 (1250, 1251, and 1252).
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, Alt-key combinations,
and the like. This is because (a) UNIX is a portable operating system, not
only for PCs; and (b) UNIX sessions can come from anywhere, not just the PC's
keyboard and screen.
(3.1) C-KERMIT AND AIX
For additional information see the AIX FAQ:
http://www.emerson.emory.edu/services/aix-faq/
http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html
http://aixpdslib.seas.ucla.edu/
ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix
and/or read the comp.unix.aix newsgroup.
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.
Streaming transfers into AIX 4.2 or 4.3 (through the AIX Telnet server) have
been observed to fail, when exactly the same kind of transfers into AIX 4.1
work without incident. The error reported by AIX is "interrupted system
call". Streaming transfers work perfectly, however, if the AIX Telnet server
is removed from the picture (e.g, by using "set host * 3000" on AIX, or by
using Rlogin instead of Telnet). They also work perfectly if the Telnet
connection is forced into binary mode (C-Kermit command "set telopt requested
requested"). In case of file-transfer failure on a Telnet connection to AIX
4.2 or 4.3, tell AIX C-Kermit to "set streaming off" and/or tell the file
sender to prefix all control characters ("set prefixing all"). Also be sure
that the AIX C-Kermit on the remote end has "set flow none" (which is the
default).
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 this is not verified.
IMPORTANT: Do NOT try to run AIX 3.x C-Kermit binaries on AIX 4.x (or vice
versa). Obtain -- or build -- the C-Kermit binary that is appropriate for
your AIX version. In general, it is always better to build from source code.
According to IBM's "From Strength to Strength" document (21 April 1998),
in AIX 4.2 and later "Async supports speeds on native serial ports up to
115.2kbps". However, no API is documented to achieve serial speeds higher
than 38400 bps. Apparently the way to do this -- which might or might not
work only on the IBM 128-port multiplexer -- is:
cxma-stty fastbaud /dev/tty0
which, according to "man cxma-stty":
fastbaud Alters the baud rate table, so 50 baud becomes 57600 baud.
-fastbaud Restores the baud rate table, so 57600 baud becomes 50 baud.
Presumably (but not certainly) this extrapolates to 110 "baud" becomes
76800 bps, and 150 becomes 115200 bps. So to use high serial speeds in AIX
4.2 or 4.3, the trick would be to give the "cxma-stty fastbaud" command for
the desired tty device before starting Kermit, and then use "set speed 50",
"set speed 110", or "set speed 150" to select 56700, 76800, or 115200 bps.
It is not known whether cxma-stty requires privilege.
According to one report, "Further investigation with IBM seems to indicate
that the only hardware capable of doing this is the 128-port multiplexor with
one (or more) of the 16 port breakout cables (Enhanced Remote Async Node
16-Port EIA-232). We are looking at about CDN$4,000 in hardware just to hang a
56kb modem on there. Of course, we can then hang 15 more, if we want. This
hardware combo is described to be good to 230.4kbps."
Another report says (quote from AIX newsgroup, March 1999):
The machine type and the adapter determine the speed that one can actually
run at. The older microchannel machines have much slower crystal
frequencies and may not go beyond 76,800. A feature put into AIX 421
allows one to key in non-POSIX baud rates and if the uart can support that
speed, it will get set. this applies also to 43p's and beyond. 115200 is
the max for the 43P's native serial port. As crytal frequencies continue
to increase, the built-in serial ports speeds will improve. To use 'uucp'
or 'ate' at the higher baud rates, configure the port for the desired
speed, but set the speed of uucp or ate to 50. Any non-POSIX speeds set
in the ttys configuration will the be used. In the case of the 128-port
adapters or the ISA 8-port or PCI 8-port adapter, there are only a few
higher baud rates.
a. Change the port to enable high baud rates:
B50 for 57600
B75 for 76800
B110 for 115200
B200 for 230000
b. chdev -l ttyX -a fastbaud=enable
For the 128 ports original style rans, only 57600 bps is supported.
For the new enhanced RANs, up to 230Kbps is supported.
(end quote)
Note that some RS/6000s (e.g. the IBM PowerServer 320) have nonstandard
rectangular 10-pin serial ports; the DB-25 connector is NOT a serial port;
it is a parallel printer port. IBM cables are required for the serial ports,
(The IBM RT PC also had rectangular serial ports -- perhaps the same as these,
perhaps different.)
If you dial in to AIX through a modem that is connected directly to an AIX
port (e.g. on the 128-port multiplexer) and find that data is lost, especially
when uploading files to the AIX system (and system error logs report buffer
overruns on the port):
1. Make sure the port and modem are BOTH configured for hardware (RTS/CTS)
flow control. The port is configured somewhere in the system
configuration, outside of Kermit.
2. Tell C-Kermit to "set flow keep"; experimentation shows that SET FLOW
RTS/CTS has no effect when used in remote mode (i.e. on /dev/tty, as
opposed to a specify port device).
Several people have reported that C-Kermit (version unspecified) causes
AIX 4.2 (or later) to "freeze" or "hang" or "halt". No further details are
known at this time. However:
1. No user-mode application should ever be able to make AIX or any other
version of UNIX freeze, hang, or halt; if it does, this indicates a
serious bug in AIX, which should be reported immediately to IBM.
2. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support
and other AIX bugs are available from IBM at:
http://service.software.ibm.com/rs6000/
Downloads -> Software Fixes -> Download FixDist gets an application
for looking up known problems.
Other people have reported that after upgrading AIX from 4.1 to 4.2, the "ttys
hang" when they try to use Kermit. Again, so far no further details are
available. However, others report that C-Kermit 6.0 works fine on both AIX
4.2 and 4.3 if it is rebuilt from source code. Still others report that the
original C-Kermit 6.0 binaries, built under AIX 4.1, work perfectly in AIX
4.2 and 4.3.
More recently, people have reported various kinds of problems running a
C-Kermit binary built under AIX 4.1 or 4.2 on AIX 4.3. There has been some
speculation on the newsgroups about a new round binary incompatibility between
AIX 4.3 and earlier versions -- some even suggest renumbered syscalls, but
that seems unlikely. Example: a user in Germany reported that the C-Kermit
6.0 AIX 4.1 binary would crash during file transfer when run on AIX 4.2, but
the problems disappeared when running a binary that was built on AIX 4.2.
C-Kermit 6.0.192 and earlier were built by default without "BIGBUFOK" defined
for AIX, and this limits the maximum size of macros, etc. In particular, it
affects the alphanumeric page macro (TAPMSG) distributed with C-Kermit 6.0.
BIGBUFOK should be defined, and it is in C-Kermit 6.1 and later. In the
meantime use:
make clean ; make aix??? KFLAGS=-DBIGBUFOK
Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports does not
work unless the port number is in the /etc/services file; it's not clear from
the report whether this is a problem with AIX Telnet (in which case it would
not affect Kermit), or with the sockets library (in which case it would). The
purported fix is IBM APAR IX61523.
Many problems reported with bidirectional terminal lines on AIX 3.2.x on the
RS/6000. Workaround: don't use bidirectional terminal lines, or write a
shell-script wrapper for Kermit that turns getty off on the line before
starting Kermit, or before Kermit attempts to do the SET LINE. (But note:
These problems MIGHT be fixed in C-Kermit 6.0 and later.) The commands for
turning getty off and on (respectively) are /usr/sbin/pdisable and
/usr/sbin/penable.
Reportedly, all versions of IBM AIX use the same (undocumented) lockfile
conventions as RTAIX. If this is true, the "makes" for PS/2 AIX and AIX/370
will have to be changed to use the RTAIX convention (it may be sufficient to
simply add -DRTAIX to the make entry). This should not be an issue in
C-Kermit 7.0 or later, which now calls the AIX ttlock() family of library
functions to create, check, and remove lockfiles. (But it is not known
which versions of AIX prior to 4.1 have working ttlock() functions; for
example, the functions are present in AIX 3.2 but do not seem to work).
C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to another
won't work right unless you set your local terminal type to something other
than AIXTERM. When your terminal type is AIXTERM, AIX TELNET sends two
escapes whenever you type one, and the AIX telnet server swallows one of them.
This has something to do with the "hft" device. This behavior seems to be
removed in AIX 3.2 and later.
Transfer of binary -- and maybe even text -- files can fail on AIX 3.x. The
problem was traced to a facility in AIX whereby a particular port can have
character-set translation done for it by the tty driver. The following
advice from a knowledgeable AIX user:
(begin quote...) [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. (...end quote) And this would
imply that Kermit itself cannot be coded to take care of this, because it
would have to run as root. On the same problem, another knowledgeable AIX
user says:
The way to get information on the NLS mapping under AIX (3.2.5 anyway) is
as follows. From the command line type:
lsattr -l tty# -a imap -a omap -E -H
Replace the tty number for the number sign above. This will give a human
readable output of the settings that looks like this;
# lsattr -l tty2 -a imap -a omap -E -H
attribute value description user_settable
imap none INPUT map file True
omap none OUTPUT map file True
If you change the -H to a -O, you get output that can easily be processed
by another program or a shell script, for example:
# lsattr -l tty2 -a imap -a omap -E -O
#imap:omap
none:none
To change the settings from the command line, the chdev command is used
with the following syntax.
chdev -l tty# -a imap='none' -a omap='none'
Again substituting the appropriate tty port number for the number sign,
"none" being the value we want for C-Kermit. Of course, the above can also
be changed by using the SMIT utility and selecting devices - tty.
(...end quote)
About AIX versions and hardware platforms (from the AIX FAQ):
If you are using IBM's xlc (cc) compiler, the default is to use the common
instruction set, so the same binary will run on both RS/6000 and PowerPC.
The option -mcpu=common makes GCC use the common instruction set. Please
note that (unlike xlc) this is *not* the default with GCC on AIX.
A couple of other gotcha's:
Use shared libraries. The C runtime can and does change as IBM introduces
patches. Also this avoids "Netscape syndrome." They bound AIX 3 libraries
into their browser. Although AIX 3 binaries will run on AIX 4, the AIX 3
libraries aren't totally compatible.
AIX 4.2 changed the C runtime radically. AIX 4.2 binaries won't run on AIX
4.1 or 3.anything. AIX 3 binaries run on AIX 4.1 and AIX 4.2.
Of course, the moment you take any of this as gospel, you'll get into big
trouble, but my own experience has pretty much jibed with the above.
(end quote)
"Is AIX Year 2000 Compliant?" According to a comp.unix.aix newsgroup posting
from IBM Austin, version 4.2 is; earlier versions such as 4.1.x and 3.2.5
require PTFs (which, as of Jan 1997, have not yet been issued).
Here is a sample configuration for setting up an xterm keyboard for VT220 or
higher terminal emulation on AIX, courtesy of Bruce Momjian, Drexel Hill, PA.
Xterm can be started like this:
xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220
-title vt220 -tn xterm-220 "$@" &
---------------------------------------------------------------------------
XTerm*VT100.Translations: #override n
<Key>Home: string(0x1b) string("[3~") n
<Key>End: string(0x1b) string("[4~") n
vt220*VT100.Translations: #override n
Shift <Key>F1: string("[23~") n
Shift <Key>F2: string("[24~") n
Shift <Key>F3: string("[25~") n
Shift <Key>F4: string("[26~") n
Shift <Key>F5: string("[K~") n
Shift <Key>F6: string("[31~") n
Shift <Key>F7: string("[31~") n
Shift <Key>F8: string("[32~") n
Shift <Key>F9: string("[33~") n
Shift <Key>F10: string("[34~") n
Shift <Key>F11: string("[28~") n
Shift <Key>F12: string("[29~") n
<Key>Print: string(0x1b) string("[32~") n
<Key>Cancel: string(0x1b) string("[33~") n
<Key>Pause: string(0x1b) string("[34~") n
<Key>Insert: string(0x1b) string("[2~") n
<Key>Delete: string(0x1b) string("[3~") n
<Key>Home: string(0x1b) string("[1~") n
<Key>End: string(0x1b) string("[4~") n
<Key>Prior: string(0x1b) string("[5~") n
<Key>Next: string(0x1b) string("[6~") n
<Key>BackSpace: string(0x7f) n
<Key>Num_Lock: string(0x1b) string("OP") n
<Key>KP_Divide: string(0x1b) string("Ol") n
<Key>KP_Multiply: string(0x1b) string("Om") n
<Key>KP_Subtract: string(0x1b) string("OS") n
<Key>KP_Add: string(0x1b) string("OM") n
<Key>KP_Enter: string(0x1b) string("OM") n
<Key>KP_Decimal: string(0x1b) string("On") n
<Key>KP_0: string(0x1b) string("Op") n
<Key>KP_1: string(0x1b) string("Oq") n
<Key>KP_2: string(0x1b) string("Or") n
<Key>KP_3: string(0x1b) string("Os") n
<Key>KP_4: string(0x1b) string("Ot") n
<Key>KP_5: string(0x1b) string("Ou") n
<Key>KP_6: string(0x1b) string("Ov") n
<Key>KP_7: string(0x1b) string("Ow") n
<Key>KP_8: string(0x1b) string("Ox") n
<Key>KP_9: string(0x1b) string("Oy") n
! <Key>Up: string(0x1b) string("[A") n
! <Key>Down: string(0x1b) string("[B") n
! <Key>Right: string(0x1b) string("[C") n
! <Key>Left: string(0x1b) string("[D") n
*visualBell: true
*saveLines: 1000
*cursesemul: true
*scrollKey: true
*scrollBar: true
(3.2) C-KERMIT AND HP-UX
For further information, read the comp.sys.hp.hpux newsgroup.
3.2.0. Common Problems
The following sequence:
set line /dev/cua0p0 ; or other device
set speed 19200 ; or other normal speed
produces the message "?Unsupported line speed". This means the port is not
configured for dialout. Go into SAM and configure the port for dialout.
Some HP workstations have a BREAK/RESET key. If you hit this key while
C-Kermit is running, it might kill or suspend the C-Kermit process. C-Kermit
arms itself against these signals, but evidently the BREAK/RESET key is -- at
least in some circumstances, on certain HP-UX versions -- too powerful to be
caught. (Some report that the first BREAK/RESET shows up as SIGINT and is
caught by C-Kermit's *former* SIGINT handler even when SIGINT is currently set
to SIG_IGN; the second kills Kermit; other reports suggest the first
BREAK/RESET sends a SIGTSTP (suspend) signal to Kermit, which it catches and
suspends itself.) You can tell C-Kermit to ignore suspend signals with SET
SUSPEND OFF. You can tell C-Kermit to ignore SIGINT with SET COMMAND
INTERRUPTION OFF. It is not known whether these commands also grant immunity
to the BREAK/RESET key (one report states that with SET SUSPEND OFF, the
BREAK/RESET key is ignored the first four times, but kills Kermit the 5th
time). In any case:
1. If this key is mapped to SIGINT or SIGTSTP, C-Kermit catches or ignores
it, depending on which mode (CONNECT, command, etc) Kermit is in.
2. If it causes HP-UX to kill C-Kermit, there is nothing C-Kermit can do to
prevent it.
When HP-UX is on the remote end of the connection, it is essential that HP-UX
C-Kermit be configured for Xon/Xoff flow control (this is the default, but in
case you change it and then experience file-transfer failures, this is a
likely reason).
3.2.1. Building C-Kermit on HP-UX
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 6.1 and 7.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 makefile), but doing so tends to make the compilations take a much
longer time. For example, the "hpux100o+" makefile entry 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 C-Kermit 7.0 makefile, all HP-UX entries automatically skip
optimization of problematic modules.
3.2.2. Performance
An unexpected slowness has been noted when transferring files over local
Ethernet connections when an HP-UX system (9.0 or later, perhaps also earlier
versions) is 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.
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. The test file was C-Kermit executable, transferred
in binary mode. Conditions were relatively poor: the Sun and the local net
heavily loaded; the HP system is old, slow, and memory-constrained.
C-Kermit 6.0... C-Kermit 7.0...
Local Remote ACK/NAK........ Streaming......
Client Server Send Receive Send Receive
Sun HP 36 18 64 18
HP HP 25 15 37 16
HP Sun 77 83 118 92
Sun Sun 60 60 153 158
So whenever HP is the remote we have poor performance. Why?
. Changing file display to CRT has no effect (so it's not the curses
library on the client side).
. Changing TCP RECV-BUFFER or SEND-BUFFER has little effect.
. Telling the client to make a binary-mode connection (SET TELNET BINARY
REQUESTED, which successfully negotiates a binary connection) has no
effect on throughput.
BUT... If I start C-Kermit as a TCP server:
set host * 3000
server
and then from the client "set host blah 3000", I get:
C-Kermit 6.0... C-Kermit 7.0...
Local Remote ACK/NAK........ Streaming......
Client Server Send Receive Send Receive
Sun HP 77 67 106 139
HP HP 50 50 64 62
HP Sun 57 85 155 105
Sun Sun 57 50 321 314
Therefore the HP-UX telnet server or pty driver seems to be adding more
overhead than the SunOS one, and most others. When going through this type of
connection (a remote telnet server) there is little Kermit can do improve
matters, since the telnet server and pty driver are between the two Kermits,
and neither Kermit program can have any influence over them (except putting
the Telnet connection in binary mode, but that doesn't help).
(The numbers for the HP-HP transfers are lower than the others since both
Kermit processes are running on the same slow CPU.)
3.2.3. Dialing Out and UUCP Lockfiles in HP-UX
Before you can use serial ports on the HP-9000, you must configure them as
either "terminals" or "modems" with SAM ("peripheral devices"..."terminals and
modems"), as described in the HP manual, "Configuring HP-UX for Peripherals:
HP 9000". If you attempt to use a serial device before it has been configured
this way, it will not work properly; typical symptoms are (a) no communication
at all; (b) nonfunctional modem signals; and/or (c) massive amounts of
character loss in both directions.
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:
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
diag:mux<X> diag:mux<D>
---------------------------------------------------------------------
ttyd* dial-in modems ttyd<YY> ttyd<X>p<Y> ttyd<D>p
diag:ttyd<X>p<Y> diag:ttyd<D>p
---------------------------------------------------------------------
cua* auto-dial out cua<YY> cua<X>p<Y> cua<D>p
diag:cua<X>p<Y>
---------------------------------------------------------------------
cul* dial-out cul<YY> cul<X>p<Y> cul<D>p
diag:cul<X>p<Y>
---------------------------------------------------------------------
<X>= LU (Logical Unit) <D>= Devspec (decimal card instance)
<Y> or <YY> = Port = Port
For dialing out, you should use the cua or cul devices. When C-Kermit's
CARRIER setting is AUTO or ON, C-Kermit should pop back to its prompt
automatically if the carrier signal drops, e.g. when you log out from the
remote computer or service. If you use the 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.
3.2.4. HP-UX 5.00
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 8.00
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.
And this report just in:
"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.6. HP-UX 9.00 AND LATER
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.7. HP-UX 10.10 AND LATER
C-Kermit is included as part of the HP-UX operating system by contract between
Hewlett Packard and Columbia University for all HP-UX releases 10.00 and
later. Each level of HP-UX includes a freshly built C-Kermit binary in
/bin/kermit, which should work correctly. However, if you are building your
own or downloading from Columbia, you should be aware that you can only use a
binary that was built under the same OS level as you are running. As of
C-Kermit version 6.0, HP-UX 10.xx / 11.xx binaries announce, in the startup
herald and the VERSION command, the explicit HP-UX version they were built
for: HP-UX 10.00, 10.01, 10.10, 10.20, 10.30, or 11.00. If there is a version
mismatch, HP-UX (not Kermit) is very likely to do something like "Invalid
version for shared lib /usr/lib/libc.1, IOT trap (core dumped)" during program
load.
Beginning in 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.
3.2.8. HP-UX and X.25
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 will work if padem uses standard i/o (see Section 2.7 of ckermit2.txt).
(3.3) C-KERMIT AND LINUX
For further information, read the comp.os.linux.misc, comp.os.linux.answers,
and other Linux-oriented newsgroups, and:
The Linux Document Project (LDP):
. http://sunsite.unc.edu/LDP/
The Linux FAQ:
. http://sunsite.unc.edu/LDP/FAQ/Linux-FAQ.html
The Linux HOWTOs (especially the Serial HOWTO):
. http://sunsite.unc.edu/LDP/HOWTO/Serial-HOWTO.html
. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
. ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
. http://sunsite.unc.edu/LDP/HOWTO/
. http://sunsite.unc.edu/LDP/hmirrors.html
Also see general comments on PC-based UNIXes in Section 3.0.
Did you know: DECnet is available for Linux? See:
http://linux.dreamtime.org/decnet/
(But there is no support for it in C-Kermit -- anybody interested in adding
it, please let me know.)
Before proceeding, let's handle the two most frequently asked question in
the Linux newsgroups:
1. Neither C-Kermit not any other Linux application can use Winmodems
(with one exception). See section 3.0 for details.
2. "Why does it take such a long time to make a telnet connection to (or
from) my Linux PC?" (this applies to C-Kermit or 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 cannot be
found by the 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.
C-Kermit itself performs reverse DNS lookups unless you tell it not to.
This is to allow C-Kermit to let you know which host it is actually
connected to in case you have made a connection to a "host pool"
(multihomed host). You can disable C-Kermit's reverse DNS lookup with
SET TCP REVERSE-DNS-LOOKUP OFF.
3.3.1. Problems Building C-Kermit for Linux
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. Note that you might also have to choose (separately) to install the
"curses" or "ncurses" terminal control library -- it is possible to install
the C compiler and linker, but omit the (n)curses library and headers. If
curses is not installed, you will not be able to build a version of C-Kermit
that supports the fullscreen file-transfer display, in which case you'll need
to use the "linuxnc" makefile target (nc = No Curses) or else install ncurses
before building.
Be sure to read the comments in the "linux:" makefile entry. There are all
sorts of confusing issues caused by the many and varied Linux distributions.
Some of the worst involve the curses library and header files: where are they,
what are they called, which ones are they really? Other vexing questions
involve libc5 vs libc6 vs glibc vs glibc2 (C libraries), gcc vs egcs vs lcc
(compilers), plus using or avoiding features that were added in a certain
version of Linux or a library or a distribution, and are not available in
others.
Linux C-Kermit, like all other UNIX C-Kermit versions, was built traditionally
with curses.h and the curses library. However, this library was evidently so
buggy (users reported that, after doing a file transfer using the fullscreen
display, "screen scrolling locks up" and the cursor "is stuck on the bottom of
the screen", etc), that a new curses library, called ncurses, was developed to
replace it. C-Kermit, as of version 6.1, uses ncurses rather than curses.
After modern practice, ncurses is dynamically linked, rather than linked into
the executable. This means a certain relationship must obtain between the
version number referenced in the executable and the version number of the
library. But there are evidently several different numbering systems for
libncurses.so -- e.g. 1.9.9e is another "name" for 3.0 -- but the program
loader doesn't know that and so won't run the program. Also the library
and/or terminfo database might be in a different place on the target system
(e.g. /usr/share/terminfo) than it was on the build system (e.g.
/usr/lib/terminfo). Solution: Create the appropriate symbolic links and/or
rebuild C-Kermit yourself from source code, and if you have additional
trouble, come back and read the rest of this section.
Of course static linking is also a possibility, but this makes the executable
MUCH bigger and introduces new problems of its own.
From the March 1999 Kermit newsgroup traffic:
: When I start Kermit (under Redhat Linux 5.2), it complains about not
: being able to recognise my terminal type - I've tried all the obvious
: terminal types - which ones can I use? Or can I get it to recognise
: xterm?
:
Assuming that you can use full screen programs, this looks identical to the
problem introduced by RedHat with 5.1. They moved the curses library, and
didn't [ leave a link from the old location to the new one ]:
To fix: cd /usr/share; ln -s terminfo ../lib
The termcap library is no longer referenced in the Linux target in the
makefile, since its functions are supposedly incorporated into the ncurses and
curses libraries. However, should any termcap-related entry points come up
undefined at link time (_tgetent, _tgoto, _tputs, etc), it might be necessary
to add -ltermcap back to LIBS. But then you might find that the termcap
library is not in /usr/lib after all, but has been moved to /usr/lib/termcap/,
in which case you'll need to make a symlink, or do something like:
"LIBS = -L/usr/lib/curses -lcurses -L/usr/lib/termcap -ltermcap"
Different UUCP lockfile conventions are used by different Linux versions
and/or distributions. In C-Kermit 6.0 and later, "make linux" uses
/var/lock/LCK..name, decimal ASCII 10-byte PID string with leading spaces
because -DLINUXFSSTND ("Linux File System Standard") is included in the
compilation CFLAGS. If you remove this definition, C-Kermit will use the
earlier arrangement of integer PID, /usr/spool/uucp/LCK..name. The leading
spaces are required by FSSTND 1.2, but FSSTND 1.0 required leading zeros; to
get the leading zeros, also include -DFSSTND10. Use whichever option agrees
with your uucp, cu, tip, etc, programs.
One user reported problems building C-Kermit under Linux 2.0.30/Slackware 96,
errors like:
/usr/include/linux/socket.h:77: warning: `PF_AAL5' redefined
/usr/local/include/socketbits.h:68: warning: this is the location of the
previous definition
ckutio.c:4679: `TIOCGSERIAL' undeclared (first use this function)
ckutio.c:4685: `TIOCSSERIAL' undeclared (first use this function)
ckutio.c:6092: warning: passing arg 3 of `select' from incompatible
pointer type
etc etc. Diagnosis: These were caused by installing some other package, which
created files in /usr/local/include. Cure: rm -rf /usr/local/include, and
start over.
Reportedly, building C-Kermit 6.0 on Linux 1.1.33 and 1.1.34 gets fatal
compilation errors due to inconsistencies in the Linux header files. Linux
kernel versions prior to 1.1.33 and later than 1.1.34 should be OK. (Also,
C-Kermit 6.1 and later should be OK since we no longer include kernel header
files.)
Reportedly there is a bug in gcc 2.5.8 with signed to unsigned compares
that can wreak havoc when Kermit (or most any other program) is compiled with
this version of gcc; reportedly this can be worked around, at least in part,
by adding "-fno-unroll-loops" to the gcc compilation options. (This problem
is evidently fixed in more recent gcc releases.)
Reportedly, if you have the iBCS2 (Intel Binary Compatibility Standard 2)
module installed, you can also run SCO Xenix and UNIX binaries under Linux,
including the SCO C-Kermit binaries, shareable libraries and all.
(iCBS2 is available via anonymous ftp from tsx-11.mit.edu, along with an
SCO libc_s compatibility module for Linux).
There is evidently a minor problem with GCC (version unknown) on (64-bit)
Alpha platforms, in which it complains:
warning: cast to pointer from integer of different size
whenever it encounters a legitimate trinary expression like:
integer ? "string1" : "string2"
(The "integer" can also be an integer-valued expression.) These warnings
appear to be harmless.
3.3.2. Problems with Serial Devices in Linux
Also see: "man setserial", "man irqtune".
And: Sections 3.0, 6, 7, and 8 of this document.
Don't expect it to be easy. Queries like the following are posted to the
Linux newsgroups almost daily:
Problem of a major kind with my Compaq Presario 1805 in the sense that
the pnpdump doesn't find the modem and the configuration tells me that
the modem is busy when I set everything by hand!
I have <some recent SuSE distribution>, kernel 2.0.35. Using the Compaq
tells me that the modem (which is internal) is on COM2, with the usual
IRQ and port numbers. Running various Windows diagnostics show me
AT-style commands exchanged so I have no reason to beleive that it is a
Winmodem. Also, the diagnostics under Win98 tell me that I am talking to
an NS 16550AN.
[Editor's note: This does not necessarily mean it isn't a Winmodem.]
Under Linux, no joy trying to talk to the modem on /dev/cua1 whether
via. minicom, kppp, or chat. kppp at least tells me that tcgetattr()
failed.
Usage of setserial ("setserial /dev/cua1 port 0x2F8 irq 3 autoconfig"
followed by "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.
Can anybody suggest something else for me to try?
(end quotes)
Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the like
(see cautions in 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).
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.
"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 occur in C-Kermit 7.0.)
"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 6.1 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 it out in favor of the ttyS device. See:
http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
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.
3.3.3. Terminal Emulation in Linux
Run C-Kermit in 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:
http://www.clark.net/pub/dickey/xterm/xterm.faq.html
Before starting C-Kermit in an xterm window, you might need to tell the xterm
window's shell to "stty sane".
To set up your PC console keyboard to send VT220 key sequences when using
C-Kermit as your communications program in an X terminal window (if it doesn't
already), create a file somewhere (e.g. in /root/) called .xmodmaprc,
containing something like the following:
keycode 77 = KP_F1 ! Num Lock => DEC Gold (PF1)
keycode 112 = KP_F2 ! Keypad / => DEC PF1
keycode 63 = KP_F3 ! Keypad * => DEC PF3
keycode 82 = KP_F4 ! Keypad - => DEC PF4
keycode 111 = Help ! Print Screen => DEC Help
keycode 78 = F16 ! Scroll Lock => DEC Do
keycode 110 = F16 ! Pause => DEC Do
keycode 106 = Find ! Insert => DEC Find
keycode 97 = Insert ! Home => DEC Insert
keycode 99 = 0x1000ff00 ! Page Up => DEC Remove
keycode 107 = Select ! Delete => DEC Select
keycode 103 = Page_Up ! End => DEC Prev Screen
keycode 22 = Delete ! Backspace sends Delete (127)
Then put "xmodmap <filename>" in your .xinitrc file (in your login
directory), e.g.
xmodmap /root/.xmodmaprc
Of course you can move things around. Use the xev program to find
out key codes.
Console-mode keys are mapped separately using loadkeys, and different
keycodes are used. Find out what they are with showkey.
3.3.4. Dates and Times
If C-Kermit's date-time (e.g. as shown by its DATE command) differs from
the system's date and time:
a. Make sure the libc to which Kermit is linked is set to GMT or is not
set to any time zone. Watch out for mixed libc5/libc6 systems; each
must be set indpendently.
b. If you have changed your TZ environment variable, make sure it is
exported. This is normally done in /etc/profile or /etc/TZ.
3.3.5. Startup Errors
C-Kermit 7.0 should work on all versions of Linux current through December
1999, provided it was built on the same version you have (just get the
source code and "make linux"). This is no guarantee that binaries built
for 7.0 release will not stop working at a later date, since Linux tends
to change out from under its applications, just as it did under C-Kermit 6.0
(libc/glibc, curses/ncurses, etc).
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 Kermit newsgroup:
From: rchandra@hal9000.buf.servtech.com ()
Newsgroups: comp.protocols.kermit.misc
Subject: Red Hat Linux/Intel 5.1 and ncurses: suggestions
Date: 22 Aug 1998 15:54:46 GMT
Organization: Verio New York
Keywords: RedHat RPM 5.1
Several factors can influence whether "linux" is recognized as a
terminal type on many Linux systems.
1.) Your program, or the libraries it linked with (if statically
linked), or the libraries it dynamically links with at runtime, are
looking for an entry in /etc/termcap that isn't there. (not likely,
but possible...I believe but am not certain that this is a very old
practice in very old [n]curses library implementations to use a
single file for all terminal descriptions.)
2.) Your program, or the libraries...are looking for a terminfo file
that just plain isn't there. (also not so likely, since many people
in other recent message threads said that other programs work OK).
3.) Your program, or the libraries...are looking for a terminfo file
that is stored at a pathname that isn't expected by your program,
the libraries--and so on. I forgot if I read this in the errata Web
page or where exactly I discovered this (Netscape install? Acrobat
install?), but it may just be that one libc (let's say for sake of
argument, libc5, but I don't know this to be true) expects your
terminfo to be in /usr/share/terminfo, and the other (let's say
libc6/glibc) expects /usr/lib/terminfo. I remember that the
specific instructions in this bugfix/workaround were to do the
following or equivalent:
cd /usr/lib
ln -s ../share/terminfo ./terminfo
- or -
ln -s /usr/share/terminfo /usr/lib/terminfo
So what this says is that the terminfo database/directory structure
can be accessed by either path. When something goes to reference
/usr/lib/terminfo, the symlink redirects it to essentially
/usr/share/terminfo, which is where it really resides on your
system. I personally prefer wherever possible to use relative
symlinks, because they still hold, more often than break, across
mount points, particularly NFS mounts, where the directory structure
may be different on the different systems.
(end quote) 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 report that installing the link fixes the problem.
(3.4) C-KERMIT AND NEXTSTEP
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 tty 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
See also: The 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.
The 32-bit version (and the 16-bit version prior to C-Kermit 7.0) support most
of C-Kermit's advanced features including TCP/IP, high serial speeds, hardware
flow-control, modem-signal awareness, curses support, etc.
BUG: In C-Kermit 6.0 and earlier 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 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/ser<n> 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 UUCP lockfile section ckuins.txt 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.
(3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER
See also:
. The comp.unix.sco.* newsgroups.
. http://www.sco.com/Support/ssl.html
. Section 3.10 below for Unixware
. The FAQ at ftp://rtfm.mit.edu/pub/usenet/news.answers/sco/newsgroups-faq
(which only covers newsgroups and mailing lists).
There is a general SCO FAQ, but I'm not sure where to find it. It is posted
to the newsgroups from time to time.
Also see general comments on PC-based UNIXes in Section 3.0.
Old Xenix versions... Did you know: Xenix 3.0 is *older* than Xenix 2.0?
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 :-)
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., Digiboard
drivers).
SCO OpenServer (all versions up to and included 5.0.5) 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.
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:
ftp://ftp.fu-berlin.de/pub/unix/driver/fas
Other users often make similar observations regarding Digi and other 3rd
party drivers.
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."
Hardware flow control is available in C-Kermit when the underlying SCO version
supports it. Note that Xenix 2.3.0 and later claims 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).
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 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.
SCO systems tend to use different names (i.e. drivers) for the same device.
In Xenix, /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). In the SCO case, C-Kermit always uses the
lowercase name when creating the UUCP lockfile (this is, according to SCO
experts, the proper behavior, but reportedly not all other communications
applications found on SCO systems follow this rule).
In SCO Xenix, you must use SET CARRIER ON *and* use the upper-case tty device
name in order to have carrier detection. SET CARRIER OFF should work with
either upper or lowercase tty devices. SET CARRIER AUTO is the same as OFF.
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 Section 14 of this file 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 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, 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