ckubwr.txt

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

take a look at the source code and send us your suggested fixes or changes.
Or else just send us a report about what seems to be wrong (see the TECHNICAL
SUPPORT section above for details).

(3.0) C-KERMIT ON PC-BASED UNIXES

PCs are not the best platform for real operating systems like UNIX.  The
architecture suffers from numerous deficiencies, not the least of which is the
stiflingly small number of hardware interrupts (either 7 or 15, most of which
are preallocated).  Thus adding devices, using multiple serial ports, etc, is
always a challenge and usually a nightmare.  The free-for-all nature of the PC
market and the lack of standards combined with the diversity of UNIX OS
versions makes it difficult to find drivers for any particular device on any
particular version of UNIX.

Of special interest to Kermit users is the fact that there is no standard
provision in the PC architecture for more than 2 communication (serial) ports.
COM3 and COM4 (or higher) will not work unless you (a) find out the hardware
address and interrupt for each, (b) find out how to provide your UNIX version
with this information, and (c) actually set up the configuration in the UNIX
startup files (or whatever other method is used).  Watch out for interrupt
conflicts, and don't expect to be able to use more than two serial ports at
the same time.

Here is a typical tale from a Linux user (Fred Smith) about installing a third
serial port: "...problems can come from a number of causes. The one I fought
with for some time, and finally conquered, was that my modem is on an add-in
serial port, cua3/IRQ5.  By default IRQ5 has a very low priority, and does not
get enough service in times when the system is busy to prevent losing
data. This in turn causes many resends. There are two 'fixes' that I know of,
one is to relax hard disk interrupt hogging by using the correct parameter to
hdparm, but I don't like that one because the hdparm man page indicates it is
risky to use. The other one, the one I used, was to get 'irqtune' and use it
to give IRQ5 the highest priority instead of nearly the lowest. Completely
cured the problem."

To complicate matters, the PC platform is becoming increasingly and inexorably
Windows-oriented.  More and more add-on devices are "Windows only" -- meaning
they are incomplete and rely on proprietary Windows-based software drivers to
do the jobs that you would expect the device itself to do.  PCMCIA or
"Plug-n-Play" devices are rarely supported on PC-based UNIX versions such as
SCO; Winmodems, Winprinters, and the like are not supported at all on any UNIX
to our knowledge (except Lucent has released a Linux-only driver for one of
its PCI "software" modems).  The self-proclaimed Microsoft PC 97 (or later)
standard will probably only make matters worse since its only purpose to
ensure that PCs are "optimized to run Windows 95 and Windows NT 4.0 and future
versions of these operating systems".

With the exception noted (the Lucent modem), drivers for "Win" devices are
available only for Windows, since the Windows market dwarfs that of any
particular UNIX brand, and for that matter all UNIXes (or for that matter, all
non-Windows operating systems) combined.  If your version of UNIX (SCO, Linux,
BSDI, FreeBSD, etc) does not support a particular device, then C-Kermit can't
use it either.  C-Kermit, like any UNIX application, must access all devices
through drivers and not directly.

Don't waste time thinking that you, or anybody else, could write a Linux (or
other UNIX) driver for a Winmodem or other "Win" device.  First of all, these
devices generally require realtime control, but since UNIX (unlike Windows) is
a true multitasking system, realtime device control is not possible outside
the kernel.  Second, the specifications for these devices are secret and
proprietary, and each one (and each version of each one) is potentially
different.  Third, a Winmodem driver would be enormously complex; it would
take years to write and debug, by which time it would be obsolete.

Before you buy a new PC or add-on equipment, especially serial ports, internal
modems, or printers, make sure they are compatible with your version of UNIX.
This is becoming an ever-greater challenge; only a huge company like Microsoft
can afford to be constantly cranking out and/or verifying drivers for the
thousands of video boards, sound cards, network adapters, SCSI adapters,
buses, etc, that spew forth in an uncontrolled manner from all corners of the
world on a daily basis.  With very few exceptions, makers of PCs assemble the
various components and then verify them only with Windows, which they must do
since they are, no doubt, preloading the PC with Windows.  To find a modern PC
that is capable of running a variety of non-Windows operating systems
(e.g. Linux, SCO OpenServer, Unixware, and Solaris) is a formidable challenge
requiring careful study of each vendor's "compatibility lists" and precise
attention to exact component model numbers and revision levels.

