ckuker.bwr

linux终端仿真程序

:  Hayes Accura 14.4 + FAX internal on COM 2
: 
: Relevant software:
:  Linux Debian 0.93R6, kernel 1.2.13, GCC 2.6.3, C-kermit 1.90
: 
C-Kermit 5A(190) was tested successfully on every known Linux variation at
the time it was released (October 1994), but since then what is
collectively known as Linux has been changing rapidly out from underneath
us, thanks in large part to its numerous repackagers.  Most of the
problems stem from the many and varied curses libraries; this is the first
report I have heard of this nature.  You might try:

 1. The Debian C-Kermit distribution, put together and tested by the
    Debian Project.  Maybe they linked it with different libraries than
    you did:

      ftp://kermit.columbia.edu/kermit/linux/

 2. The 6.0.192 Alpha not-yet-a-release:

      ftp://kermit.columbia.edu/kermit/test/

 3. Taking a debug log of a core-dumping session and sending the last
    hundred lines or so to [e-mail] for analysis.  Also see if
    you can get a backtrace from the core file to find out what routine it
    was in when it faulted.  I don't know what the command for this is on
    Linux -- locally I use "adb kermit core" and then "$c", where "kermit"
    is Kermit's pathname and "core" is the core file's pathname.

[e-mail] (John D. Griffith) replies:
Well I am succesfully using C-kermit 1.90 with the same modem on 
/dev/cua2 (COM3).  I am running linux 1.2.13 (a.out) and gcc 2.5.8.
My distribution was originally Red Hat Release 1.0, but has been
considerably customized since then. 

[e-mail] (Bill Mitchell) replies:
I'm the debian kermit maintainer, but I'm afraid I don't have much
of a clue about this.  The debian kermit sources are stock kermit
sources except for the addition of some debian-specific files (debian.*)
which don't impact non-debian compilation and the addition of a debian
target in debian.makefile.
I use kermit regularly on my debian linux system with the 1.2.13 kernel,
and my modem is on /dev/cua1.

And in the same vein...

Date: Wed, 15 Nov 95 10:16:24 EST
From: Frank da Cruz <[e-mail]>
To: kurt klingbeil <[e-mail]>
Subject: Re: cku190 & linux 1.1.59 vs 1.2.x ??
In-Reply-To: Your message of Tue, 14 Nov 1995 23:57:21 -0700 (MST)

> Any idea what's changed in the serial handling of linux
> between 1.1.x and 1.2.x ?
> 
Absolutely no idea.  It's just the way of the world.  The rule is that if
Kermit works in release n of any operating system, then release n+1 breaks it.
I think this must be an internal requirement for OS developers.  The nice
thing about Linux is you don't even know who to ask about it.

> Using cku190 to connect to a USR v.everything (no getty or any other process
> active on that tty port):
> I can dial, connect, run a remote session.
> When I hangup, the loss of CD causes kermit 
> to disconnect, drop RTS and DTR, and return to its prompt.
> 
> When attempting to immediately re-connect to the modem
> (using c command), I can see the DTR and RTS lines being brought up:
> (The modem's CTS and DSR remain set at all times.)
> 
> Under Linux 1.1.59, kermit is immediately able to communincate with 
> the modem.  Under Linux 1.2.{3,8,13} kermit appears to be hung -
> no modem responses are received, kermit ignores it's escape character
> and will wait forever.  If one sends kermit a signal (either via kill,
> or, if one is on the console via break (control-C is ignored as well)),
> then a few characters of garbage appear in kermit's session, and
> things are back to normal.
> 
> I suspect that either a previously non-blocking read is now a blocking
> read, or that previously the port was being properly flushed before
> a connection was made, and that under 1.2.x it isn't and hence kermit
> gets deadlocked waiting forever for a conidition which never occurs.
> 
> Any ideas ?
> 
(Unhelpful response deleted)

Could this be the explanation? --

Date: Sat, 13 Jan 1996 09:48:11 -0800 (PST)
From: John Harris <[e-mail]>
Subject: C-Kermit Installation on Linux 1.2.1 

Below is a letter which addresses the problem I was having installing 
C-Kermit on a Linux platform.  So you do not need to waste your time 
addressing my difficulty, I wish to inform you that I have just resolved 
it; that is, the compile now takes place without even a warning. 

So that someone else can benefit, I briefly describe the cause of the 
problem.  The following directories were not present: /usr/include/linux/ 
and /usr/src/linux/include/asm.  There may also have been other files 
missing in certain directories; for example, /usr/include/linux and 
/usr/include/asm.  The problem may have arisen from an oversight during
Linux installation; for example, I may have forgotten to create the file
system in advance of installation with "mke2fs -c <partition> <size>" or
perhaps I simply neglected to transfer some library files during the 
software installation itself.

In more recent releases of Linux (mid-1996), the trend is to replace curses by
ncurses.  But of course this is not transparent to application software that
includes curses.h and links with libcurses.  Linus says it *should* be
transparent -- the application should continue to refer to curses and not to
ncurses.  C-Kermit follows this recommendation, so if you have curses-related
trouble during compilation or at runtime, create symbolic links called
curses.h and libcurses.a (or .sa, or .so, or .so.XX, etc) pointing to
ncurses.h and libncurses-dot-whatever, and rebuild Kermit.

Also note that some Linux distributions have internal problems in their header
files.  In one case, there are fatal errors in <termcap.h> that can be fixed
by adding "#include <termios.h>" to the termcap.h file.

See additional comments in the Linux entry in the makefile.

(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

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 verified to work in both
16-bit and 32-bit versions.  Most advanced features are supported including
TCP/IP, high serial speeds, hardware flow-control, modem-signal awareness,
curses support, etc.

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.doc and make the necessary changes to the
makefile entry (e.g. add -DHDBUUCP).

BUG: The fullscreen file transfer display works fine the first time, but it is
fractured on subsequent file transfers.  Cause and cure unknown.

(3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER

There is all sorts of confusion among SCO versions, particularly when third-
party communications boards and drivers are installed, regarding lockfile
naming conventions.  Basically, 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 :-)

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

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.

SCO Xenix and UNIX can provide different names 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).

One user of C-Kermit 5A(190) on SCO UNIX 3.2.4 reported that C-Kermit dumps
core when receiving files in local mode.  The crash invariably occurs when the
16384th byte arrives, obviously indicating some kind of int/long, or
short/int, or similar mismatch in argument-passing -- no doubt the byte count.
Other users of SCO UNIX 3.2.4, built using the same makefile entry, report
that they can receive files of any length with no problem at all.  Maybe it
depends on which file transfer display is being used?  If this happens to you,
try using a different file transfer display (SET FILE DISPLAY NONE, SERIAL,
CRT, or FULLSCREEN).

SCO users report that only one copy of Kermit can run at a time when a
Stallion Technologies multiport boards are installed.

(3.7) C-KERMIT AND SOLARIS

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