通讯/手机编程

开发平台：

Windows_Unix

ckubwr.txt：源码内容

SCO supplements are at ftp://ftp.sco.com/; the "rs40" series are
under directory /Supplements/internet
(end quote)
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 -- 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.7) C-KERMIT AND SOLARIS
See also:
The comp.unix.solaris newsgroup
http://access1.sun.com/
http://docs.sun.com/
http://www.sunhelp.com/
http://www.wins.uva.nl/pub/solaris/solaris2/
http://www.wins.uva.nl/cgi-bin/sfaq.cgi
ftp://ftp.wins.uva.nl/pub/solaris
And about serial communications in particular, see "Celeste's Tutorial on
Solaris 2.x Modems and Terminals":
http://www.stokely.com/
In particular:
http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
For PC-based Solaris, also see general comments on PC-based UNIXes in
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.
Even then your serial port can't be used -- or at least won't work right --
until it is enabled in Solaris. For example, you get a message like "SERIAL:
Operation would block" when attempting to dial. This probably indicates that
the serial port has not been enabled for use with modems. You'll need to
follow the instructions in your system setup or management manual, such as
(e.g.) the Desktop SPARC Sun System & Network Manager's Guide, which should
contain a section "Setting up Modem Software"; read it and follow the
instructions. These might (or might not) include running a program called
"eeprom", editing some system configuration file (such as, for example:
/platform/i86pc/kernel/drv/asy.conf
and then doing a configuration reboot, or running some other programs like
drvconfig and devlinks. "man eeprom" for details.
Also, on certain Sun models like IPC, the serial port hardware might need to
have a jumper changed to make it an RS-232 port rather than RS-423.
Some users report difficulties dialing out with C-Kermit on serial port when
using the /dev/cua/a name -- session seems to become stuck, can't escape back,
etc -- but when using the /dev/term/a name for the *same* device, everything
works fine. Explanation: unknown, but probably due to improper configuration
of the port; again, see the materials referenced above.
Reportedly, if you start C-Kermit and "set line" to a port that has a modem
connected to it that is not turned on, and then "set flow rts/cts", there
might be some (unspecified) difficulties closing the device (Solaris version
not specified).
The built-in SunLink X.25 support for Solaris 2.3/2.4./25 and SunLink 8.01 or
9.00 works OK provided the X.25 system has been installed and initialized
properly. Packet sizes might need to be reduced to 256, maybe even less,
depending on the configuration of the X.25 installation. On one connection
where C-Kermit 6.0 was tested, very large packets and window sizes could be
used in one direction, but only very small ones would work in the other.
In any case, according to Sun, C-Kermit's X.25 support is superfluous with
SunLink 8.x / Solaris 2.3. Quoting an anonymous Sun engineer:
... there is now no need to include any X.25 code within kermit. As of
X.25 8.0.1 we support the use of kermit, uucp and similar protocols over
devices of type /dev/xty. This facility was there in 8.0, and should
also work on the 8.0 release if patch 101524 is applied, but I'm not 100%
sure it will work in all cases, which is why we only claim support from
8.0.1 onwards.
When configuring X.25, on the "Advanced Configuration->Parameters" screen
of the x25tool you can select a number of XTY devices. If you set this
to be > 1, press Apply, and reboot, you will get a number of /dev/xty
entries created.
Ignore /dev/xty0, it is a special case. All the others can be used exactly
as if they were a serial line (e.g. /dev/tty) connected to a modem, except
that instead of using Hayes-style commands, you use PAD commands.
From kermit you can do a 'set line' command to, say, /dev/xty1, then set
your dialing command to be "CALL 12345678", etc. All the usual PAD
commands will work (SET, PAR, etc).
I know of one customer in Australia who is successfully using this, with
kermit scripts, to manage some X.25-connected switches. He used standard
kermit, compiled for Solaris 2, with X.25 8.0 xty devices.
C-Kermit can't be compiled successfully under Solaris 2.3 using SUNWspro cc
2.0.1 unless at least some of the following patches are applied to cc (it is
not known which one(s), if any, fix the problem):
100935-01 SparcCompiler C 2.0.1: bad code generated when addresses
of two double arguments are involved
100961-05 SPARCcompilers C 2.0.1: conditional expression with
function returning structure gives wrong value
100974-01 SparcWorks 2.0.1: dbx jumbo patch
101424-01 SPARCworks 2.0.1 maketool SEGV's instantly on Solaris 2.3
With unpatched cc 2.0.1, the symptom is that certain modules generate
truncated object files, resulting in many unresolved references at link time.
Using a Sun workstation keyboard for VT emulation when accessing VMS:
From: Jerry Leichter <leichter@smarts.com>
Newsgroups: comp.os.vms
Subject: Re: VT100 keyboard mapping to Sun X server
Date: Mon, 19 Aug 1996 12:44:21 -0400
> I am stuck right now using a Sun keyboard (type 5) on systems running SunOS
> and Solaris. I would like to use EVE on an OpenVMS box with display back to
> the Sun. Does anyone know of a keyboard mapping (or some other procedure)
> which will allow the Sun keyboard to approximate a VT100/VT220?
You can't get it exactly - because the keypad has one fewer key - but
you can come pretty close. Here's a set of keydefs I use:
keycode 101=KP_0
keycode 119=KP_1
keycode 120=KP_2
keycode 121=KP_3
keycode 98=KP_4
keycode 99=KP_5
keycode 100=KP_6
keycode 75=KP_7
keycode 76=KP_8
keycode 77=KP_9
keycode 52=KP_F1
keycode 53=KP_F2
keycode 54=KP_F3
keycode 57=KP_Decimal
keycode 28=Left
keycode 29=Right
keycode 30=KP_Separator
keycode 105=KP_F4
keycode 78=KP_Subtract
keycode 8=Left
keycode 10=Right
keycode 32=Up
keycode 33=Down
keycode 97=KP_Enter
Put this in a file - I use "keydefs" in my home directory and feed it
into xmodmap:
xmodmap - <$HOME/keydefs
This takes care of the arrow keys and the "calculator" key cluster. The
"+" key will play the role of the DEC "," key. The Sun "-" key will be
like the DEC "-" key, though it's in a physically different position -
where the DEC PF4 key is. The PF4 key is ... damn, I'm not sure where
"key 105" is. I *think* it may be on the leftmost key of the group of
four just above the "calculator" key cluster.
I also execute the following (this is all in my xinitrc file):
xmodmap -e 'keysym KP_Decimal = KP_Decimal'
xmodmap -e 'keysym BackSpace = Delete BackSpace'
-e 'keysym Delete = BackSpace Delete'
xmodmap -e 'keysym KP_Decimal = Delete Delete KP_Decimal'
xmodmap -e 'add mod1 = Meta_R'
xmodmap -e 'add mod1 = Meta_L'
Beware of one thing about xmodmap: Keymap changes are applied to the
*whole workstation*, not just to individual windows. There is, in fact,
no way I know of to apply them to individual windows. These definitions
*may* confuse some Unix programs (and/or some Unix users).
If you're using Motif, you may also need to apply bindings at the Motif
level. If just using xmodmap doesn't work, I can try and dig that stuff
up for you.
(end quote)
NOTE: The rest of the problems in this section have to do with bidirectional
tty lines and the Solaris Port Monitor. Hopefully these were all fixed in
C-Kermit 6.0.
Reportedly, "C-Kermit ... causes a SPARCstation running Solaris 2.3
to panic after the modem connects. I have tried compiling C-Kermit with Sun's
unbundled C compiler, with GCC Versions 2.4.5 and 2.5.3, with make targets
'sunos51', 'sunos51tcp', 'sunos51gcc', and even 'sys5r4', and each time it
compiles and starts up cleanly, but without fail, as soon as I dial the number
and get a 'CONNECT' message from the modem, I get:
BAD TRAP
kermit: Data fault
kernel read fault at addr=0x45c, pme=0x0
Sync Error Reg 80 <INVALID>
...
panic: Data Fault.
...
Rebooting...
The same modem works fine for UUCP/tip calling." Also (reportedly), this only
happens if the dialout port is configured as in/out via admintool. If it is
configured as out-only, no problem. This is the same dialing code that works
on hundreds of other System-V based UNIX OS's. Since it should be impossible
for a user program to crash the operating system, this problem must be chalked
up to a Solaris bug. Even if you SET CARRIER OFF, CONNECT, and dial manually
by typing ATDTnnnnnnn, the system panics as soon as the modem issues its
CONNECT message. (Clearly, when you are dialing manually, C-Kermit does not
know a thing about the CONNECT message, and so the panic is almost certainly
caused by the transition of the Carrier Detect (CD) line from off to on.)
This problem was reported by many users, all of whom say that C-Kermit worked
fine on Solaris 2.1 and 2.2. If the speculation about CD is true, then a
possible workaround might be to configure the modem to leave CD on (or off)
all the time. Perhaps by the time you read this, a patch will have been
issued for Solaris 2.3.
The following is from Karl S. Marsh, Systems & Networks Administrator,
AMBIX Systems Corp, Rochester, NY (begin quote):
"Environment:
Solaris 2.3 Patch 101318-45
C-Kermit 5A(189) (and presumably this applies to 188 and 190 also)
eeprom setting:
ttya-rts-dtr-off=false
ttya-ignore-cd=false
ttya-mode=19200,8,n,8,-
"To use C-Kermit on a bidirectional port in this environment, do not use
admintool to configure the port. Use admintool to delete any services running
on the port and then quit admintool and issue the following command:
pmadm -a -p zsmon -s ttyb -i root -fu -v 1 -m "`ttyadm -b -d /dev/term/b
-l conttyH -m ldterm,ttcompat -s /usr/bin/login -S n`"
[NOTE: This was copied from a fax, so please check it carefully] where:
-a = Add service
-p = pmtag (zsmon)
-s = service tag (ttyb)
-i = id to be associated with service tag (root)
-fu = create utmp entry
-v = version of ttyadm
-m = port monitor-specific portion of the port monitor administrative file
entry for the service
-b = set up port for bidirectional use
-d = full path name of device
-l = which ttylabel in the /etc/ttydefs file to use
-m = a list of pushable STREAMS modules
-s = pathname of service to be invoked when connection request received
-S = software carrier detect on or off (n = off)
"This is exactly how I was able to get Kermit to work on a bi-directional
port without crashing the system." (End quote)
On the Solaris problem, also see SunSolve Bug ID 1150457 ("Using C-Kermit, get
Bad Trap on receiving prompt from remote system"). Another user reported "So,
I have communicated with the Sun tech support person that submitted this bug
report [1150457]. Apparently, this bug was fixed under one of the jumbo
kernel patches. It would seem that the fix did not live on into 101318-45, as
this is EXACTLY the error that I see when I attempt to use kermit on my
system."
Later (Aug 94)... C-Kermit dialout successfully tested on a Sun4m with a
heavily patched Solaris 2.3. The patches most likely to have been relevant:
101318-50: SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
101720-01: SunOS 5.3: ttymon - prompt not always visible on a modem connection
101815-01: SunOS 5.3: Data fault in put() NULL queue passed from
ttycommon_qfull()
101328-01: SunOS 5.3: Automation script to properly setup tty ports prior to
PCTS execution
Still later (Nov 94): another user (Bo Kullmar in Sweden) reports that after
using C-Kermit to dial out on a bidirectional port, the port might not answer
subsequent incoming calls, and says "the problem is easy enough to fix with
the Serial Port Manager; I just delete the service and install it again using
the graphical interface, which underneath uses commands like sacadm and
pmadm." Later Bo reports, "I have found that if I run Kermit with the
following script then it works. This script is for /dev/cua/a, -s a is the
last a in /dev/cua/a
#! /bin/sh
kermit
sleep 2
surun pmadm -e -p zsmon -s a
(end quote)
(3.8) C-KERMIT AND SUNOS
For additional information, see "Celeste's Tutorial on SunOS 4.1.3+ Modems
and Terminals":
http://www.stokely.com/
For FAQs, etc, from Sun, see:
http://access1.sun.com/
Sun SPARCstation users should read the section "Setting up Modem Software" in
the Desktop SPARC Sun System & Network Manager's Guide. If you don't set up
your serial ports correctly, Kermit (and other communications software) won't
work right.
Also, on certain Sun models like IPC, the serial port hardware might need to
have a jumper changed to make it an RS-232 port rather than RS-423.
Reportedly, C-Kermit does not work correctly on a Sun SPARCstation in an Open
Windows window with scrolling enabled. Disable scrolling, or else invoke
Kermit in a terminal emulation window (xterm, crttool, vttool) under SunView
(this might be fixed in later SunOS releases).
On the Sun with Open Windows, an additional symptom has been reported:
outbound SunLink X.25 connections "magically" translate CR typed at the
keyboard into LF before transmission to the remote host. This doesn't happen
under SunView.
SET CARRIER ON, when used on the SunOS 4.1 version of C-Kermit (compiled in
the BSD universe), causes the program to hang uninterruptibly when SET LINE
is issued for a device that is not asserting carrier. When Kermit is built
in the Sys V universe on the same computer, there is no problem (it can be
interrupted with Ctrl-C). This is apparently a limitation of the BSD-style
tty driver.
SunOS 4.1 C-Kermit has been observed to dump core when running a complicated
script program under cron. The dump invariably occurs in ttoc(), while trying
to output a character to a TCP/IP TELNET connection. ttoc() contains a
write() call, and when the system or the network is very busy, the write()
call can get stuck for long periods of time. To break out of deadlocks caused
by stuck write() calls, there is an alarm around the write(). It is possible
that the core dump occurs when this alarm signal is caught. (This one has
not been observed recently -- possibly fixed in edit 190.)
On Sun computers with SunOS 4.0 or 4.1, SET FLOW RTS/CTS works only if the
carrier signal is present from the communication device at the time when
C-Kermit enters packet mode or CONNECT mode. If carrier is not sensed (e.g.
when dialing), C-Kermit does not attempt to turn on RTS/CTS flow control.
This is because the SunOS serial device driver does not allow characters to
be output if RTS/CTS is set (CRTSCTS) but carrier (and DSR) are not present.
Workaround (maybe): SET CARRIER OFF before giving the SET LINE command,
establish the connection, then SET FLOW RTS/CTS
It has also been reported that RTS/CTS flow control under SunOS 4.1 through
4.1.3 works only on INPUT, not on output, and that there is a patch from Sun
to correct this problem: Patch-ID# T100513-04, 20 July 1993 (this patch might
apply only to SunOS 4.1.3). It might also be necessary to configure the
eeprom parameters of the serial port; e.g. do the following as root at the
shell prompt:
eeprom ttya-ignore-cd=false
eeprom ttya-rts-dtr-off=true
There have been reports of file transfer failures on Sun-3 systems when using
long packets and/or large window sizes. One user says that when this happens,
the console issues many copies of this message:
chaos vmunix: zs1: ring buffer overflow
This means that SunOS is not scheduling Kermit frequently enough to service
interrupts from the zs serial device (Zilog 8350 SCC serial communication
port) before its input silo overflows. Workaround: use smaller packets
and/or a smaller window size, or use "nice" to increase Kermit's priority.
Use hardware flow control if available, or remove other active processes
before running Kermit.
SunLink X.25 support in C-Kermit 5A(190) has been built and tested
successfully under SunOS 4.1.3b and SunLink X.25 7.00.
(3.9) C-KERMIT AND ULTRIX
See also: The comp.unix.ultrix and comp.sys.dec newsgroups.
There is no hardware flow control in Ultrix. That's not a Kermit deficiency,
but an Ultrix one.
When sending files to C-Kermit on a Telnet connection to a remote Ultrix
system, you must SET PREFIXING ALL (or at least prefix more control characters
than are selected by SET PREFIXING CAUTIOUS).
Reportedly, DEC ULTRIX 4.3 is immune to C-Kermit's disabling of SIGQUIT,
which is the signal that is generated when the user types Ctrl-, which kills
the current process (i.e. C-Kermit) and dumps core. Diagnosis and cure
unknown. Workaround: before starting C-Kermit -- or for that matter, when you
first log in because this applies to all processes, not just Kermit -- give
the following UNIX command:
stty quit undef
Certain operations driven by RS-232 modem signal do not work on DECstations or
other DEC platforms whose serial interfaces use MMP connectors (DEC version of
RJ45 telephone jack with offset tab). These connectors convey only the DSR
and DTR modem signals, but not carrier (CD), RTS, CTS, or RI. Use SET CARRIER
OFF to enable communication, or "hotwire" DSR to CD.
The maximum serial speed on the DECstation 5000 is normally 19200, but various
tricks are available (outside Kermit) to enable higher rates. For example, on
the 5000/200, 19200 can be remapped (somehow, something to do with "a bit in
the SIR", whatever that is) to 38400, but in software you must still refer to
this speed as 19200; you can't have 19200 and 38400 available at the same time.
19200, reportedly, is also the highest speed supported by Ultrix, but NetBSD
reportedly supports speeds up to 57600 on the DECstation, although whether and
how well this works is another question.
In any case, given the lack of hardware flow control in Ultrix, high serial
speeds are problematic at best.
(3.10) C-KERMIT AND UNIXWARE
See also:
comp.unix.unixware.misc
comp.unix.sco.misc
Also see general comments on PC-based UNIXes in Section 3.0.
Note that in Unixware 2.0 and later, the preferred serial device names
(drivers) are /dev/term/00 (etc), rather than /dev/tty00 (etc).
Also note the following correspondence of device names and driver
characteristics:
New name Old name Description
/dev/term/00 /dev/tty00 ???
/dev/term/00h /dev/tty00h Modem signals and hardware flow control
/dev/term/00m /dev/tty00m Modem signals(?)
/dev/term/00s /dev/tty00s Modem signals and software flow control
/dev/term/00t /dev/tty00t ???
Lockfile names use device inode.major.minor numbers, e.g.:
/var/spool/locks/LK.7679.003.005
The minor number varies according to the device name suffix (none, h, m, s,
or t). Only the inode and major number are compared, and thus all of
the different names for the same physical device (e.g. all of those shown
in the table above) interlock effectively.
Prior to UnixWare 7, serial speeds higher than 38400 are not supported. In
UnixWare 7, we also support 57600 and 115200, plus some unexpected ones like
14400, 28800, and 76800, by virtue of a strange new interface, evidently
peculiar to UnixWare 7, discovered while digging through the header files:
tcsetspeed(). Access to this interface is allowed only in POSIX builds, and
thus the UnixWare 7 version of C-Kermit is POSIX-based, unlike C-Kermit for
Unixware 1.x and 2.x (since the earlier UnixWare versions did not support high
serial speeds, period).
HOWEVER, turning on POSIX features engages all of the "#if (!_POSIX_SOURCE)"
clauses in the UnixWare header files, which in turn prevent us from having
modem signals, access to the hardware flow control APIs, select(), etc -- in
short, all the other things we need in communications software, especially
when high speeds are used. Oh the irony. And so C-Kermit must be shamelessly
butchered -- as it has been so many times before -- to allow us to have the
needed features from the POSIX and non-POSIX worlds. See the UNIXWAREPOSIX
sections of ckutio.c.
Meanwhile the tcsetspeed() function allows any number at all (any long, 0 or
positive) as an argument and succeeds if the number is a legal bit rate for
the serial device, and fails otherwise. There is no list anywhere of legal
speeds. Thus the SET SPEED keyword table ("set speed ?" to see it) is
hardwired based on trial and error with all known serial speeds, the maximum
being 115200. However, to allow for the possibility that other speeds might
be allowed in the future (or with different port drivers), the SET SPEED
command for UnixWare 7 only allows you to specify any number at all; a warning
is printed if the number is not in the list, but the number is accepted
anyway; the command succeeds if tcsetspeed() accepts the number, and fails
otherwise.
Old business:
Using C-Kermit 6.0 on the UnixWare 1.1 Application Server, one user reported
a system panic when the following script program is executed:
set line /dev/tty4
set speed 9600
output 13
connect
The panic does not happen if a PAUSE is inserted:
set line /dev/tty4
set speed 9600
pause 1
output 13
connect
This is using a Stallion EasyIO card installed as board 0 on IRQ 12 on
a Gateway 386 with the Stallion-supplied driver. The problem was reported
to Novell and Stallion and (reportedly) is now fixed.
(3.11) C-KERMIT AND APOLLO SR10
Reportedly, version 5A(190), when built under Apollo SR10 using "make
sr10-bsd", compiles, links, and executes OK, but leaves the terminal unusable
after it exits -- the "cs7" or "cs8" (character size) parameter has become
cs5. The terminal must be reset from another terminal. Cause and cure
unknown. Suggested workaround: Wrap Kermit in a shell script something like:
kermit @*
stty sane
(3.12) C-KERMIT AND TANDY XENIX 3.0
C-Kermit 7.0 is too big to be built on Tandy Xenix, even in a minimum
configuration; version 6.0 is the last one that fits. In C-Kermit 6.0:
Reportedly, if you type lots of Ctrl-C's during execution of the
initialization file, ghost Kermit processes will be created, and will compete
for the keyboard. They can only be removed via "kill -9" from another
terminal, or by rebooting. Diagnosis -- something strange happening with
the SIGINT handler while the process is reading the directory (it seems to
occur during the SET PROMPT [v(dir)] ... sequence). Cure: unknown.
Workaround: don't interrupt C-Kermit while it is executing its init file on
the Tandy 16/6000.
(3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX)
Before you can use a serial port on a new Digital Unix system, you must run
uucpsetup to enable or configure the port. Evidently the /dev/tty00 and 01
devices that appear in the configuration are not usable; uucpsetup turns them
into /dev/ttyd00 and 01, which are. Note that uucpsetup and other uucp-family
programs are quite primitive -- they only know about speeds up to 9600 bps and
their selection of modems dates from the early 1980s. None of this affects
Kermit, though -- with C-Kermit, you can use speeds up to 115200 bps (at least
in DU4.0 and later) and modern modems with hardware flow control and all the
rest.
Reportedly, if a modem is set for &S0 (assert DSR at all times), the system
resets or drops DTR every 30 seconds; reportedly DEC says to set &S1.
Digital UNIX 3.2 evidently wants to believe your terminal is one line longer
than you say it is, e.g. when a "more" or "man" command is given. This is has
nothing to do with C-Kermit, but tends to annoy those who use Kermit or other
terminal emulators to access Digital UNIX systems. Workaround: tell UNIX
to "stty rows 23" (or whatever).
Reportedly, there is some bizarre behavior when trying to use a version of
C-Kermit built on Digital Unix 4.0 on another, possibly due to differing
OS or library revision levels; for example, the inability to connect to
certain TCP/IP hosts. Solution: rebuild C-Kermit from source code on the
system where you will be using it.
Digital UNIX tgetstr() causes a segmentation fault. C-Kermit 7.0 includes
#ifdefs to avoid calling this routine in Digital UNIX. As a result, the
SCREEN commands always send ANSI escape sequences -- even though curses knows
your actual terminal type.
(3.14) C-KERMIT AND SGI IRIX
See also:
The comp.sys.sgi.misc and .admin newsgroups.
The SGI FAQ:
http://www-viz.tamu.edu/~sgi-faq/
ftp://viz.tamu.edu/pub/sgi/faq/
About IRIX version numbers: "uname -a" tells the "two-digit" version number,
such as "5.3" or "6.5". The three-digit form can be seen with "uname -R".
(this information is unavailable at the simple API level). Supposedly all
three-digit versions within the same two-digit version (e.g. 6.5.2, 6.5.3) are
binary compatible; i.e. a binary built on any one of them should run on all
others. The "m" suffix denotes just patches; the "f" suffix indicates that
features were added.
SGI did not supply an API for hardware flow control prior to IRIX 5.2.
C-Kermit 6.1 and higher for IRIX 5.2 and higher supports hardware flow control
in the normal way, via "set flow rts/cts".
For hardware flow control on earlier IRIX and/or C-Kermit versions, use the
ttyf* (modem control AND hardware flow control) devices and not the ttyd*
(direct) or ttym* (modem control but no hardware flow control) ones, and
obtain the proper "hardware handshaking" cable from SGI, which is incompatible
with the ones for the Macintosh and NeXT even though they look the same. "man
serial" for further info.
Serial speeds higher than 38400 are available in IRIX 6.2 and later, on
O-class machines (e.g. Origin, Octane) only, and are supported by C-Kermit 6.1
and later. Commands such as "set speed 115200" may be given on other models
(e.g. Iris, Indy, Indigo) but will fail because the OS reports an invalid
speed for the device.
Experimentation with both IRIX 5.3 and 6.2 shows that when logged in to IRIX
via Telnet, that remote-mode C-Kermit can't send files if the packet length is
greater than 4096; the Telnet server evidently has this restriction (or bug),
since there is no problem sending long packets on serial or rlogin
connections. However, it can receive files with no problem if the packet
length is greater than 4096. As a workaround, the FAST macro for IRIX
includes "set send packet-length 4000". IRIX 6.5.1 does not have this
problem, so evidently it was fixed some time after IRIX 6.2. Tests show
file-transfer speeds are better (not worse) with 8K packets than with 4K
packets from IRIX 6.5.1.
Reportedly some Indys have bad serial port hardware. IRIX 5.2, for example,
needs patch 151 to work around this; or upgrade to a later release.
Similarly, IRIX 5.2 has several problems with serial i/o, flow control, etc.
Again, patch or upgrade.
Reportedly on Silicon Graphics (SGI) machines with IRIX 4.0, Kermit cannot be
suspended by typing the suspend ("swtch") character if it was started from
csh, even though other programs can be suspended this way, and even though the
Z and SUSPEND commands still work correctly. This is evidently because IRIX's
csh does not deliver the SIGTSTP signal to Kermit. The reason other programs
can be suspended in the same environment is probably that they do not trap
SIGTSTP themselves, so the shell is doing the suspending rather than the
application.
Also see notes about IRIX 3.x in ckcuins.txt.
(3.15) C-KERMIT AND THE BEBOX
See also: The comp.sys.be newsgroup.
The BeBox has been discontinued and BeOS repositioned for PC platforms.
The POSIX parts of BeOS are not finished, nor is the sockets library,
therefore a fully functional version of C-Kermit is not possible.
In version 6.0 of C-Kermit, written for BeOS DR7, it was possible to:
- set line /dev/serial2 (and probably the other serial ports)
- set speed 115200 (and at least some of the lower baud rates)
- connect
- set modem type hayes (and likely others, too)
- dial [phone number]
- set send packet length 2048 (other lengths for both send and receive)
- set receive packet length 2048
- set file type binary (text mode works, too)
(with remote kermit session in server mode)
- put bedrop.jpg
- get bedrop.jpg
- get bedrop.jpg bedrop.jpg2
- finish, bye
The following do not work:
- kermit does not detect modem hangup
- !/RUN/PUSH [commandline command]
- running kermit in remote mode
- using other protocols (x/y/zmodem)
- TCP networking interface (Be's TCP/IP API has a ways to go, still)
C-Kermit does not work on BeOS DR8 because of changes in the underlying APIs.
Unfortunately not enough changes were made to allow the regular POSIX-based
C-Kermit to work either. Note: the lack of a fork() service requires the
select()-based CONNECT module, but there is no select(). There is a select()
in DR8, but it doesn't work.
C-Kermit 7.0 has been built for BeOS 4.5 and it works in remote mode.
It does not include networking support since the APIs are still not there.
It is not known if dialing out works, but probably not.
(3.16) C-KERMIT AND DG/UX
Somebody downloaded the C-Kermit 6.0 binary built under DG/UX 5.40 and ran it
under DG/UX 5.4R3.10 -- it worked OK except that file dates for incoming files
were all written as 1 Jan 1970. Cause and cure unknown. Workaround: SET
ATTRIBUTE DATE OFF. Better: Use a version of C-Kermit built under and for
DG/UX 5.4R3.10.
(3.17) C-KERMIT AND SEQUENT DYNIX
Reportedly, when coming into a Sequent UNIX (DYNIX) system through an X.25
connection, Kermit doesn't work right because the Sequent's FIONREAD ioctl
returns incorrect data. To work around, use the 1-character-at-a-time version
of myread() in ckutio.c (i.e. undefine MYREAD in ckutio.c and rebuild the
program). This is unsatisfying because two versions of the program would be
needed -- one for use over X.25, and the other for serial and TCP/IP
connections.
(3.18) C-KERMIT AND {FREE,OPEN,NET}BSD
Some NebBSD users have reported difficulty escaping back from CONNECT mode,
usually when running NetBSD on non-PC hardware. Probably a keyboard issue.
NetBSD users have also reported that C-Kermit doesn't pop back to the prompt
if the modem drops carrier. This needs to be checked out & fixed if possible.
(All of this seems to work properly in C-Kermit 7.0.)
(4) GENERAL UNIX-SPECIFIC HINTS, LIMITATIONS, AND BUGS
In version 6.0, the default C-Kermit prompt includes your current (working)
directory; for example:
[/usr/olga] C-Kermit>
If that directory is on an NFS-mounted disk, and NFS stops working or the
disk becomes unavailable, C-Kermit will hang waiting for NFS and/or the disk
to come back. Whether you can interrupt C-Kermit when it is hung this way
depends on the specific OS. Kermit has called the operating systems's
getcwd() function, and is waiting for it to return. Some versions of UNIX
(e.g. HP-UX 9.x) allow this function to be interrupted with SIGINT (Ctrl-C),
others (such as HP-UX 8.x) do not. To avoid this effect, you can always
use SET PROMPT change your prompt to something that does not involve calling
getcwd(), but if NFS is not responding, C-Kermit will still hang any time you
give a command that refers to an NFS-mounted directory. Also note that in some
cases, the uninterruptibility of NFS-dependent system or library calls is
considered a bug, and sometimes there are patches. For HP-UX, for example:
replaced by:
HP-UX 10.20 libc PHCO_8764 PHCO_14891/PHCO_16723
HP-UX 10.10 libc PHCO_8763 PHCO_14254/PHCO_16722
HP-UX 9.x libc PHCO_7747 S700 PHCO_13095
HP-UX 9.x libc PHCO_6779 S800 PHCO_11162
You might have reason to make C-Kermit the login shell for a specific user,
by entering the pathname of Kermit (possibly with command-line switches, such
as -x to put it in server mode) into the shell field of the /etc/passwd file.
This works pretty well. In some cases, for "ultimate security", you might
want to use a version built with -DNOPUSH (see ckccfg.txt) for this, but even
if you don't, then PUSHing or shelling out from C-Kermit just brings up a
new copy of C-Kermit (but warning: this does not prevent the user from
explicitly running a shell; e.g. "run /bin/sh"; use NOPUSH to prevent this).
C-Kermit will not work as expected on a remote UNIX system, when used through
the "splitvt" or GNU "screen" programs. In this case, terminal connections to
the remote UNIX system work, but attempts to transfer files fail because the
screen optimization (or at least, line wrapping, control-character absorption)
done by this package interferes with Kermit's packets.
The same can apply to any other environment in which the user's session is
captured, monitored, recorded, or manipulated. Examples include the 'script'
program (for making a typescript of a session), the Computronics PEEK package
and pksh (at least versions of it prior to 1.9K), and so on.
You might try the following -- what we call "doomsday Kermit" -- settings to
push packets through even the densest and most obstructive connections, such
as "screen" and "splitvt" (and certain kinds of 3270 protocol emulators):
Give these commands to BOTH Kermit programs:
SET FLOW NONE
SET CONTROL PREFIX ALL
SET RECEIVE PACKET-LENGTH 70
SET RECEIVE START 62
SET SEND START 62
SET SEND PAUSE 100
SET BLOCK B
If it works, it will be slow.
On UNIX workstations equipped with DOS emulators like SoftPC, watch out for
what these emulators do to the serial port drivers. After using a DOS
emulator, particularly if you use it to run DOS communications software, you
might have to reconfigure the serial ports for use by UNIX.
On AT&T 7300 (3B1) machines, you might have to "stty nl1" before starting
C-Kermit. Do this if characters are lost during communications operations.
Under the bash shell (versions prior to 1.07 from CWRU), "pushing" to an
inferior shell and then exiting back to Kermit leaves Kermit in the background
such that it must be explicitly fg'd. This is reportedly fixed in version
1.07 of bash.
Interruption by Ctrl-Z makes UNIX C-Kermit try to suspend itself with
kill(0,SIGSTOP), but only on systems that support job control, as determined
by whether the symbol SIGTSTP is defined (or on POSIX or SVR4 systems, if
syconf(_SC_JOB_CONTROL) or _POSIX_JOB_CONTROL in addition to SIGTSTP).
However, if Kermit is running under a login shell (such as the original Bourne
shell) that does not support job control, the user's session hangs and must be
logged out from another terminal, or hung up on. There is no way Kermit can
defend itself against this. If you use a non-job control shell on a computer
that supports job control, give a command like "stty susp undef" to fix it so
the suspend signal is not attached to any particular key, or give the command
SET SUSPEND OFF to C-Kermit, or build C-Kermit with -DNOJC.
Reportedly, the UNIX C-Kermit server, under some conditions, on certain
particular systems, fails to log out its login session upon receipt of a
BYE command. Before relying on the BYE command working, test it a few times
to make sure it works on your system: there might be system configuration or
security mechanisms to prevent an inferior process (like Kermit) from
killing a superior one (like the login shell).
(5) INITIALIZATION AND COMMAND FILES
C-Kermit's initialization file for UNIX is .kermrc (lowercase, starts with
period) in your home directory, unless Kermit was built with the system-wide
initialization-file option (see ckuins.txt).
C-Kermit identifies your home directory based on the environment variable,
HOME. Most UNIX systems set this variable automatically when you log in. If
C-Kermit can't find your initialization file, check your HOME variable:
echo $HOME (at the UNIX prompt)
or:
echo $(HOME) (at the C-Kermit prompt)
If HOME is not defined, or is defined incorrectly, add the appropriate
definition to your UNIX .profile or .login file, depending on your shell:
setenv HOME full-pathname-of-your-home-directory (C-Shell, .login file)
or:
HOME=full-pathname-of-your-home-directory (sh, ksh, .profile file)
export HOME
NOTE: Various other operations depend on the correct definition of HOME.
These include the "tilde-expansion" feature, which allows you to refer to
your home directory as "~" in filenames used in C-Kermit commands, e.g.
send ~/.kermrc
as well as the v(home) variable.
Prior to version 5A(190), C-Kermit would look for its initialization file in
the current directory if it was not found in the home directory. This feature
was removed from 5A(190) because it was a security risk. Some people, however,
liked this behavior and had .kermrc files in all their directories that would
set up things appropriately for the files therein. If you want this behavior,
you can accomplish it in various ways, for example:
. Create a shell alias, for example:
alias kd="kermit -Y ./.kermrc"
. Create a .kermrc file in your home directory, whose contents are:
take ./.kermrc
The TAKE command does not search your UNIX PATH for command files. If a
command file is not in the current directory, you must give a full path
specification for it. This poses a problem for TAKE commands that are
themselves in TAKE files. See the trick used in CKETEST.INI...
Suppose you need to pass a password from the UNIX command line to a C-Kermit
script program, in such a way that it does not show up in "ps" or "w" listings.
Here is a method (not guaranteed to be 100% secure, but definitely more secure
than the more obvious methods):
echo mypassword | kermit myscript
The "myscript" file contains all the commands that need to be executed during
the Kermit session, up to and including EXIT, and also includes an ASK or ASKQ
command to read the password from standard input, which has been piped in from
the UNIX 'echo' command, but it must not include a CONNECT command. Only
"kermit myscript" shows up in the ps listing.
(6) COMMUNICATION SPEED SELECTION
Version-7 based UNIX implementations, including 4.3 BSD and earlier and UNIX
systems based upon BSD, use a 4-bit field to record a serial device's terminal
speed. This leaves room for 16 speeds, of which the first 14 are normally:
0, 50, 75, 110, 134.5, 150, 200, 300, 600, 1200, 1800, 2400, 4800, and 9600
The remaining two are usually called EXTA and EXTB, and are defined by the
particular UNIX implementation. C-Kermit determines which speeds are
available on your system based on whether symbols for them are defined in your
terminal device header files. EXTA is generally assumed to be 19200 and EXTB
38400, but these assumptions might be wrong, or they might not apply to a
particular device that does not support these speeds. Presumably, if you try
to set a speed that is not legal on a particular device, the driver will
return an error, but this can not be guaranteed.
On these systems, it is usually not possible to select a speed of 14400 bps
for use with V.32bis modems. In that case, use 19200 or 38400 bps, configure
your modem to lock its interface speed and to use RTS/CTS flow control, and
tell C-Kermit to SET FLOW RTS/CTS and SET DIAL SPEED-MATCHING OFF.
The situation is similar, but different, in System V. SVID Third Edition
lists the same speeds, 0 through 38400.
Some versions of UNIX, and/or terminal device drivers that come with
certain third-party add-in high-speed serial communication interfaces, use the
low "baud rates" to stand for higher ones. For example, SET SPEED 50 gets you
57600 bps; SET SPEED 75 gets you 76800; SET SPEED 110 gets 115200.
SCO ODT 3.0 is an example where a "baud-rate-table patch" can be applied that
can rotate the tty driver baud rate table such that 600=57600 and 1800=115k
baud. Similarly for Digiboard multiport/portservers, which have a
"fastbaud" setting that does this. Linux has a "setserial" command that can
do it, etc.
More modern UNIXes support POSIX-based speed setting, in which the selection
of speeds is not limited by a 4-bit field. C-Kermit 6.1 incorporates a new
mechanism for finding out (at compile time) which serial speeds are supported
by the operating system that does not involve editing of source code by hand;
on systems like Solaris 5.1, IRIX 6.2, and SCO OSR5.0.4, "set speed ?" will
list speeds up to 460800 or 921600. In C-Kermit 7.0:
1. If a symbol for a particular speed (say B230400 for 230400 bps) appears
in whatever header file defines acceptable serial speeds (e.g. <termbits.h>
or <sys/termios.h> or <sys/ttydev.h>, etc), the corresponding speed will
appear in C-Kermit's "set speed ?" list.
2. The fact that a given speed is listed in the header files and appears in
C-Kermit's list does not mean the driver will accept it. For example,
a computer might have some standard serial ports plus some add-on ones
with different drivers that accept a different repertoire of speeds.
3. The fact that a given speed is accepted by the driver does not guarantee
the underlying hardware can accept it.
When Kermit is given a "set speed" command for a particular device, the
underlying system service is called to set the speed; its return code is
checked and the SET SPEED command fails if the return code indicates failure.
Regardless of the system service return status, the device's speed is then
read back and if it does not match the speed that was requested, an error
message is printed and the command fails.
Even when the command succeeds, this does not guarantee successful operation
at a particular speed, especially a high one. That depends on electricity,
information theory, etc. How long is the cable, what is its capacitance, how
well is it shielded, etc, not to mention that every connection has two ends
and its success depends on both of them. (With the obvious caveats about
internal modems, is the cable really connected, interrupt conflicts, etc etc
etc).
Note, in particular, that there is a certain threshold above which modems can
not "autobaud" -- i.e. detect the serial interface speed when you type AT (or
whatever else the modem's recognition sequence might be). Such modems need to
be engaged at a lower speed (say 2400 or 9600 or even 115200 -- any speed
below their autobaud threshold) and then must be given a modem-specific
command (which can be found in the modem manual) to change their interface
speed to the desired higher speed, and then the software must also be told to
change to the new, higher speed.
For additional information, read the section TERMINAL SPEEDS in ckuins.txt,
plus any platform-specific notes in Section (3) above.
(7) COMMUNICATIONS AND DIALING
If you SET LINE to a serial port modem-control device that has nothing plugged
in to it, or has a modem connected that is powered off, and you have not given
a prior SET MODEM TYPE or SET CARRIER-WATCH OFF command, the SET LINE command
is likely to hang. In most cases, you can Ctrl-C out. If not, you'll have to
kill C-Kermit from another terminal.
Similarly, if you give a SET MODEM TYPE HAYES (or USR, or any other modem type
besides DIRECT, NONE, or UNKNOWN) and then SET LINE to an empty port, the
subsequent close (implicit or explicit) is liable to hang or even crash
(through no fault of Kermit's -- the hanging or crashing is inside a system
call such as cfsetospeed() or close()).
The SET CARRIER-WATCH command works as advertised only if the underlying
operating system and device drivers support this feature; in particular only
if a read() operation returns immediately with an error code if the carrier
signal goes away or, failing that, if C-Kermit can obtain the modem signals
from the device driver (you can tell by giving a "set line" command to a
serial device, and then a "show communications" command -- if modem signals
are not listed, C-Kermit won't be able to detect carrier loss, the WAIT
command will not work, etc). Of course, the device itself (e.g. modem) must
be configured appropriately and the cables convey the carrier and other needed
signals, etc.
If you dial out from UNIX system, but then notice a lot of weird character
strings being stuck into your session at random times (especially if they look
like +++ATQ0H0 or login banners or prompts), that means that getty is also
trying to control the same device. You'll need to dial out on a device that
is not waiting for a login, or else disable getty on the device.
In version 7.0, C-Kermit makes a lot of explicit checks for the Carrier Detect
signal, and so catches hung-up connections much better than 6.0 and earlier.
However, it still can not be guaranteed to catch every ever CD on-to-off
transition. For example, when the HP-UX version of C-Kermit is in CONNECT
mode on a dialed connection and CARRIER-WATCH ON or AUTO, and you turn off
the modem, HP-UX is stuck in a read() that never returns. (C-Kermit does not
pop back to its prompt automatically, but you can still escape back.)
If, on the other hand, you log out from the remote system, and it hangs up,
and CD drops on the local modem, C-Kermit detects this and pops back to the
prompt as it should. (Evidently there can be a difference between CD and DSR
turning off at the same time, versus CD turning off while DSR stays on;
experimentation with &S0/&S1/&S2 on your modem might produce the desired
results).
When UNIX C-Kermit exits, it closes (and must close) the communications
device. If you were dialed out, this will most likely hang up the connection.
If you want to get out of Kermit and still use Kermit's communication device,
you have several choices:
1. Shell out from Kermit or suspend Kermit, and refer to the device literally
(as in "term -blah -blah < /dev/cua > /dev/cua").
2. Shell out from Kermit and use the device's file descriptor which Kermit
makes available to you in the v(ttyfd) variable.
3. Use C-Kermit's REDIRECT command. See the ckermit2.txt file about this.
4. Use C-Kermit new EXEC /REDIRECT command, also described in ckermit2.txt.
If you are having trouble dialing:
1. Make sure the dialout line is configured correctly. More
about this below.
2. Make sure all necessary patches are installed for your operating
system.
3. If you can't dial on a "bidirectional" line, then configure it for
outbound-only (remove the getty) and try again. (The mechanisms -- if
any -- for grabbing bidirectional lines for dialout vary wildly
among UNIX implementations and releases, and C-Kermit -- which runs on
well over 300 different UNIX variations -- makes no effort to keep up
with them; the recommended method for coping with this situation is to
wrap C-Kermit in a shell script that takes the appropriate actions.)
4. Make sure C-Kermit's SET DIAL and SET MODEM parameters agree with the
modem you are actually using -- pay particular attention to SET DIAL
SPEED-MATCHING.
5. Try SET DIAL HANGUP OFF before the DIAL command. Also, SET DIAL DISPLAY
ON to watch what's happening. See section 8 of ckuins.txt.
6. Read pages 50-67 of "Using C-Kermit".
7. As a last resort, don't use the DIAL command at all; SET CARRIER OFF and
CONNECT to the modem and dial interactively, or write a script program to
dial the modem.
Make sure your dialout line is correctly configured for dialing out (as
opposed to login). The method for doing this is different for each kind of
UNIX system. Consult your system documentation for configuring lines for
dialing out (for example, SUN SparcStation IPC users should read the section
"Setting up Modem Software" in the Desktop SPARC Sun System & Network
Manager's Guide; HP-9000 workstation users should consult the manual
"Configuring HP-UX for Peripherals", etc).
Symptom: DIAL works, but a subsequent CONNECT command does not. Diagnosis:
the modem is not asserting Carrier Detect (CD) after the connection is made,
or the cable does not convey the CD signal. Cure: Reconfigure the modem,
replace the cable. Workaround: SET CARRIER OFF (at least in System-V based
UNIX versions).
C-Kermit tries to use the 8th bit for data when parity is NONE, and this
generally works on real UNIX terminal (tty) devices, but it often does not
work when the UNIX system is accessed over a network via telnet or rlogin
protocols, including (in many cases) through terminal servers. For example,
an Encore computer with Annex terminal servers only gives a 7-bit path if
the rlogin protocol is selected in the terminal server but it gives the full
8 bits if the proprietary RDP protocol is used.
If file transfer does not work through a host to which you have rlogin'd,
use "rlogin -8" rather than "rlogin". If that doesn't work, tell both Kermit
programs to "set parity space".
The Encore TELNET server does not allow long bursts of input. When you have
a TELNET connection to an Encore, tell C-Kermit on the Encore to SET RECEIVE
PACKET-LENGTH 200 or thereabouts.
For Berkeley-UNIX-based systems (4.3BSD and earlier), Kermit includes code to
use LPASS8 mode when parity is none, which is supposed to allow 8-bit data and
Xon/Xoff flow control at the same time. However, as of edit 174, this code is
entirely disabled because it is unreliable: even though the host operating
system might (or might not) support LPASS8 mode correctly, the host access
protocols (terminal servers, telnet, rlogin, etc) generally have no way of
finding out about it and therefore render it ineffective, causing file
transfer failures. So as of edit 174, Kermit once again uses rawmode for
8-bit data, and so there is no Xon/Xoff flow control during file transfer or
terminal emulation in the Berkeley-based versions (4.3 and earlier, not 4.4).
Also on Berkeley-based systems (4.3 and earlier), there is apparently no way
to configure a dialout line for proper carrier handling, i.e. ignore carrier
during dialing, require carrier thereafter, get a fatal error on any attempt
to read from the device after carrier drops (this is handled nicely in System
V by manipulation of the CLOCAL flag). The symptom is that carrier loss does
not make C-Kermit pop back to the prompt automatically. This is evident on
the NeXT, for example, but not on SunOS, which supports the CLOCAL flag. This
is not a Kermit problem, but a limitation of the underlying operating system.
For example, the cu program on the NeXT doesn't notice carrier loss either,
whereas cu on the Sun does.
On certain AT&T UNIX systems equipped with AT&T modems, DIAL and HANGUP don't
work right. Workarounds: (1) SET DIAL HANGUP OFF before attempting to dial;
(2) If HANGUP doesn't work, SET LINE, and then SET LINE <device> to totally
close and reopen the device. If all else fails, SET CARRIER OFF.
C-Kermit does not contain any particular support for AT&T DataKit devices.
You can use Kermit software to dial in to a DataKit line, but C-Kermit does
not contain the specialized code required to dial out from a DataKit line. If
the UNIX system is connected to DataKit via serial ports, dialout should work
normally (e.g. set line /dev/ttym1, set speed 19200, connect, and then see the
DESTINATION: prompt, from which you can connect to another computer on the
DataKit network or to an outgoing modem pool, etc). But if the UNIX system
is connected to the DataKit network through the special DataKit interface
board, then SET LINE to a DataKit pseudodevice (such as /dev/dk031t) will not
work (you must use the DataKit "dk" or "dkcu" program instead).
In some BSD-based UNIX C-Kermit versions, SET LINE to a port that has nothing
plugged in to it with SET CARRIER ON will hang the program (as it should), but
it can't be interrupted with Ctrl-C. The interrupt trap is correctly armed,
but apparently the UNIX open() call cannot be interrupted in this case. When
SET CARRIER is OFF or AUTO, the SET LINE will eventually return, but then the
program hangs (uninterruptibly) when the EXIT or QUIT command (or, presumably,
another SET LINE command) is given. The latter is probably because of the
attempt to hang up the modem. (In edit 169, a timeout alarm was placed around
this operation.)
With SET DIAL HANGUP OFF in effect, the DIAL command might work only once,
but not again on the same device. In that case, give a SET LINE command
with no arguments to close the device, and then another SET LINE command for
the desired device. Or rebuild your version of Kermit with the -DCLSOPN
compile-time switch (see ckuins.txt).
The DIAL command says "To cancel: Type your interrupt character (normally
Ctrl-C)." This is just one example of where program messages and
documentation assume your interrupt character is Ctrl-C. But it might be
something else. In most (but not necessarily all) cases, the character
referred to is the one that generates the SIGINT signal. If Ctrl-C doesn't
act as an interrupt character for you, type the Unix command "stty -a" or
"stty all" or "stty everything" to see what your interrupt character is.
(Kermit could be made to find out what the interrupt character is, but this
would require a lot of system-dependent coding and #ifdefs, and a new routine
and interface between the system-dependent and system-independent parts of the
program.)
In general, the hangup operation on a serial communication device is prone
to failure. C-Kermit tries to support many, many different kinds of
computers, and there seems to be no portable method for hanging up a modem
connection (i.e. turning off the RS-232 DTR signal and then turning it back on
again). If HANGUP, DIAL, and/or Ctrl-H do not work for you, and you are a
programmer, look at the tthang() function in ckutio.c and see if you can add
code to make it work correctly for your system, and send the code to the
address above. (NOTE: This problem has been largely sidestepped as of edit
188, in which Kermit first attempts to hang up the modem by "escaping back"
via +++ and then giving the modem's hangup command, e.g. ATH0, when DIAL
MODEM-HANGUP is ON, which is the default setting.)
Even when Kermit's modem-control software is configured correctly for your
computer, it can only work right if your modem is also configured to assert
the CD signal when it is connected to the remote modem and to hang up the
connection when your computer drops the DTR signal. So before deciding Kermit
doesn't work with your modem, check your modem configuration AND the cable (if
any) connecting your modem to the computer -- it should be a straight-through
modem cable conducting the signals FG, SG, TD, RD, RTS, CTS, DSR, DTR, CD,
and RI.
Many UNIX systems keep aliases for dialout devices; for example, /dev/acu
might be an alias for /dev/tty00. But most of these UNIX systems also use
UUCP lockfile conventions that do not take this aliasing into account, so if
one user assigns (e.g.) /dev/acu, then another user can still assign the same
device by referring to its other name. This is not a Kermit problem --
Kermit must follow the lockfile conventions used by the vendor-supplied
software (cu, tip, uucp).
The SET FLOW-CONTROL KEEP option should be given *before* any communication
(dialing, terminal emulation, file transfer, INPUT/OUTPUT/TRANSMIT, etc) is
attempted, if you want C-Kermit to use all of the device's preexisting
flow-control related settings. The default flow-control setting is XON/XOFF,
and it will take effect when the first communication-related command is given,
and a subsequent SET FLOW KEEP command will not necessarily know how to
restore *all* of the device's original flow-control settings.
(8) HARDWARE FLOW CONTROL
SET FLOW RTS/CTS is available in UNIX C-Kermit only when the underlying
operating system provides an Application Program Interface (API) for turning
this feature on and off under program control, which turns out to be a rather
rare feature among UNIX systems. To see if your UNIX C-Kermit version
supports hardware flow control, type "set flow ?" at the C-Kermit prompt, and
look for "rts/cts" among the options. Other common situations include:
1. The API is available, so "set flow rts/cts" appears as a valid C-Kermit
command, but it doesn't do anything because the device driver (part of
the operating system) was never coded to do hardware flow control. This
is common among System V R4 implementations (details below).
2. The API is not available, so "set flow rts/cts" does NOT appear as a valid
C-Kermit command, but you can still get RTS/CTS flow control by selecting
a specially named device in your SET LINE command. Examples:
NeXTSTEP: /dev/cufa instead of /dev/cua, /dev/cufb instead of /dev/cub
(68040 only; "man zs" for further info).
IRIX: /dev/ttyf2 instead of /dev/ttyd2 or /dev/ttym2 ("man 7 serial").
3. The API is available, doesn't work, but a workaround as in (2) can be used.
4. The API is available, but Kermit doesn't know about it. In these cases,
you can usually use an stty command to enable RTS/CTS on the device, e.g.
"stty crtscts" or "stty ctsflow", "stty rtsflow", before starting Kermit,
and then tell Kermit to SET FLOW KEEP.
5. No API and no special device drivers. Hardware flow control is completely
unavailable.
System V R4 based UNIXes are supposed to supply a <termiox.h> file, which
gives Kermit the necessary interface to command the terminal driver to
enable/disable hardware flow control. Unfortunately, but predictably, many
implementations of SVR4 whimsically place this file in /usr/include/sys rather
than /usr/include (where SVID clearly specifies it should be; see SVID, Third
Edition, V1, termiox(BA_DEV). Thus if you build C-Kermit with any of the
makefile entries that contain -DTERMIOX or -DSTERMIOX (the latter to select
<sys/termiox.h>), C-Kermit will have "set flow rts/cts" and possibly other
hardware flow-control related commands. BUT... That does not necessarily
mean that they will work. In some cases, the underlying functions are simply
not coded into the operating system.
(9) TERMINAL CONNECTION AND KEY MAPPING
UNIX C-Kermit is not a terminal emulator. Refer to page 147 of "Using
C-Kermit", 2nd Edition: "Most versions of C-Kermit -- UNIX, VMS, AOS/VS, VOS,
etc -- provide terminal connection without emulation. These versions act as a
'semitransparent pipe' between the remote computer and your terminal, terminal
emulator, console driver, or window, which in turn emulates (or is) a specific
kind of terminal." The environment in which you run C-Kermit is up to you.
If you are an X Windows user, you should be aware of an alternative to xterm
that supports VT220 emulation, from Thomas E. Dickey:
http://www.clark.net/pub/dickey/xterm/xterm.faq.html
UNIX C-Kermit's SET KEY command currently can not be used with keys that
generate "wide" scan codes or multibyte sequences, such as workstation
function or arrow keys, because UNIX C-Kermit does not have direct access to
the keyboard.
However, many UNIX workstations and/or console drivers provide their own key
mapping feature. With xterm, for example, you can use 'xmodmap' ("man
xmodmap" for details); here is an xterm mapping to map the Sun keyboard to DEC
VT200 values for use with VT-terminal oriented applications like VMS EVE:
keycode 101=KP_0
keycode 119=KP_1
keycode 120=KP_2
keycode 121=KP_3
keycode 98=KP_4
keycode 99=KP_5
keycode 100=KP_6
keycode 75=KP_7
keycode 76=KP_8
keycode 77=KP_9
keycode 52=KP_F1
keycode 53=KP_F2
keycode 54=KP_F3
keycode 57=KP_Decimal
keycode 28=Left
keycode 29=Right
keycode 30=KP_Separator
keycode 105=KP_F4
keycode 78=KP_Subtract
keycode 8=Left
keycode 10=Right
keycode 32=Up
keycode 33=Down
keycode 97=KP_Enter
Users of Linux consoles can use loadkeys ("man dumpkeys loadkeys keytables"
for details. The format used by loadkeys is compatible with that used by
Xmodmap, although it is not definitely certain that the keycodes are
compatible for different keyboard types (e.g. Sun vs HP vs PC, etc).
(10) FILE TRANSFER
Suppose you start C-Kermit with a command-line argument to send or receive a
file (e.g. "kermit -r") and then type Ctrl-c immediately afterwards to escape
back and initiate the other end of the transfer, BUT your local Kermit's
escape character is not Ctrl-. In this case, the local Kermit passes the
Ctrl- to the remote system, and if this is UNIX, Ctrl- is likely to be its
SIGQUIT character, which causes the current program to halt and dump core.
Well, just about the first thing C-Kermit does when it starts is to disable
the SIGQUIT signal. However, it is still possible for SIGQUIT to cause Kermit
to quit and dump core if it is delivered while Kermit is being loaded or
started, before the signal can be disabled. There's nothing Kermit itself can
do about this, but you can prevent it from happening by disabling SIGQUIT in
your UNIX session. The command is usually something like:
stty quit undef
UNIX C-Kermit does not reject incoming files on the basis of size. There
appears to be no good (reliable, portable) way to determine in advance how
much disk space is available, either on the device, or (when quotas or other
limits are involved) to the user.
File transfer can fail if the incoming file is bigger than your "ulimit".
Use the UNIX ulimit command to examine or change your ulimit (the number is
in 512-byte blocks, i.e. 0.5K). The exact effect of the ulimit depends on
the particular UNIX version, and to some extent probably also on the shell.
"man ulimit" for details, or read the man page for the shell you are using.
UNIX C-Kermit discards all carriage returns from incoming files when in text
mode.
If C-Kermit has problems creating files in writable directories when it is
installed setuid or setgid on BSD-based versions of UNIX such as NeXTSTEP 3.0,
it probably needs to be rebuilt with the -DSW_ACC_ID compilation switch (see
ckuins.txt).
If C-Kermit is receiving a file on a dialup connection and the connection
hangs up, the SIGHUP signal is delivered to the top-level shell, which kills
all processes (including Kermit and any of its subforks) and closes all open
files, including the file that was being received. Even if you have told
Kermit to SET FILE INCOMPLETE DISCARD, the partially received file is kept.
See comments in ckutio.c (search for SIGHUP) for details.
If you SET FILE DISPLAY FULLSCREEN, and C-Kermit complains "Sorry, terminal
type not supported", it means that the terminal library (termcap or termlib)
that C-Kermit was built with does not know about a terminal whose name is the
current value of your TERM environment variable. If this happens, but you
want to have the fullscreen file transfer display, EXIT from C-Kermit and set
a UNIX terminal type from among the supported values that is also supported by
your terminal emulator, or else have an entry for your terminal type added to
the system termcap and/or terminfo database.
If you attempt to suspend C-Kermit during local-mode file transfer and then
continue it in the background (via bg), it will block for "tty output" if
you are using the FULLSCREEN file transfer display. This is apparently
a problem with curses. Moving a local-mode file transfer back and forth
between foreground and background works correctly, however, with the SERIAL,
CRT, BRIEF, or NONE file transfer displays.
If C-Kermit's command parser no longer echoes, or otherwise acts strangely,
after returning from a file transfer with the fullscreen (curses) display, and
the curses library for your version of UNIX includes the newterm() function,
then try rebuilding your version of C-Kermit with -DCK_NEWTERM. Similarly if
it echoes doubly, which might even happen during a subsequent CONNECT session.
If rebuilding with -DCK_NEWTERM doesn't fix it, then there is something very
strange about your system's curses library, and you should probably not use
it. Tell C-Kermit to SET FILE DISPLAY CRT or anything else other than
FULLSCREEN, and/or rebuild without -DCK_CURSES, and without linking with
(termlib and) curses. Note: In C-Kermit 7.0 this problem seems to have
escalated, and -DCK_NEWTERM had to be added to many builds that previously
worked without it: Linux, AIX 4.1, DG/UX, etc. In the Linux case, it is
obviously because of changes in the (n)curses library; the cause in the other
cases is not known.
Reportedly, when using "MSEND *" from a 14-character filename UNIX system to
another system (e.g. BSD) that allows longer names, with SET FILE NAMES
LITERAL, any files with 14-character names will have a space added to the end
of the name on the receiving machine (this *should* be fixed in 6.0).
C-Kermit creates backup-file names (such as "oofa.txt.~1~") based on its
knowledge of the maximum filename length on the platform where it is running,
which is learned at compile time, based on MAXNAMLEN or equivalent symbols
from the system header files. But suppose C-Kermit is receiving files on a
UNIX platform that supports long filenames, but the incoming files are being
stored on an NFS-mounted file system that supports only short names. NFS maps
the external system to the local APIs, so C-Kermit has no way of knowing that
long names will be truncated. Or that C-Kermit is running on a version of
UNIX that supports both long-name and short-name file systems simultaneously
(such as HP-UX 7.00). This can cause unexpected behavior when creating backup
files, or worse. For example, you are sending a group of files whose names
are differentiated only by characters past the point at which they would be
truncated, each file will overwrite the previous one upon arrival.
Optimum file transfer performance is a matter of tuning parameters like packet
length, window size, control-character unprefixing, and on serial connections,
ensuring there is an effective flow control method, preferably hardware (such
as RTS/CTS).
However, a fully-configured C-Kermit program can be slower than a minimally
configured one simply because of its size. A command-line-only version that
is stripped of every conceivable feature not affecting file transfer (such as
"sunos41m" for the Sun or "dellsys5r4m" for Dell) can move files faster than a
full-featured one. Thus, it might make sense to keep a minimal version
available as well as a full-featured one. See the files ckuins.txt and
ckccfg.txt as well as the makefile for how to do this.
A fairly substantial reduction in size and a noticeable improvement in speed
can be obtained simply by rebuilding C-Kermit without the debugging feature:
make <entryname> KFLAGS=-DNODEBUG
See ckccfg.txt for more detailed information about configuration.
(11) EXTERNAL FILE TRANSFER PROTOCOLS
UNIX C-Kermit can be used in conjunction with other communications software
in various ways. C-Kermit can be invoked from another communications program
as an "external protocol", and C-Kermit can also invoke other communication
software to perform external protocols.
This sort of operation makes sense only when you are dialing out from your
UNIX system. If the UNIX system is the one you have dialed in to, you don't
need any of these tricks. Just run the desired software on your UNIX system
instead of Kermit. When dialing out from a UNIX system, the difficulty is
getting two programs to share the same communication device in spite of the
UNIX UUCP lockfile mechanism, which would normally prevent any sharing, and
preventing the external protocol from closing (and therefore hanging up) the
device when it exits back to the program that invoked it.
(This section deleted; see "Using C-Kermit", 2nd Ed, Chapter 14.)
"pcomm" is a general-purpose terminal program that provides file transfer
capabilities itself (X- and YMODEM variations) and the ability to call on
external programs to do file transfers (ZMODEM and Kermit, for example). You
can tell pcomm the command to send or receive a file with an external
protocol:
send receive
ZMODEM sz <filename> rz
Kermit kermit -s <filename> kermit -r
pcomm runs external programs for file transfer by making stdin and stdout
point to the modem port, and then exec-ing "/bin/sh -c xxx" (where xxx is the
appropriate command). However, C-Kermit does not treat stdin and stdout as
the communication device unless you instruct it:
send receive
Kermit kermit -l 0 -s <filename> kermit -l 0 -r
The "-l 0" option means to use file descriptor 0 for the communication device.
In general, any program can pass any open file descriptor to C-Kermit for the
communication device in the "-l" command-line option. When Kermit is given
a number as the argument to the "-l" option, it simply uses it as a file
descriptor, and it does not attempt to close it upon exit.
Here's another example, for Seyon (a Linux communication program). First try
the technique above. If that works, fine; otherwise... If Seyon does not
give you a way to access and pass along the file descriptor, but it starts up
the Kermit program with its standard i/o redirected to its (Seyon's)
communications file descriptor, you can also experiment with the following
method, which worked here in brief tests on SunOS. Instead of having Seyon
use "kermit -r" or "kermit -s filename" as its Kermit protocol commands, use
something like this (examples assume C-Kermit 6.0):
For serial connections:
kermit -YqQl 0 -r <-- to receive
kermit -YqQl 0 -s filename(s) <-- to send one or more files
For Telnet connections:
kermit -YqQF 0 -r <-- to receive
kermit -YqQF 0 -s filename(s) <-- to send one or more files
Command line options:
Y - skip executing the init file
Q - use fast file transfer settings
l 0 - transfer files using file descriptor 0 for a serial connection
F 0 - transfer files using file descriptor 0 for a Telnet connection
q - quiet - no messages
r - receive
s - send
(11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
(This section is obsolete, but not totally useless.
See Chapter 14 of "Using C-Kermit", 2nd Edition).
After you have opened a communication link with C-Kermit's SET LINE (SET PORT)
or SET HOST (TELNET) command, C-Kermit makes its file descriptor available to
you in the v(ttyfd) variable so you can make it available to other programs
that you RUN from C-Kermit. Here, for example, C-Kermit runs itself as an
external protocol:
C-Kermit>set modem type hayes
C-Kermit>set line /dev/acu
C-Kermit>set speed 2400
C-Kermit>dial 7654321
Call complete.
C-Kermit>echo v(ttyfd)
3
C-Kermit>run kermit -l v(ttyfd)
Other programs that accept open file descriptors on the command line can be
started in the same way.
You can also use your shell's i/o redirection facilities to assign C-Kermit's
open file descriptor (ttyfd) to stdin or stdout. For example, old versions of
the UNIX ZMODEM programs, sz and rz, when invoked as external protocols,
expect to find the communication device assigned to stdin and stdout with no
option for specifying any other file descriptor on the sz or rz command line.
However, you can still invoke sz and rz as exterior protocols from C-Kermit if
your current shell ($SHELL variable) is ksh (the Korn shell) or bash (the
Bourne-Again shell), which allows assignment of arbitrary file descriptors to
stdin and stdout:
C-Kermit> run rz <&v(ttyfd) >&v(ttyfd)
or:
C-Kermit> run sz oofa.zip <&v(ttyfd) >&v(ttyfd)
In version 5A(190) and later, you can use C-Kermit's REDIRECT command, if it
is available in your version of C-Kermit, to accomplish the same thing without
going through the shell:
C-Kermit> redirect rz
or:
C-Kermit> redirect sz oofa.zip
A complete set of rz,sz,rb,sb,rx,sx macros for UNIX C-Kermit is defined in
the file ckurzsz.ini. It automatically chooses the best redirection method.
(11.3) USING C-KERMIT WITH TERM
Note: the following section dates from circa 1994. Since then,
evidently, "slirp" has supplanted "term", and reportedly, unlike
term, slirp can be used transparently to the application:
http://blitzen.canberra.edu.au/resources
The "term" program provides an error-corrected, multiplexed connection
between two UNIX systems, allowing you to run multiple applications over a
single connection, for example several terminal windows and a file transfer
simultaneously. Term depends on a communications application (such as
C-Kermit) to make the connection and then redirect it to term's standard i/o.
The advantages of using C-Kermit rather than other communication programs for
this include:
. C-Kermit's script language lets you automate the entire process.
. With C-Kermit's REDIRECT command, term sessions are not limited to serial
connections, but can work over network connections (TCP/IP, X.25) too.
Here is an example showing how to set up a term session between two UNIX
systems with C-Kermit (assuming the connection has already been made by
C-Kermit, e.g. by dialing up):
C-Kermit> connect
login: xxx
Password: xxx
$ exec term -r -s 38400 -A
^c (escape back)
C-Kermit>redirect term -s 38400 -A &
C-Kermit>push ; or "suspend"
$
Now you can run term clients such as trsh and tupload at the local shell
prompt.
(12) SECURITY
We receive constant requests for versions of C-Kermit that use all sorts of
security mechanisms: SOCKS, SSL, SSH, SSLeay, TSL, PCT, SRP, etc etc. Well...
(a) C-Kermit can be linked with a SOCKS library if you have one; see
ckccfg.txt, section 8.1.1.
(b) Most of the others require export or import licenses, carry source-code
restrictions, and/or are patented.
HOWEVER...
(c) C-Kermit 7.0 includes support for Kerberos; see kerberos.txt for details.
(d) It also has a new feature to let it be used "over" secure clients like
SSL Telnet, SRP Telnet, etc. See ckermit2.txt Sections 2.7 and 2.14
for details.
(13) MISCELLANEOUS USER REPORTS
Date: Thu, 12 Mar 92 1:59:25 MEZ
From: Walter Mecky <walter@rent-a-guru.de>
Subject: Help.Unix.sw
To: svr4@pcsbst.pcs.com, source@usl.com
PRODUCT: Unix
RELEASE: Dell SVR4 V2.1 (is USL V3.0)
MACHINE: AT-386
PATHNAME: /usr/lib/libc.so.1
/usr/ccs/lib/libc.a
ABSTRACT: Function ttyname() does not close its file descriptor
DESCRIPTION:
ttyname(3C) opens /dev but never closes it. So if it is called
often enough the open(2) in ttyname() fails. Because the broken
ttyname() is in the shared lib too all programs using it can
fail if they call it often enough. One important program is
uucico which calls ttyname for every file it transfers.
Here is a little test program if your system has the bug:
#include <stdlib.h>
#include <stdio.h>
main() {
int i = 0;
while (ttyname(0) != NULL)
i++;
perror("ttyname");
printf("i=%dn", i);
}
If this program runs longer than some seconds you don't have the bug.
WORKAROUND:
None
FIX:
Very easy if you have source code.
Another user reports some more explicit symptoms and recoveries:
> What happens is when invoking ckermit we get one of the following
> error messages:
> You must set line
> Not a tty
> No more processes.
> One of the following three actions clears the peoblem:
> shutdown -y -g0 -i6
> kill -9 the ttymon with the highest PID
> Invoke sysadm and disable then enable the line you want to use.
> Turning off respawn of sac -t 300 and going to getty's and uugetty's
> does not help.
>
> Also C-Kermit reports "?timed out closing /dev/ttyxx".
> If this happens all is well.
------------------------------
(Note: the following problem also occurs on SGI and probably many other
UNIX systems):
From: James Spath <spath@jhunix.hcf.jhu.edu>
To: Info-Kermit-Request@cunixf.cc.columbia.edu
Date: Wed, 9 Sep 1992 20:20:28 -0400
Subject: C-Kermit vs uugetty (or init) on Sperry 5000
We have successfully compiled the above release on a Unisys/Sperry 5000/95. We
used the sys5r3 option, rather than sys5r2 since we have VR3 running on our
system. In order to allow dialout access to non-superusers, we had to do
"chmod 666 /dev/tty###", where it had been -rw--w--w- (owned by uucp), and to
do "chmod +w /usr/spool/locks". We have done text and binary file transfers
through local and remote connections.
The problem concerning uucp ownership and permissions is worse than I thought
at first. Apparently init or uugetty changes the file permissions after each
session. So I wrote the following C program to open a set of requested tty
lines. I run this for any required outgoing line prior to a Kermit session.
------ cut here -------
/* opentty.c -- force allow read on tty lines for modem i/o */
/* idea from: restrict.c -- System 5 Admin book Thomas/Farrow p. 605 */
/* /jes jim spath {spath@jhunix.hcj.jhu.edu } */
/* 08-Sep-92 NO COPYRIGHT. */
/* this must be suid to open other tty lines */
/* #define DEBUG */
#define TTY "/dev/tty"
#define LOK "/usr/spool/locks/LCK..tty"
#include <stdio.h>
/* allowable lines: */
#define TOTAL_LINES 3
static char allowable[TOTAL_LINES][4] = { "200", "201", "300" };
static int total=TOTAL_LINES;
int allow;
/* states: */
#define TTY_UNDEF 0
#define TTY_LOCK 1
#define TTY_OKAY 2
main(argc, argv)
int argc; char *argv[]; {
char device[512];
char lockdev[512];
int i;
if (argc == 1) {
fprintf(stderr, "usage: open 200 [...]n");
}
while (--argc > 0 && (*++argv) != NULL ) {
#ifdef DEBUG
fprintf(stderr, "TRYING: %s%sn", TTY, *argv);
#endif
sprintf(device, "%s%s", TTY, *argv);
sprintf(lockdev, "%s%s", LOK, *argv);
allow = TTY_UNDEF; i = 0;
while (i <= total) { /* look at all defined lines */
#ifdef DEBUG
fprintf(stderr, "LOCKFILE? %s?n", lockdev);
#endif
if (access(lockdev, 00) == 0) {
allow=TTY_LOCK;
break;
}
#ifdef DEBUG
fprintf(stderr, "DOES:%s==%s?n", allowable[i], *argv);
#endif
if (strcmp(allowable[i], *argv) == 0)
allow=TTY_OKAY;
i++;
}
#ifdef DEBUG
fprintf(stderr, "allow=%dn", allow);
#endif
switch (allow) {
case TTY_UNDEF:
fprintf (stderr, "open: not allowed on %sn", *argv);
break;
case TTY_LOCK:
fprintf (stderr, "open: device locked: %sn", lockdev);
break;
case TTY_OKAY:
/* attempt to change mode on device */
if (chmod (device, 00666) < 0)
fprintf (stderr, "open: cannot chmod on %sn", device);
break;
default:
fprintf (stderr, "open: FAULTn");
}
}
exit (0);
}
------------------------------
(14) THIRD-PARTY DRIVERS
UNIX versions, especially those for PCs (SCO, Unixware, etc) might be
augmented by third-party communication-board drivers from Digiboard, Stallion,
etc. These can sometimes complicate matters for Kermit considerably since
Kermit has no way of knowing that it is going through a possibly nonstandard
driver. Various examples are listed in the earlier sections of this file;
search for Stallion, Digiboard, etc. Additionally:
. The Stallion Technologies EasyConnection serial board driver does not
always report the state of DSR as low. From Stallion (October 1997):
"Unfortunately, this is a bug in our driver. We have implemented all of the
other TIOMC functions, eg DTR, DCD, RTS and CTS, but not DSR. Our driver
should report the actual state of DSR on those of our cards that have a DSR
signal. That the driver always reports DSR as not asserted (0), is a bug in
the driver. The driver should be either reporting the state of DSR
correctly on those cards that support DSR or as always asserted (1) on
those cards that do not have a DSR signal. This will be fixed in a future
version of our drivers; at this time I cannot say when this will be." And
later, "As far as I can tell, we don't support the termios/termiox ioctls
that relate specifically to DSR and RI; all the rest are supported. This
will, as I mentioned earlier, be fixed in the next release of our ATA
software." - World Wide Escalation Support, Stallion Technologies,
Toowong QLD, support@stallion.oz.au.
Later (December 1997, from the same source):
. We have now released a new version of the ATA software, version 5.4.0.
This version fixes the problem with the states of the DSR and RI
signals and how they were being reported by the driver. This is the
problem that you reported in October. The DSR signal is reported
correctly on those cards that support the DSR signal, such as the early
revision of the EasyIO card and the EasyConnection 8D4 panel, and as
always asserted on those cards that do not support the DSR signal in
the hardware. The new driver is available from our Web site,
www.stallion.com, in the /drivers/ata5/UnixWare directory.
(End of CKUBWR.TXT)