Modems: External modems are recommended.  Internal PC modems (even when they
are not Winmodems, which is increasingly unlikely in new PCs) are always
trouble, especially in UNIX.  Even when they work for dialing out, they might
not work for dialing in, etc.  Problems that occur when using an internal
modem can almost always be eliminated by switching to an external one.  Even
when an internal modem is not a Winmodem or Plug-n-Play, it is often a no-name
model of unknown quality -- not the sort of thing you want sitting directly on
your computer's bus.  (Even if it does not cause hardware problems, it
probably came without a command list, so no UNIX software will know how to
control it.)  For more about UNIX compatible modems, see:

  http://www.o2.net/~gromitkc/winmodem.html

Multiple modems: Remember that PCs, even now -- 2 decades after the PC was
first introduced -- are not (in general) capable of supporting more than 2
serial devices.  Here's a short success story from a recent newsgroup posting:
"I have a Diamond SupraSonic II dual modem in my machine. What I had to end up
doing is buying a PS/2 mouse and port and install it. Had to get rid of my
serial mouse. I also had to disable PnP in my computer bios. I was having IRQ
conflicts between my serial mouse and "com 3". Both modems work fine for me.
My first modem is ttyS0 and my second is ttyS1."  Special third-party
multiport boards such as DigiBoard are available for certain UNIX platforms
(typically SCO, maybe Linux) that come with special platform-specific drivers.

Character sets: PCs generally have PC code pages such as CP437 or CP850, and
these are often used by PC-based UNIX operating systems, particularly on the
console.  These are supported directly by C-Kermit's SET FILE CHARACTER-SET
and SET TERMINAL CHARACTER-SET commands.  Some PC-based UNIX versions, such as
recent Red Hat Linux releases, might also support Microsoft Windows code pages
such as CP1252, or even Latin Alphabet 1 itself (perhaps displayed with CP437
glyphs).

Certain Windows code pages are not supported directly by C-Kermit, but since
they are ISO Latin Alphabets with nonstandard "extensions" in the C1 control
range, you can substitute the corresponding Latin alphabet (or other character
set) in any C-Kermit character-set related commands:

  Windows Code Page    Substitution
   CP 1004              Latin-1
   CP 1051              HP Roman-8

Other Windows code pages are mostly (or totally) incompatible with their
Latin Alphabet counterparts (e.g. CP1250 and Latin-2), but several of these
are supported by C-Kermit 7.0 (1250, 1251, and 1252).

Finally, note that as a real operating system, UNIX (unlike Windows) does not
provide the intimate connection to the PC keyboard, screen, and mouse that you
might expect.  UNIX applications can not "see" the keyboard, and therefore can
not be programmed to understand F-keys, Editing keys, Alt-key combinations,
and the like.  This is because (a) UNIX is a portable operating system, not
only for PCs; and (b) UNIX sessions can come from anywhere, not just the PC's
keyboard and screen.

(3.1) C-KERMIT AND AIX

For additional information see the AIX FAQ:

  http://www.emerson.emory.edu/services/aix-faq/
  http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
  http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html
  http://aixpdslib.seas.ucla.edu/
  ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
  ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix

and/or read the comp.unix.aix newsgroup.

C-Kermit won't be able to "set line /dev/tty0" (or any other dialout device)
if you haven't installed "cu" or "uucp" on your system, because installing
these is what creates the UUCP lockfile directory.  If SET LINE commands
always result in "Sorry, access to lock denied", even when C-Kermit has been
given the same owner, group, and permissions as cu:

  -r-sr-xr-x   1 uucp     uucp       67216 Jul 27 1999  cu

and even when you run it as root, then you must go back and install "cu" from
your AIX installation media.

