ckuker.bwr

linux终端仿真程序

 Client   Server   Send    Receive
  HP       HP       50       50
  Sun      HP       77       67
  HP       Sun      57       85
  Sun      Sun      57       50

Therefore the HP-UX telnet server or pty driver seems to be adding more
overhead than the SunOS one, and most others.  When going through this type of
connection (a remote telnet server) there is nothing Kermit can do improve
matters, since the telnet server and pty driver are between the two Kermits,
and neither Kermit can have any influence over them (except putting the Telnet
connection in binary mode, but that doesn't help).

(3.2.1) HP-UX 5.21

Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on the
HP-9000 series 500 computers.  It only occurs when the controlling terminal
is using an HP-27140 six-port modem mux.  The problem is not present if the
controlling terminal is logged into an HP-27130 eight-port mux.  The symptom
is that just after dialing successfully and connecting Kermit locks up and
the port is unusable until both forks of Kermit and the login shell are
killed."

(3.2.2) HP-UX 8.05

To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install HP-UX
patch PHNE_0899.  This patch deals with a lot of driver issues, particularly
related to communication at higher speeds.

(3.2.3) HP-UX 9.00 AND LATER

HP-UX 9.00 and 9.01 need patch PHNE_3641 for hptt0.o, asio0.o, and ttycomn.o
in libhp-ux.a.  Contact Hewlett Packard if you need this patch.  Without it,
the dialout device (tty) will be hung after first use; subsequent attempts to
use will return an error like "device busy".

C-Kermit works fine -- including its curses-based file-transfer display -- on
the console terminal, in a remote session (e.g. when logged in to the HP 9000
on a terminal port or when telnetted or rlogin'd), and in an HP-VUE hpterm
window or an xterm window.

Before you can use serial ports on the HP-9000, you must configure them as
either "terminals" or "modems" with SAM ("peripheral devices"..."terminals and
modems"), as described in the HP manual, "Configuring HP-UX for Peripherals:
HP 9000".  If you attempt to use a serial device before it has been configured
this way, it will not work properly; typical symptoms are (a) no communication
at all; (b) nonfunctional modem signals; and/or (c) massive amounts of
character loss in both directions.

In HP-UX 9.0, serial device names were different between HP9000 Series 700 and
Series 800 systems.  In 10.0, device file names (and also major and minor
numbers) have "converged", as shown in the following table:

  Converged HP-UX Serial I/O Filenames : TTY Mux Naming
  ---------------------------------------------------------------------
  General meaning        S800 9.0          S700 9.0    Convio 10.0
  ---------------------------------------------------------------------
  tty* hardwired ports   tty<X>p<Y>        tty<YY>     tty<D>p<p>
			 diag:mux<X>                   diag:mux<D>
  ---------------------------------------------------------------------
  ttyd* dial-in modems   ttyd<X>p<Y>       ttyd<YY>    ttyd<D>p<p>
			 diag:ttyd<X>p<Y>              diag:ttyd<D>p<p>
  ---------------------------------------------------------------------
  cua* auto-dial out     cua<X>p<Y>        cua<YY>     cua<D>p<p>
			 diag:cua<X>p<Y>
  ---------------------------------------------------------------------
  cul* dial-out          cul<X>p<Y>        cul<YY>     cul<D>p<p>
			 diag:cul<X>p<Y>
  ---------------------------------------------------------------------
   <X>= LU (Logical Unit)  <D>= Devspec (decimal card instance)
   <Y> or <YY> = Port      <p>= Port

For dialing out, you should use the cua or cul devices.  When C-Kermit's
CARRIER setting is AUTO or ON, C-Kermit will pop back to its prompt
automatically if the carrier signal drops, e.g. when you log out from the
remote computer or service.  If you use the tty<D>p<d> (e.g. tty0p0) device,
the carrier signal is ignored.  The tty<D>p<d> device should be used for
direct connections where the carrier signal does not follow RS-232
conventions (use the cul device for hardwired connections through a true null
modem).  Do not use the ttyd<D>p<d> device for dialing out.

Kermit's access to serial devices is controlled by "UUCP lockfiles", which are
intended to prevent different users using different software programs (Kermit,
cu, etc, and UUCP itself) from accessing the same serial device at the same
time.  When a device is in use by a particular user, a file with a special
name is created in the /var/spool/locks directory.  The file's name indicates
the device that is in use, and its contents indicates the process ID (pid) of
the process that is using the device.  Since serial devices and the
/var/spool/locks directory are not both publicly readable and writable, Kermit
and other communication software must be installed setuid to the owner (bin)
of the serial device and setgid to the group (daemon) of the /var/spool/locks
directory.  Kermit's setuid and setgid privileges are enabled only when
opening the device and accessing the lockfiles.

Let's say "unit" means a string of decimal digits (the interface instance
number) followed by the letter "p" (lowercase), followed by another string of
decimal digits (the port number on the interface), e.g. "0p0", "0p1", "1p0",
etc.  Then a normal serial device (driver) name consists of a prefix ("tty",
"ttyd", "cua", "cul") followed by a unit, e.g. "cua0p0".  Kermit's treatment
of UUCP lockfiles is as close as possible to that of the HP-UX "cu" program.
Here is a table of the lockfiles that Kermit creates for unit 0p0:

  Selection      Lockfile 1     Lockfile 2
  ------------   ------------   ------------
  /dev/tty0p0    LCK..tty0p0    (none)
* /dev/ttyd0p0   LCK..ttyd0p0   (none)
  /dev/cua0p0    LCK..cua0p0    LCK..ttyd0p0
  /dev/cul0p0    LCK..cul0p0    LCK..ttyd0p0
  <other>        LCK..<other>   (none)

(* = Dialin device, should not be used.)

The final case allows for symbolic links, etc, but, of course, it is not
foolproof since we have no way of telling which device is really being used.

When Kermit tries to open a dialout device whose name ends with a "unit", it
searches the lockfile directory for all possible names for the same unit.  For
example, if user selects /dev/cul2p3, Kermit looks for lockfiles named
LCK..tty2p3, LCK..ttyd2p3, LCK..cua2p3, and LCK..cul2p3.

If any of these files are found, Kermit opens them to find out the ID (pid) of
the process that created them; if the pid is still valid, the process is still
active, and so the SET LINE command fails and the user is informed of the pid
so s/he can use "ps" to find out who is using the device.

If the pid is not valid, the file is deleted.  If all such files (i.e. with
same "unit" designation) are successfully removed, then the SET LINE command
succeeds; up to four messages are printed telling the user which "stale
lockfiles" are being removed.

If the selected device was in use by "cu", Kermit can't open it, because "cu"
has changed its ownership, so we never get as far as looking at the lockfiles.
In the normal case, we can't even look at the device to see who the owner is
because it is visible only to its (present) owner.  In this case, Kermit says
(for example):

  /dev/cua0p0: Permission denied

When Kermit releases a device it has successfully opened, it removes all the
lockfiles that it created.  This also happens whenever Kermit exits "under its
own power".

If Kermit is killed with a device open, the lockfile(s) are left behind.  The
next Kermit program that tries to assign the device, under any of its various
names, will automatically clean up the stale lockfiles because the pids
they contain are invalid.

(3.2.4) HP-UX 10.10 AND LATER

C-Kermit is included as part of the HP-UX 10.xx operating system by contract
between Hewlett Packard and Columbia University.  Each level of HP-UX 10.xx
includes a freshly built C-Kermit binary in /bin/kermit, which should work
correctly.  However, if you are building your own or downloading from
Columbia, you should be aware that you can only use a binary that was built
under the same OS level as you are running.  As of C-Kermit version 6.0, HP-UX
10.xx binaries announce, in the startup herald and the VERSION command, the
explicit HP-UX version they were built for: HP-UX 10.00, 10.10, 10.20, or
10.30.  If there is a version mismatch, HP-UX does something like "Invalid
version for shared lib /usr/lib/libc.1, IOT trap (core dumped)".

Beginning in 10.10, libcurses is linked to libxcurses, the new UNIX95 (X/Open)
version of curses, which has some serious bugs; some routines, when called,
would hang and never return, some would dump core.  Evidently libxcurses
contains a select() routine, and whenever C-Kermit calls what it thinks is the
regular (sockets) select(), it gets the curses one, causing a segmentation
fault.  There is a patch for this from HP, PHCO_8086, "s700_800 10.10
libcurses patch", "shared lib curses program hangs on 10.10", "10.10 enhanced
X/Open curses core dumps due to using wrong select call", 96/08/02 (you can
tell if the patch is installed with "what /usr/lib/libxcurses.1"; the unpatched
version is 76.20, the patched one is 76.20.1.2.  It has been verified that
C-Kermit works OK with the patched library, but results are not definite for
HP-UX 10.20 or higher.  

To ensure that C-Kermit works even on non-patched HP-UX 10.10 systems,
separate makefile entries are provided for HP-UX 10.00/10.01, 10.10, 10.20,
etc, in which the entries for 10.10 and above link with libHcurses, which is
"HP curses", the one that was used in 10.00/10.01.

(3.3) C-KERMIT AND LINUX

Be sure to read the comments in the "linux:" makefile entry.  There are all
sorts of confusing issues caused by the many and varied Linux distributions.
Some of the worst involve the curses library and header files: where are they,
what are they called, which ones are they really?  Ditto for UUCP lock files.

Run C-Kermit in the regular console screen, which provides VT100 emulation via
the "console" termcap entry, or under X-Windows in an xterm window.  Before
starting C-Kermit in an xterm window, tell the xterm window's shell to "stty
sane".

How to set up your PC console keyboard to send VT220 key sequences when using
C-Kermit as your communications program in an X terminal window: Create a file
somewhere (e.g. in /root/) called .xmodmaprc, containing something like the
following:

  keycode 77  = KP_F1       ! Num Lock     => DEC Gold (PF1)
  keycode 112 = KP_F2       ! Keypad /     => DEC PF1
  keycode 63  = KP_F3       ! Keypad *     => DEC PF3
  keycode 82  = KP_F4       ! Keypad -     => DEC PF4
  keycode 111 = Help        ! Print Screen => DEC Help
  keycode 78  = F16         ! Scroll Lock  => DEC Do
  keycode 110 = F16         ! Pause        => DEC Do
  keycode 106 = Find        ! Insert       => DEC Find
  keycode 97  = Insert      ! Home         => DEC Insert
  keycode 99  = 0x1000ff00  ! Page Up      => DEC Remove
  keycode 107 = Select      ! Delete       => DEC Select
  keycode 103 = Page_Up     ! End          => DEC Prev Screen
  keycode 22  = Delete      ! Backspace sends Delete (127)

Then put "xmodmap <filename>" in your .xinitrc file (in your login
directory), e.g.

  xmodmap /root/.xmodmaprc

Of course you can move things around.  Use the xev program to find out key
codes.

Different UUCP lockfile conventions are used by Linux, depending on your Linux
distribution.  In C-Kermit 6.0, "make linux" uses /var/lock/LCK..name, decimal
ASCII 10-byte PID string with leading spaces because -DLINUXFSSTND ("Linux File
System Standard") is included in the compilation CFLAGS.  If you remove this
definition, C-Kermit will use the earlier arrangement of integer PID,
/usr/spool/uucp/LCK..name.  The leading spaces are required by FSSTND 1.2, but
FSSTND 1.0 required leading zeros; to get the leading zeros, also include
-DFSSTND10.  Use whichever option agrees with your uucp, cu, tip, etc,
programs.

Building C-Kermit on Linux 1.1.33 and 1.1.34 gets fatal compilation errors
due to inconsistencies in the Linux header files.  Linux kernel versions prior
to 1.1.33 and later than 1.1.34 should be OK.

C-Kermit versions prior to 5A(190) did not support hardware flow control or
high interface speeds for Linux.

One Linux user reported problems dialing out using the /dev/cua device;
"device busy" errors.  He said that using the alternative name (driver) for
the device, /dev/ttyS2, made the problem go away.

Reportedly there is a bug in gcc 2.5.8 with signed to unsigned compares
that can wreak havoc when Kermit (or most any other program) is compiled with
this version of gcc; reportedly this can be worked around, at least in part,
by adding "-fno-unroll-loops" to the gcc compilation options.

Reportedly, if you have the iBCS2 (Intel Binary Compatibility Standard 2)
module installed, you can also run SCO Xenix and UNIX binaries under Linux,
including the SCO C-Kermit binaries, shareable libraries and all.
(iCBS2 is available via anonymous ftp from tsx-11.mit.edu, along with an
SCO libc_s compatibility module for Linux).

Some Linux users reported that after doing a file transfer using the
fullscreen display (thermometer), that "screen scrolling locks up" and the
cursor "is stuck on the bottom of the screen".  This probably only happens
when using the console device.  This turns out to be a problem with Linux
ncurses.  The workaround is to use "set file display crt" or "serial".  The
cure (reportedly) is to build C-Kermit with Linux ncurses 1.8.7 (or later).

(Time passes...)  Now (early 1996) we have increasing reports of C-Kermit core
dumping in Linux 1.2.x, e.g. when the "set line" command is given.  But they
are conflicting -- it happens to some people, not to others.  Not much can be
said about this but:

From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit drops core at SET LINE /dev/cua1
Date: 14 Feb 1996 15:43:07 GMT
Organization: Columbia University

In article <4fr2nc$[e-mail]>,
Branden Robinson <[e-mail]> wrote:
: I'm trying to run C-Kermit under Linux, but as soon as I type "set line
: /dev/cua1", kermit gets a segmentation fault.  This is the correct line, as
: evidenced by the fact that "echo ATDT" and a phone number redirected to
: /dev/cua1 makes the modem dial.
: 
: I thought this might have something to do with the lock file put on
: /dev/cua1, but both the compliation with the -DLINUXFSSTND and without it
: yield the same result.  What is going on here?
: 
: Relevant hardware: