ckubwr.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

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

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

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

3.2.8. HP-UX and X.25

Although C-Kermit presently does not include built-in support for HP-UX X.25
(as it does for the Sun and IBM X.25 products), it can still be used to make
X.25 connections as follows: start Kermit and then telnet to localhost.  After
logging back in, start padem as you would normally do to connect over X.25.
Padem acts as a pipe between Kermit and X.25.  In C-Kermit 7.0, you might also
be able to avoid the "telnet localhost" step by using:

  C-Kermit> pty padem <address>

This will work if padem uses standard i/o (see Section 2.7 of ckermit2.txt).

(3.3) C-KERMIT AND LINUX

For further information, read the comp.os.linux.misc, comp.os.linux.answers,
and other Linux-oriented newsgroups, and:

 The Linux Document Project (LDP):
  . http://sunsite.unc.edu/LDP/

 The Linux FAQ:
  . http://sunsite.unc.edu/LDP/FAQ/Linux-FAQ.html

 The Linux HOWTOs (especially the Serial HOWTO):
  . http://sunsite.unc.edu/LDP/HOWTO/Serial-HOWTO.html
  . ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
  . ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
  . http://sunsite.unc.edu/LDP/HOWTO/
  . http://sunsite.unc.edu/LDP/hmirrors.html

Also see general comments on PC-based UNIXes in Section 3.0.

Did you know: DECnet is available for Linux?  See:

  http://linux.dreamtime.org/decnet/

(But there is no support for it in C-Kermit -- anybody interested in adding
it, please let me know.)

Before proceeding, let's handle the two most frequently asked question in
the Linux newsgroups:

 1. Neither C-Kermit not any other Linux application can use Winmodems
    (with one exception).  See section 3.0 for details.

 2. "Why does it take such a long time to make a telnet connection to (or
    from) my Linux PC?" (this applies to C-Kermit or to regular Telnet).
    Most telnet servers these days perform reverse DNS lookups on the client
    (for security and/or logging reasons).  If the Telnet client cannot be
    found by the local DNS server, the DNS request goes out to the Internet
    at large, and this can take quite some time.  The solution to this
    problem is to make sure that both client and host are registered in DNS.
    C-Kermit itself performs reverse DNS lookups unless you tell it not to.
    This is to allow C-Kermit to let you know which host it is actually
    connected to in case you have made a connection to a "host pool"
    (multihomed host).  You can disable C-Kermit's reverse DNS lookup with
    SET TCP REVERSE-DNS-LOOKUP OFF.

3.3.1.  Problems Building C-Kermit for Linux

Modern Linux distributions like Red Hat give you a choice at installation
whether to include "developer tools".  Obviously, you can't build C-Kermit or
any other C program from source code if you have not installed the developer
tools.  Note that you might also have to choose (separately) to install the
"curses" or "ncurses" terminal control library -- it is possible to install
the C compiler and linker, but omit the (n)curses library and headers.  If
curses is not installed, you will not be able to build a version of C-Kermit
that supports the fullscreen file-transfer display, in which case you'll need
to use the "linuxnc" makefile target (nc = No Curses) or else install ncurses
before building.

Be sure to read the comments in the "linux:" makefile entry.  There are all
sorts of confusing issues caused by the many and varied Linux distributions.
Some of the worst involve the curses library and header files: where are they,
what are they called, which ones are they really?  Other vexing questions
involve libc5 vs libc6 vs glibc vs glibc2 (C libraries), gcc vs egcs vs lcc
(compilers), plus using or avoiding features that were added in a certain
version of Linux or a library or a distribution, and are not available in
others.

