ckubwr.txt

KERMIT工具 这在办公室下载不了,很多人都没有载不到.

   If you find a tty0p0 device but no cua0p0, you'll need to creat one if
   you want to dial out; the tty0p0 does not work for dialing out. It's
   easy: start SAM; in the main Sam window, double-click on Peripheral
   Device, then in the Peripheral Devices window, double-click on
   Terminals and Modems. In the Terminals and Modems dialog, click on
   Actions, then choose "Add modem" and fill in the blanks. For example:
   Port number 0, speed 57600 (higher speeds tend not to work reliably),
   "Use device for calling out", do NOT "Receive incoming calls" (unless
   you know what you are doing), leave "CCITT modem" unchecked unless you
   really have one, and do select "Use hardware flow control (RTS/CTS)".
   Then click OK. This creates cua0p0 as well as cul0p0 and ttyd0p0

   If the following sequence:

  set line /dev/cua0p0 ; or other device
  set speed 115200     ; or other normal speed

   produces the message "?Unsupported line speed". This means either that
   the port is not configured for dialout (go into SAM as described above
   and make sure "Use device for calling out" is selected), or else that
   speed you have given (such as 460800) is supported by the operating
   system but not by the physical device (in which case, use a lower
   speed like 57600).

   In HP-UX 9.0, serial device names began to change. The older names
   looked like "/dev/cua00", "/dev/tty01", etc (sometimes with only one
   digit). The newer names have two digits with the letter "p" in
   between. HP-UX 8.xx and earlier have the older form, HP-UX 10.00 and
   later have the newer form. HP-UX 9.xx has the newer form on Series 800
   machines, and the older form on other hardware models. The situation
   is summarized in the following table (the Convio 10.0 column applies
   to HP-UX 10 and 11).

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

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

   Kermit's access to serial devices is controlled by "UUCP lockfiles",
   which are intended to prevent different users using different software
   programs (Kermit, cu, etc, and UUCP itself) from accessing the same
   serial device at the same time. When a device is in use by a
   particular user, a file with a special name is created in:

  /var/spool/locks  (HP-UX 10.00 and later)
  /usr/spool/uucp   (HP-UX 9.xx and earlier)

   The file's name indicates the device that is in use, and its contents
   indicates the process ID (pid) of the process that is using the
   device. Since serial devices and the locks directory are not both
   publicly readable and writable, Kermit and other communication
   software must be installed setuid to the owner (bin) of the serial
   device and setgid to the group (daemon) of the /var/spool/locks
   directory. Kermit's setuid and setgid privileges are enabled only when
   opening the device and accessing the lockfiles.

   Let's say "unit" means a string of decimal digits (the interface
   instance number) followed (in HP-UX 10.00 and later) by the letter "p"
   (lowercase), followed by another string of decimal digits (the port
   number on the interface), e.g.:

  "0p0", "0p1", "1p0", etc       (HP-UX 10.00 and later)
  "0p0", "0p1", "1p0", etc       (HP-UX 9.xx on Series 800)
  "00",  "01",  "10",  "0", etc  (HP-UX 9.xx not on Series 800)
  "00",  "01",  "10",  "0", etc  (HP-UX 8.xx and earlier)

   Then a normal serial device (driver) name consists of a prefix ("tty",
   "ttyd", "cua", "cul", or possibly "cuad" or "culd") followed by a
   unit, e.g. "cua0p0". Kermit's treatment of UUCP lockfiles is as close
   as possible to that of the HP-UX "cu" program. Here is a table of the
   lockfiles that Kermit creates for unit 0p0:

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

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

   In other words, if the device name begins with "cu", a second lockfile
   for the "ttyd" device, same unit, is created, which should prevent
   dialin access on that device.

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

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

  LCK..tty2p3
  LCK..ttyd2p3
  LCK..cua2p3
  LCK..cul2p3
  LCK..cuad2p3
  LCK..culd2p3

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

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

   When the "set line" command succeeds in HP-UX 10.00 and later,
   C-Kermit also creates a Unix System V R4 "advisory lock" as a further
   precaution (but not guarantee) against any other process obtaining
   access to the device while you are using it.

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

  /dev/cua0p0: Permission denied

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

   If Kermit is killed with a device open, the lockfile(s) are left
   behind. The next Kermit program that tries to assign the device, under
   any of its various names, will automatically clean up the stale
   lockfiles because the pids they contain are invalid. The behavior of
   cu and other communication programs under these conditions should be
   the same.

   Here, by the way, is a summary of the differences between the HP-UX
   port driver types from John Pezzano of HP:

     There are three types of device files for each port.

     The ttydXXX device file is designed to work as follows:

    1. The process that opens it does NOT get control of the port until
       CD is asserted. This was intentional (over 15 years ago) to allow
       getty to open the port but not control it until someone called in.
       If a process wants to use the direct or callout device files
       (ttyXXX and culXXX respectively), they will then get control and
       getty would be blocked. This eliminated the need to use uugetty
       (and its inherent problems with lock files) for modems. You can
       see this demonstrated by the fact that "ps -ef" shows a ? in the
       tty column for the getty process as getty does not have the port
       yet.
    2. Once CD is asserted, the port is controlled by getty (or the
       process handling an incoming call) if there was no process using
       the port. The ? in the "ps" command now shows the port. At this
       point, the port accepts data.

     Therefore you should use either the callout culXXX device file
     (immediate control but no data until CD is asserted) or the direct
     device file ttyXXX which gives immediate control and immediate data
     and which ignores by default modem control signals.

     The ttydXXX device should be used only for callin and my
     recommendation is to use it only for getty and uugetty.
    ________________________________________________________________________

  3.2.4 Notes on Specific HP-UX Releases

   SECTION CONTENTS

  3.2.4.1. [216]HP-UX 11
  3.2.4.2. [217]HP-UX 10
  3.2.4.3. [218]HP-UX 9
  3.2.4.4. [219]HP-UX 8
  3.2.4.5. [220]HP-UX 7 and Earlier

  3.2.4.1. HP-UX 11

   [ [221]Top ] [ [222]Contents ] [ [223]Section Contents ] [ [224]Next ]

   As noted in [225]Section 3.2.2, the HP-UX 11 Telnet server and/or
   pseudoterminal driver are a serious impediment to file transfer over
   Telnet connections into HP-UX. If you have a Telnet connection into
   HP-UX 11, tell your desktop Kermit program to:

  set streaming off
  set receive packet-length 2000
  set send packet-length 500

   File transfer speeds over connections from HP-UX 11 (dialed or Telnet)
   are not impeded whatsoever, and can go at whatever speed is allowed by
   the connection and the Kermit partner on the far end.

   PA-RISC binaries for HP-UX 10.20 or later should run on any PA-RISC
   system, S700 or S800, as long as the binary was not built under a
   later HP-UX version than the host operating system. HP-UX 11.00 and
   11.11 are only for PA-RISC systems. HP-UX 11.20 is only for IA64
   (subsequent HP-UX releases will be for both PA-RISC and IA64). To
   check binary compatibility, the following C-Kermit 8.0 binaries were
   run successfully on an HP-9000/785 with HP-UX 11.11:

     * Model 7xx HP-UX 10.20
     * Model 8xx HP-UX 10.20
     * Model 7xx HP-UX 11.00
     * Model 8xx HP-UX 11.00
     * Model 7xx HP-UX 11.11
     * Model 8xx HP-UX 11.11

   Binaries built under some of the earlier HP-UX releases, such as 9.05,
   might also work, but only if built for the same hardware family (e.g.
   s700).
    ________________________________________________________________________

  3.2.4.2. HP-UX 10

   [ [226]Top ] [ [227]Contents ] [ [228]Section Contents ] [ [229]Next ]
   [ [230]Previous ]

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

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

  3.2.4.3. HP-UX 9

   [ [231]Top ] [ [232]Contents ] [ [233]Section Contents ] [ [234]Next ]
   [ [235]Previous ]

   HP-UX 9.00 and 9.01 need patch PHNE_10572 (note: this replaces
   PHNE_3641) for hptt0.o, asio0.o, and ttycomn.o in libhp-ux.a. Contact
   Hewlett Packard if you need this patch. Without it, the dialout device
   (tty) will be hung after first u