file-transfer partner to the local Kermit and communicates only   through its standard input and output.      At any moment, a Kermit program can be in any of the following states.   It's important to know what they are and how to change from one to the   other.      Command state                    In this state, Kermit reads commands from:                    + Your keyboard; or:          + A file, or:          + A macro definition.                      You can exit from Command state back to Unix with the EXIT or          QUIT command (same thing). You can enter Connect state with any          of various commands (CONNECT, DIAL, TELNET, etc). You can enter          file transfer state with commands like SEND, RECEIVE, and GET.          You can enter Server state with the SERVER command. The TAKE          command tells Kermit to read and execute commands from a file.          The (perhaps implied) DO command tells Kermit to read and          execute commands from a macro definition. While in Command          state, you can interrupt any command, macro, or command file by          typing Ctrl-C (hold down the Ctrl key and press the C key);          this normally brings you back to the prompt.             Shell state                    You can invoke an inferior shell or external command from the          Kermit command prompt by using the PUSH, RUN (!), EDIT, or          BROWSE command. While the inferior shell or command is active,          Kermit is suspended and does nothing. Return to Kermit Command          state by exiting from the inferior shell or application.             Connect state                    In this state, which can be entered only when in Local mode          (i.e. when Kermit has made a connection to another computer),          Kermit is acting as a terminal to the remote computer. Your          keystrokes are sent to the remote computer and characters that          arrive over the communication connection are displayed on your          screen. This state is entered when you give a CONNECT, DIAL,          TELNET, RLOGIN, or IKSD command. You can return to command          state by logging out of the remote computer, or by typing:            Ctrl-\c          That is: Hold down the Ctrl key and press the backslash key,          then let go of the Ctrl key and press the C key. This is called          escaping back. Certain other escape-level commands are also          provided; type Ctrl-\? for a list. For example, you can enter          Shell state with:            Ctrl-\!          To send a Ctrl-\ to the host while in Connect state, type two          of them in a row. See HELP CONNECT and HELP SET ESCAPE for more          info.             Local file-transfer state                    In this state, Kermit is sending packets back and forth with          the other computer in order to transfer a file or accomplish          some other file-related task. And at the same time, it is          displaying its progress on your screen and watching your          keyboard for interruptions. In this state, the following          single-keystroke commands are accepted:                      X Interrupt the current file and go on to the next (if any).            Z Interrupt the current file and skip all the rest.            E Like Z but uses a "stronger" protocol (use if X or Z don't          work).            Ctrl-C   Interrupt file-transfer mode (use if Z or E don't          work).                    Kermit returns to its previous state (Command or Connect) when          the transfer is complete or when interrupted successfully by X,          Z, E, or Ctrl-C (hold down the Ctrl key and press the C key).             Remote file-transfer state                    In this state, Kermit is exchanging file-transfer packets with          its local partner over its standard i/o. It leaves this state          automatically when the transfer is complete. In case you find          your local Kermit in Connect state and the remote one in          File-transfer state (in which it seems to ignore your          keystrokes), you can usually return it to command state by          typing three Ctrl-C's in a row. If that doesn't work, return          your local Kermit to Command state (Ctrl-\ C) and type          "e-packet" and then press the Return or Enter key; this forces          a fatal Kermit protocol error.             Remote Server state                    This is like Remote File-transfer state, except it never          returns automatically to Command state. Rather, it awaits          further instructions from the client program; that is, from          your Local Kermit program. You can return the Remote Server to          its previous state by issuing a "finish" command to the client,          or if you are in Connect state, by typing three Ctrl-C's in a          row. You can tell the server job to log out and break the          connection by issuing a "bye" command to the client.             Local Server state                    Like Remote-Server state, but in local mode, and therefore with          its file-transfer display showing, and listening for single-key          commands, as in Local File-transfer state. Usually this state          is entered automatically when a remote Kermit program gives a          GET command.             C-Kermit, Kermit 95, and MS-DOS Kermit all can switch automatically   from Connect state to Local File-transfer state when you initiate a   file transfer from the remote computer by starting Kermit and telling   it to send or get a file, in which case, Connect state is   automatically resumed after the file transfer is finished.      Note that C-Kermit is not a terminal emulator. It is a communications   application that you run in a terminal window (e.g. console or Xterm).   The specific emulation, such as VT100, VT220, Linux Console, or Xterm,   is provided by the terminal window in which you are running C-Kermit.   Kermit 95 and MS-DOS Kermit, on the other hand, are true terminal   emulators. Why is C-Kermit not a terminal emulator? [85]CLICK HERE to   read about it.      [ [86]Kermit Home ] [ [87]C-Kermit Home ] [ [88]C-Kermit FAQ ]    ________________________________________________________________________    MAKING CONNECTIONS [ [89]Top ] [ [90]Contents ] [ [91]Next ] [ [92]Previous ]     Here is how to make different kinds of connections using interactive   Kermit commands (as noted above, you can also make connections with   command-line options). Note that you don't have to make connections   with Kermit. It can also be used on the far end of a connection as the   remote file transfer and management partner of your local   communications software.      Making a Telnet Connection                    At the C-Kermit command prompt, simply type:            telnet foo.bar.com         ; Substitute desired host name or address.  telnet xyzcorp.com 3000    ; You can also include a port number.          If the connection is successful, Kermit automically enters          Connect state. When you logout from the remote host, Kermit          automatically returns to its prompt. More info: HELP TELNET,          HELP SET TELNET, HELP SET TELOPT. Also see the [93]IKSD section          below.             Making an Rlogin connection                    This is just like Telnet, except you have to be root to do it          because Rlogin uses a privileged TCP port:            rlogin foo.bar.com         ; Substitute desired host name or address.          More info: HELP RLOGIN.             Making an SSH Connection                    Unlike Telnet and Rlogin, SSH connections are not built-in, but          handled by running your external SSH client through a          pseudoterminal. Using C-Kermit to control the SSH client gives          you all of Kermit's features (file transfer, character-set          conversion, scripting, etc) over SSH.            ssh foo.bar.com            ; Substitute desired host name or address.          More info: HELP SSH, HELP SET SSH.             Dialing with a Modem                    If it's an external modem, make sure it is connected to a          usable serial port on your computer with a regular          (straight-through) modem cable, and to the telephone jack with          a telephone cable, and that it's turned on. Then use these          commands:            set modem type usrobotics  ; Or other supported type  set line /dev/ttyS0        ; Specify device name  set speed 57600            ; Or other desired speed  set flow rts/cts           ; Most modern modems support this  set dial method tone       ; (or pulse)  dial 7654321               ; Dial the desired number          Type "set modem type ?" for a list of supported modem types. If          you omit the SET MODEM TYPE command, the default type is          "generic-high-speed", which should work for most modern          AT-command-set modems. If the line is busy, Kermit redials          automatically. If the call does not succeed, use "set dial          display on" and try it again to watch what happens. If the call          succeeds, Kermit enters Connect state automatically and returns          to its prompt automatically when you log out from the remote          computer or the connection is otherwise lost.                    You can also dial from a modem that is accessible by Telnet,          e.g. to a reverse terminal server. In this case the command          sequence is:            set host ts.xxx.com 2000   ; Terminal-server and port  set modem type usrobotics  ; Or other supported type  set dial method tone       ; (or pulse)  dial 7654321               ; Dial the desired number          If the terminal server supports the Telnet Com Port Option,          [94]RFC 2217, you can also give serial-port related commands          such as SET SPEED, SET PARITY, and so on, and Kermit relays          them to the terminal server using the protocol specified in the          RFC.                    More info: HELP SET MODEM, HELP SET LINE, HELP SET SPEED, HELP          SET FLOW, HELP DIAL, HELP SET DIAL, HELP SET MODEM, HELP SET          CARRIER-WATCH, SHOW COMMUNICATIONS, SHOW MODEM, SHOW DIAL.             Direct Serial Port                    Connect the two computers, A and B, with a null modem cable (or          two modem cables interconnected with a null-modem adapter or          modem eliminator). From Computer A:            set modem type none        ; There is no modem  set line /dev/ttyS0        ; Specify device name  set carrier-watch off      ; If DTR and CD are not cross-connected  set speed 57600            ; Or other desired speed  set flow rts/cts           ; If RTS and CTS are cross-connected  set flow xon/xoff          ; If you can't use RTS/CTS  set parity even            ; (or "mark" or "space", if necessary)  set stop-bits 2            ; (rarely necessary)  connect                    ; Enter Connect (terminal) state          This assumes Computer B is set up to let you log in. If it          isn't, you can run a copy of Kermit on Computer B and follow          approximately the same directions. More info: As above plus          HELP CONNECT.             With modems or direct serial connections, you might also have to "set   parity even" (or "mark" or "space") if it's a 7-bit connection.      Of the connection types listed above, only one can be open at a time.   However, any one of these can be open concurrently with an [95]FTP or   HTTP session. Each connection type can be customized to any desired   degree, scripted, logged, you name it. See the manual.      NOTE: On selected platforms, C-Kermit also can make X.25 connections.   See the manual for details.      [ [96]Kermit Home ] [ [97]C-Kermit Home ] [ [98]C-Kermit FAQ ]    ________________________________________________________________________    TRANSFERRING FILES WITH KERMIT [ [99]Top ] [ [100]Contents ] [ [101]Next ] [  [102]Previous ]       * [103]Downloading Files     * [104]Uploading Files     * [105]Kermit Transfers the Old-Fashioned Way     * [106]If File Transfer Fails     * [107]Advanced Kermit File Transfer Features     * [108]Non-Kermit File Transfer          There is a [109]widespread and persistent belief that Kermit is a slow   protocol. This is because, until recently, it used conservative tuning   by default to make sure file transfers succeeded, rather than failing   because they overloaded the connection. Some extra commands (or   command-line options, like -Q) were needed to make it go fast, but   nobody bothered to find out about them. Also, it takes two to tango:   most non-Kermit-Project Kermit protocol implementations really ARE   slow. The best file-transfer partners for C-Kermit are: another copy   of [110]C-Kermit (7.0 or later) and [111]Kermit 95. These combinations   work well and they work fast by default. MS-DOS Kermit is good too,   but you have to tell it to go fast (by giving it the FAST command).      Furthermore, all three of these Kermit programs support "autodownload"   and "autoupload", meaning that when they are in Connect state and a   Kermit packet comes in from the remote, they automatically switch into   file transfer mode.