Linux C-Kermit, like all other UNIX C-Kermit versions, was built traditionally
with curses.h and the curses library.  However, this library was evidently so
buggy (users reported that, after doing a file transfer using the fullscreen
display, "screen scrolling locks up" and the cursor "is stuck on the bottom of
the screen", etc), that a new curses library, called ncurses, was developed to
replace it.  C-Kermit, as of version 6.1, uses ncurses rather than curses.

After modern practice, ncurses is dynamically linked, rather than linked into
the executable.  This means a certain relationship must obtain between the
version number referenced in the executable and the version number of the
library.  But there are evidently several different numbering systems for
libncurses.so -- e.g. 1.9.9e is another "name" for 3.0 -- but the program
loader doesn't know that and so won't run the program.  Also the library
and/or terminfo database might be in a different place on the target system
(e.g. /usr/share/terminfo) than it was on the build system (e.g.
/usr/lib/terminfo).  Solution: Create the appropriate symbolic links and/or
rebuild C-Kermit yourself from source code, and if you have additional
trouble, come back and read the rest of this section.

Of course static linking is also a possibility, but this makes the executable
MUCH bigger and introduces new problems of its own.

From the March 1999 Kermit newsgroup traffic:
  : When I start Kermit (under Redhat Linux 5.2), it complains about not
  : being able to recognise my terminal type - I've tried all the obvious
  : terminal types - which ones can I use?  Or can I get it to recognise
  : xterm?
  :
  Assuming that you can use full screen programs, this looks identical to the
  problem introduced by RedHat with 5.1.  They moved the curses library, and
  didn't [ leave a link from the old location to the new one ]:

  To fix: cd /usr/share; ln -s terminfo ../lib

The termcap library is no longer referenced in the Linux target in the
makefile, since its functions are supposedly incorporated into the ncurses and
curses libraries.  However, should any termcap-related entry points come up
undefined at link time (_tgetent, _tgoto, _tputs, etc), it might be necessary
to add -ltermcap back to LIBS.  But then you might find that the termcap
library is not in /usr/lib after all, but has been moved to /usr/lib/termcap/,
in which case you'll need to make a symlink, or do something like:

  "LIBS = -L/usr/lib/curses -lcurses -L/usr/lib/termcap -ltermcap"

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

One user reported problems building C-Kermit under Linux 2.0.30/Slackware 96,
errors like:

  /usr/include/linux/socket.h:77: warning: `PF_AAL5' redefined
  /usr/local/include/socketbits.h:68: warning: this is the location of the
  previous definition
  ckutio.c:4679: `TIOCGSERIAL' undeclared (first use this function)
  ckutio.c:4685: `TIOCSSERIAL' undeclared (first use this function)
  ckutio.c:6092: warning: passing arg 3 of `select' from incompatible
  pointer type

etc etc.  Diagnosis: These were caused by installing some other package, which
created files in /usr/local/include.  Cure: rm -rf /usr/local/include, and
start over.

Reportedly, building C-Kermit 6.0 on Linux 1.1.33 and 1.1.34 gets fatal
compilation errors due to inconsistencies in the Linux header files.  Linux
kernel versions prior to 1.1.33 and later than 1.1.34 should be OK.  (Also,
C-Kermit 6.1 and later should be OK since we no longer include kernel header
files.)

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

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

There is evidently a minor problem with GCC (version unknown) on (64-bit)
Alpha platforms, in which it complains:

  warning: cast to pointer from integer of different size

whenever it encounters a legitimate trinary expression like:

  integer ? "string1" : "string2"

(The "integer" can also be an integer-valued expression.)  These warnings
appear to be harmless.

3.3.2. Problems with Serial Devices in Linux

  Also see: "man setserial", "man irqtune".
  And: Sections 3.0, 6, 7, and 8 of this document.

Don't expect it to be easy.  Queries like the following are posted to the
Linux newsgroups almost daily:

  Problem of a major kind with my Compaq Presario 1805 in the sense that
  the pnpdump doesn't find the modem and the configuration tells me that
  the modem is busy when I set everything by hand!

  I have <some recent SuSE distribution>, kernel 2.0.35. Using the Compaq
  tells me that the modem (which is internal) is on COM2, with the usual
  IRQ and port numbers. Running various Windows diagnostics show me
  AT-style commands exchanged so I have no reason to beleive that it is a
  Winmodem. Also, the diagnostics under Win98 tell me that I am talking to
  an NS 16550AN.

[Editor's note: This does not necessarily mean it isn't a Winmodem.]

  Under Linux, no joy trying to talk to the modem on /dev/cua1 whether
  via. minicom, kppp, or chat. kppp at least tells me that tcgetattr()
  failed.

  Usage of setserial ("setserial /dev/cua1 port 0x2F8 irq 3 autoconfig"
  followed by "setserial -g /dev/cua1") tells me that the uart is
  'unknown'. I have tried setting the UART manullay via. setserial to
  16550A, 16550, and the other one (8550?) (I didn't try 16540). None of
  these manual settings resulted in any success.

  A look at past articles leads me to investigate PNP issues by calling
  pnpdump but pnpdump returns "no boards found". I have looked around on
  my BIOS (Phoenix) and there is not much evidence of it being PNP aware.
  However for what it calls "Serial port A", it offers a choice of Auto,
  Disabled or Manual settings (currently set to Auto), but using the BIOS
  interface I tried to change to 'manual' and saw the default settings
  offered to be were 0x3F8 and IRQ 4 (COM1). The BIOS menus did not give
  me any chance to configure COM2 or any "modem". I ended up not saving
  any BIOS changes in the course of my investigations.

  Can anybody suggest something else for me to try?

(end quotes)

Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the like
(see cautions in Section 3.0).  Linux supports Plug-n-Play devices to some
degree via the isapnp and pnpdump programs; read the man pages for them.  (If
you don't have them, look on your installation CD for isapnptool or download
it from sunsite or a sunsite mirror or other politically correct location).

Even when you have a real serial port, always be wary of interrupt conflicts
and similar PC hardware configuration issues: a PC is not a real computer like
other UNIX workstations -- it is generally pieced together from whatever
rando