ckcbwr.txt

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

   Question-mark help does not work during execution of an ASKQ command.
   The question marks are simply accepted as text.

   In OUTPUT commands only, \B sends a BREAK signal, \L sends a Long
   BREAK signal, and \N sends a NUL (ASCII 0). BREAK and Long BREAK are
   special signals, not characters, and NUL is a character that normally
   cannot be included in a C string, since it is the C string terminator.
   If you really want to output a backslash followed by a B, an L, or an
   N (as is needed to configure certain modems, etc), double the
   backslash, e.g. "output \\B". In C-Kermit 7.0 or later, you can disarm
   and re-arm the special OUTPUT-command escapes (\B, \L, and \N) with
   SET OUTPUT SPECIAL-ESCAPES { OFF, ON }.

   When using the command-line processor ("kermit -l /dev/tty00 -b
   19200", etc), note that in some cases the order of the command-line
   options makes a difference, contrary to the expectation that order of
   command-line options should not matter. For example, the -b option
   must be given after the -l option if it is to affect the device
   specified in the -l option.
    ________________________________________________________________________

  3. MULTIPLE SESSIONS

   [ [36]Top ] [ [37]Contents ] [ [38]Next ] [ [39]Previous ]

   C-Kermit 7.0 and earlier do not support multiple sessions. When you
   SET LINE (or SET PORT, same thing) to a new device, or SET HOST to a
   new host, the previous SET LINE device or network host connection is
   closed, resulting in hangup of the modem or termination of the network
   connection. In windowing environments like HP-VUE, NeXTSTEP, Windows,
   OS/2, etc, you can run separate copies of Kermit in different windows
   to achieve multiple sessions.

   To achieve multiple sessions through a single serial port (e.g. when
   dialing up), you can install SLIP or PPP on your computer and then use
   C-Kermit's TCP/IP support over the SLIP or PPP connection, assuming
   you also have TCP/IP networking installed on your computer.

   C-Kermit 8.0 has the same restriction on SET LINE and SET HOST
   sessions: only one regular session (dialout, Telnet, etc) can be open
   at a time. However, version 8.0 adds two new kinds of sessions: FTP
   and HTTP; one or both of these can be open at the same as a regular
   session.
    ________________________________________________________________________

  4. NETWORK CONNECTIONS

   [ [40]Top ] [ [41]Contents ] [ [42]Next ] [ [43]Previous ]

  FTP Client Bugs

   The Unix C-Kermit 8.0.206 FTP client had the following bugs at the
   time most of the 8.0.206 binaries were built for the C-Kermit 8.0
   CDROM:

    1. FTP MGET fails when directory segments contain wildcards, as in
       "ftp mget */data/*.dat". Work around by doing a separate MGET for
       each source directory.
    2. FTP MGET can fail or produce random side effects if you have a
       TMPDIR or CK_TMP environment variable definition in effect, or a
       SET TEMP-DIRECTORY value, longer than 7 characters. Work around by
       giving a SET TEMP-DIRECTORY command with a short value, such as
       "/tmp".

   These two bugs are fixed in the source code that is included on the
   CDROM, and also in Kermit 95 2.1.1. You can tell if a C-Kermit 8.0.206
   binary has these fixes by typing SHOW VERSION; if it says "FTP Client,
   8.0.200, 24 Oct 2002" it has the fixes; if the edit number is less
   that 200, it doesn't, in which case can build a new binary from the
   source code (or contact us and we'll try to get get one for you).

  Making TCP/IP Connections Can Take a Long Time

   The most frequently asked question in many newsgroups is "Why does it
   take such a long time to make a Telnet connection to (or from) my
   (e.g.) Linux PC?" (this applies to Kermit as well as to regular Telnet
   clients):

    1. Most Telnet servers perform reverse DNS lookups on the client for
       security and/or logging reasons. If the Telnet client's host
       cannot be found by the server's 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.
    2. 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. C-Kermit 7.0 and later strictly enforce Telnet protocol rules. One
       such rule is that certain negotiations must be responded to. If
       C-Kermit sends a such a negotiation and the host does not respond,
       C-Kermit waits a long time for the reply (in case the network is
       congested or the host is slow), but eventually will time out. To
       eliminate the waits (and therefore risk possible protocol
       mismatches -- or worse -- between Telnet client and server), tell
       C-Kermit to SET TELNET WAIT OFF (or include the /NOWAIT switch
       with the TELNET command).

  The Rlogin Client

   In multiuser operating systems such as UNIX and VMS, TCP/IP Rlogin
   connections are available only to privileged users, since "login" is a
   privileged socket. Assuming you are allowed to use it in the first
   place, it is likely to behave differently depending on what type of
   host you are rlogging in to, due to technical reasons having to do
   with conflicting interpretations of RFC793 (Out-Of-Band Data) and
   Rlogin (RFC1122)... "Specifically, the TCP urgent pointer in BSD
   points to the byte after the urgent data byte, and an RFC-compliant
   TCP urgent pointer points to the urgent data byte. As a result, if an
   application sends urgent data from a BSD-compatible implementation to
   an [44]RFC-1122 compatible implementation then the receiver will read
   the wrong urgent data byte (it will read the byte located after the
   correct byte in the data stream as the urgent data byte)." Rlogin
   requires the use of OOB data while Telnet does not. Therefore, it is
   possible for Telnet to work between all systems while BSD and System V
   TCP/IP implementations are almost always a bad mix.

  The Telnet Client

   On a TCP/IP TELNET connection, you should normally have PARITY set to
   NONE and (except in VMS C-Kermit) FLOW-CONTROL also set to NONE. If
   file transfer does not work with these settings (for example, because
   the remote TELNET server only gives a 7-bit data path), use SET PARITY
   SPACE. Do not use SET PARITY MARK, EVEN, or ODD on a TELNET connection
   -- it interferes with TELNET protocol.

   If echoing does not work right after connecting to a network host or
   after dialing through a TCP/IP modem server, it probably means that
   the TELNET server on the far end of the connection is executing the
   TELNET protocol incorrectly. After initially connecting and
   discovering incorrect echoing (characters are echoed twice, or not at
   all), escape back, give the appropriate SET DUPLEX command (FULL or
   HALF), and then CONNECT again. For a consistently misbehaving
   connection, you can automate this process in a macro or TAKE file.

   TELNET sessions are treated just like serial communications sessions
   as far as "terminal bytesize" and "command bytesize" are concerned. If
   you need to view and/or enter 8-bit characters during a TELNET
   session, you must tell C-Kermit to SET TERMINAL BYTESIZE 8, SET
   COMMAND BYTESIZE 8, and SET PARITY NONE.

   If you SET TELNET DEBUG ON prior to making a connection, protocol
   negotiations will be displayed on your screen. You can also capture
   them in the debug log (along with everything else) and then extract
   them easily, since all Telnet negotiations lines begin with
   (uppercase) "TELNET".
    ________________________________________________________________________

  5. MODEMS AND DIALING

   [ [45]Top ] [ [46]Contents ] [ [47]Next ] [ [48]Previous ]

   External modems are recommended because:

     * They don't need any special drivers.
     * They are less likely to interfere with normal operation of your
       computer.
     * You can use the lights and speaker to troubleshoot dialing.
     * You can share them among all types of computers.
     * You can easily turn them off and on when power-cycling seems
       warranted.
     * They are more likely to have manuals.

   Modems can be used by C-Kermit only when they are visible as or
   through a regular serial port device. Certain modems can not be used
   in this normal way on many kinds of computers: Winmodems, RPI modems,
   Controllerless modems, the IBM Mwave, etc; all of these require
   special drivers that perform some, most, or all of the modem's
   functions in software. Such drivers are generally NOT available in
   UNIX or other non-Windows (or non-OS/2, in the case of the Mwave)
   platforms.

   In order to dial a modem, C-Kermit must know its repertoire of
   commands and responses. Each modem make and model is likely to have a
   different repertoire. Since Kermit has no way of knowhing which kind
   of modem will be dialed, normally you have to tell it with a SET MODEM
   TYPE command, e.g.:

  set modem type usrobotics
  set line /dev/cua0
  set speed 57600
  dial 7654321

   In the early days, there was a wide variety of modems and command
   languages. Nowadays, almost every modem uses the Hayes AT command set
   (but with some differences in the details) and its startup
   configuration includes error correction, data compression, and
   hardware (RTS/CTS) flow control. As long as C-Kermit is capable of
   hardware flow control (as it is on many, but not all, the platforms
   where it runs, since some operating systems don't support it), the
   modem can be dailed immediately, without lengthy configuration
   dialogs, and in fact this is what SET MODEM TYPE GENERIC-HIGH-SPEED
   does. In C-Kermit 8.0, GENERIC-HIGH-SPEED has become the default modem
   type, so now it is usually possible to SET LINE, SET SPEED, and DIAL
   without having to identify your modem. If this doesn't work, of
   course, then you might have to fall back to the tradiational method:
   Give a SET MODEM TYPE for a specific modem first, then SET LINE, SET
   SPEED, and DIAL.

   An important change in C-Kermit 6.0 is that when you give a SET MODEM
   TYPE command to tell Kermit what kind of modem you have, Kermit also
   sets a number of other modem-related parameters automatically from its
   internal modem database. Thus, the order in which you give
   modem-related commands is significant, whereas in prior releases they
   could be given in any order.

   In particular, MODEM SPEED-MATCHING is set according to whether the
   modem is known to be capable of speed buffering. SET MODEM TYPE
   HAYES-2400 automatically turns SPEED-MATCHING ON, because when the
   Hayes 2400 reports a particular speed in its CONNECT message, that
   means its interface speed has changed to that speed, and C-Kermit's
   must change accordingly if it is to continue communicating. This might
   cause some confusion if you use "set modem type hayes" for dialing a
   more advanced type of modem.

   The new default for flow control is "auto", meaning "do the right
   thing for each type of connection". So (for example) if your version
   of C-Kermit supports SET FLOW RTS/CTS and your modem also supports
   RTS/CTS, then Kermit automatically sets its flow control to RTS/CTS
   and set modem's flow control to RTS/CTS too before attempting to use
   the modem.

   For these reasons, don't assume that "set modem type hayes" should be
   used for all modems that uses the Hayes AT command set. "set modem
   type hayes" really does mean Hayes 1200 or 2400, which in turn means
   no hardware flow control, and no speed buffering. This choice will
   rarely work with a modern high-speed modem.
    ________________________________________________________________________

  6. DIALING HINTS AND TIPS

   [ [49]Top ] [ [50]Contents ] [ [51]Next ] [ [52]Previous ]

   If you have a high-speed, error-correcting, data-compressing,
   speed-buffering modem, you should fix the modem's interface speed as
   high as possible, preferably (at least) four times higher than its
   maximum connection (modulation) speed to allow compression to work at
   full advantage. In this type of setup, you must also have an effective
   means of flow control enabled between C-Kermit and the modem,
   preferably hardware (RTS/CTS) flow control. On platforms that do not
   support hardware flow control, it is usually possible to select
   software flow control (Xon/Xoff), and C-Kermit will do its best to set
   the modem for local Xon/Xoff flow control too (but then, of course,
   Ctrl-S and Ctrl-Q characters can not be transmitted on the
   connection).

   If you are having trouble dialing your modem, SET DIAL DISPLAY ON to
   watch the dialing interactions between C-Kermit and your modem.
   Consult Chapters 3-4 of [53]Using C-Kermit (2nd Ed) for modem-dialing
   troubleshooting instructions. The following sections offer some
   addtional hints and tips.

  6.1. Syntax

   If you want to dial a number that starts with #, you'll need to quote
   the "#" character (as \# or \{35}), since it is also a comment
   introducer:

  C-Kermit>dial #98765421-1-212-5551212   ; Looks like a comment
  ?You must specify a number to dial
  C-Kermit>dial \#98765421-1-212-5551212  ; Works OK
  C-Kermit>dial =#98765421-1-212-5551212  ; This works too

   When using a dialing directory, remember what happens if a name is not
   found:

  C-Kermit>dial xyzcorp
  Lookup: "xyzcorp" - not found - dialing as given

   This normally does no harm, but some modems might behave strangely
   when given dial strings that contain certain letters. For example, a