Streaming transfers into AIX 4.2 or 4.3 (through the AIX Telnet server) have
been observed to fail, when exactly the same kind of transfers into AIX 4.1
work without incident.  The error reported by AIX is "interrupted system
call".  Streaming transfers work perfectly, however, if the AIX Telnet server
is removed from the picture (e.g, by using "set host * 3000" on AIX, or by
using Rlogin instead of Telnet).  They also work perfectly if the Telnet
connection is forced into binary mode (C-Kermit command "set telopt requested
requested").  In case of file-transfer failure on a Telnet connection to AIX
4.2 or 4.3, tell AIX C-Kermit to "set streaming off" and/or tell the file
sender to prefix all control characters ("set prefixing all").  Also be sure
that the AIX C-Kermit on the remote end has "set flow none" (which is the
default).

About AIX version numbers:  "uname -a" tells the two-digit version number,
such as 3.2 or 4.1.  The three-digit form can be seen with the "oslevel"
command (this information is unavailable at the API level and is reportedly
obtained by scanning the installed patch list).  Supposedly all three-digit
versions within the same two-digit version (e.g. 4.3.1, 4.3.2) are binary
compatible; i.e. a binary built on any one of them should run on all others,
but this is not verified.

IMPORTANT: Do NOT try to run AIX 3.x C-Kermit binaries on AIX 4.x (or vice
versa).  Obtain -- or build -- the C-Kermit binary that is appropriate for
your AIX version.  In general, it is always better to build from source code.

According to IBM's "From Strength to Strength" document (21 April 1998),
in AIX 4.2 and later "Async supports speeds on native serial ports up to
115.2kbps".  However, no API is documented to achieve serial speeds higher
than 38400 bps.  Apparently the way to do this -- which might or might not
work only on the IBM 128-port multiplexer -- is:

  cxma-stty fastbaud /dev/tty0

which, according to "man cxma-stty":

  fastbaud Alters the baud rate table, so 50 baud becomes 57600 baud.
  -fastbaud Restores the baud rate table, so 57600 baud becomes 50 baud.

Presumably (but not certainly) this extrapolates to 110 "baud" becomes
76800 bps, and 150 becomes 115200 bps.  So to use high serial speeds in AIX
4.2 or 4.3, the trick would be to give the "cxma-stty fastbaud" command for
the desired tty device before starting Kermit, and then use "set speed 50",
"set speed 110", or "set speed 150" to select 56700, 76800, or 115200 bps.
It is not known whether cxma-stty requires privilege.

According to one report, "Further investigation with IBM seems to indicate
that the only hardware capable of doing this is the 128-port multiplexor with
one (or more) of the 16 port breakout cables (Enhanced Remote Async Node
16-Port EIA-232). We are looking at about CDN$4,000 in hardware just to hang a
56kb modem on there. Of course, we can then hang 15 more, if we want. This
hardware combo is described to be good to 230.4kbps."

Another report says (quote from AIX newsgroup, March 1999):

  The machine type and the adapter determine the speed that one can actually
  run at.  The older microchannel machines have much slower crystal
  frequencies and may not go beyond 76,800.  A feature put into AIX 421
  allows one to key in non-POSIX baud rates and if the uart can support that
  speed, it will get set. this applies also to 43p's and beyond.  115200 is
  the max for the 43P's native serial port.  As crytal frequencies continue
  to increase, the built-in serial ports speeds will improve.  To use 'uucp'
  or 'ate' at the higher baud rates, configure the port for the desired
  speed, but set the speed of uucp or ate to 50.  Any non-POSIX speeds set
  in the ttys configuration will the be used.  In the case of the 128-port
  adapters or the ISA 8-port or PCI 8-port adapter, there are only a few
  higher baud rates.

   a. Change the port  to enable high baud rates:

      B50 for 57600
      B75 for 76800
      B110 for 115200
      B200 for 230000

   b. chdev -l ttyX -a fastbaud=enable

  For the 128 ports original style rans, only 57600 bps is supported.
  For the new enhanced RANs, up to 230Kbps is supported.

(end quote)

Note that some RS/6000s (e.g. the IBM PowerServer 320) have nonstandard
rectangular 10-pin serial ports; the DB-25 connector is NOT a serial port;
it is a parallel printer port.  IBM cables are required for the serial ports,
(The IBM RT PC also had rectangular serial ports -- perhaps the same as these,
perhaps different.)

If you dial in to AIX through a modem that is connected directly to an AIX
port (e.g. on the 128-port multiplexer) and find that data is lost, especially
when uploading files to the AIX system (and system error logs report buffer
overruns on the port):

 1. Make sure the port and modem are BOTH configured for hardware (RTS/CTS)
    flow control.  The port is configured somewhere in the system
    configuration, outside of Kermit.

 2. Tell C-Kermit to "set flow keep"; experimentation shows that SET FLOW
    RTS/CTS has no effect when used in remote mode (i.e. on /dev/tty, as
    opposed to a specify port device).

Several people have reported that C-Kermit (version unspecified) causes
AIX 4.2 (or later) to "freeze" or "hang" or "halt".  No further details are
known at this time.  However:

 1. No user-mode application should ever be able to make AIX or any other
    version of UNIX freeze, hang, or halt; if it does, this indicates a
    serious bug in AIX, which should be reported immediately to IBM.

 2. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support
    and other AIX bugs are available from IBM at:

      http://service.software.ibm.com/rs6000/