As of K95 Version: 2.1.3
This File Last Updated: Sat Oct 25 14:01:06 2003
Invoking Kermit 95 from: [ Visual Basic ] [ Java ] [ C++ ]
At some point a new edition of Using C-Kermit will be issued, incorporating the new material.
Then, each major C-Kermit platform (Unix, VMS, Windows, ...) has its own platform-specific manual. The manual for Kermit 95 is included with K95 itself, and is accessible from Kermit 95 by:
The Kermit 95 manual concentrates on the Dialer (how to graphically set up and launch connections) and the Terminal Emulator (terminal types, scrollback, key mapping, colors, local printing, character sets, etc).
In addition to the K95 manual, K95 also includes a great deal of other documentation, including the C-Kermit 7.0 and 8.0 manual supplements, linked to from the K95 manual. You can also find a brief tutorial for K95 HERE and another for C-Kermit HERE.
Those who purchased shrink-wrapped copies of K95 through version 1.1.17 received a printed copy of Using C-Kermit. Those who purchased shrinkwrapped copies of K95 1.1.20 received a PDF version of the book on CDROM. Due to renegotiated agreements between publishers, the new Kermit 95 2.1 package (January 2003) does not include the PDF version of Using C-Kermit, but it does include a license key to let you download it (note: this applies ONLY to owners of the K95 2.1 shrinkwrap). Electronically delivered versions of K95 do not include the Using C-Kermit book because:
This is the primary reason that the cost of the electronically delivered version of K95 is so low. The shrinkwrapped version costs more.
It is expected that the PDF version of Using C-Kermit will also be available for purchase as an "e-book" from the publisher, Digital Press, or an authorized agent; the details are not yet available as of this writing (January 2003).
As for "Kermit"... This name was chosen on a whim back in 1981, before we had any idea that Kermit protocol or software would ever escape the bounds of Columbia University or remain current and popular for decades. The whim, in turn, was based on (a) a Muppets calandar on the wall when we were searching for a name, and (b) the fact that some of us had small children addicted to The Muppet Show. Although a name like "Kermit" might have certain drawbacks in today's fast-paced, high-powered software marketplace, it also has (we think) a certain charm and simplicity: It's easy to say, easy to spell, and utterly lacking in hyperbole and condescension. But if you prefer, feel free to refer to K95 as:
UltraHyperExtremeTurboCyberOpenEnterpriseSmartSecureE-CommercePowerPro-2003 Gold
set bell audible ; Make sure Ctrl-G is audible set terminal margin-bell on 72 ; Margin bell like typewriter set terminal statusline off ; For scroll detection set terminal screen-update smooth ; Or "fast" - depends on screen reader set terminal screen-optimization on ; This is the default anyway set terminal mouse off ; Might be required by some readers
In addition, certain keys might need to be set to \Kignore, so they can be used as controls for the screen reader or Braille software. Depending on the specific screen reader, these might be the keys on the numeric keypad. The method for doing all this is illustrated in the ASAP.KSC file, for setting K95 up to be used with the ASAP screen reader.
For related resources, see our links page.
Kermit 95 2.1 is distributed as a full upgrade installation to those who have earlier K95 versions, no patching required.
Kermit 95 1.1.17 and later are distributed on CDROM. Version 1.1.16 was distributed only in patch form. Versions 1.1.15 and earlier were distributed on diskette. Since the last diskette release was in 1997, we've removed the longwinded discussion of problems with diskettes and diskette drives from the FAQ.
Occasionally it happens that the Upgrade Installer reports it can't find a licensed version, and offers to let you browse to the location, but even when you choose the registered copy of the K95.EXE executable, it reports failure. This seems to happen only when you chose the "Don't make Registry entries" option when you installed your original version. If you remove your old version and reinstall it, but this time choose to make Registry entries, then the Upgrade Installer should be able to find it.
One user reported that the Upgrade Installer complained (on Windows 2000) "No valid Kermit 95 installation in C:\K95, try a different path". Repeated attempts to run the installer said the same thing. Rebooting didn't help. Downloading a fresh copy of the installer didn't help. He shut down and turned off the machine and went home. The next morning when he turned on the machine and tried the procedure again, it worked.
If all else fails, we would appreciate it if you would simply buy a new version; discounted copies are available on the Web from e-academy.com. Due to the harsh economic conditions, we no longer have sufficient staff to help people one-on-one with relatively ancient Kermit releases. Most other companies would have made you pay for upgrades all these years, and we never have -- which might be part of the problem!
When people ask how to accomplish a certain customization, we give them a command (or list of commands) to do it. The next question is invariably, "where do I put these commands?" The answer is, "If you want them in effect for all your K95 sessions, put them in your customization file," meaning: edit your K95CUSTOM.INI file to include the desired commands. In early K95 versions, you could find this file in the same directory as K95 itself. But now where is it??? This is thoroughly explained in in the K95 Read Me document, but here is a simple recipe for how to edit your K95CUSTOM.INI file, wherever it is, in K95 1.1.21 or later. Start K95G or K95, then:
K-95> kcd appdata K-95> run start notepad k95custom.ini
Remember, Kermit command files should be edited only by plain-text editors such as Notepad, DOS EDIT, or EMACS, not word processors like MS Word.
The Dialer is the graphical front end for Kermit 95. It is built using a portable GUI builder that creates versions for both Windows and OS/2.
The remaining .DAT files are associated with the GUI setup and registration programs.
If you use K95 to make different types of connections, not just TAPI, take the TAPI-related commands out of your K95CUSTOM.INI file.
The following command-line options can be used to tell K95 not to load certain DLLs; this can speed startup:
These numbers are powers of 2, representing single bits, and can be added to form a "bit mask" of options. Thus "-# 30" means don't load any of the above. On a 90 MHz PC, starting K95 1.1.16 with "-# 30" took about 1 second; without it about 4 seconds. You can omit the network DLLs if you will not be making network connections. You can omit TAPI if (a) you will not be making dialout connections, or (b) you will be using COM1 or COM2 directly rather than the TAPI modem device (i.e. the Control Panel name for the modem). You can omit Kerberos DLLs if you will not be making secure connections with Kerberos authentication. You can omit the XYZMODEM DLLs if you will not be transferring files with XMODEM, YMODEM, or ZMODEM.
It can take Windows 20-30 seconds to release the TAPI device if your modem is disconnected or powered off. When it is connected and turned on, it still can take 5-10 seconds. That's Windows, not Kermit, being slow. If you can use the SET PORT COMx / SET MODEM TYPE xxx interface instead of the TAPI one (which is possible only for standard COM ports, not Winmodems, etc), opening and closing of modems will be faster.
k95 scriptfilename arg1 arg2 arg3 ...
Specify the full pathname of K95 (or K95G) if it is not in the PATH. Specify the full pathname of the script file if it is not in the current directory.
In a shortcut to K95 or K95G you can put the script file name and arguments after the Kermit 95 executable name in the Target box of the Shortcut properties.
In a shortcut to a Kermit 95 script file, you can put the arguments to the script after the script file name in the Target box of the Shortcut properties.
From the Kermit 95 prompt, or within a Kermit 95 script, you can use the TAKE command, followed by the script file name, followed by its arguments.
k95g oofa.ksc --xpos:500 --ypos:500 = "This is script arg 1" scriptarg2
http://www.columbia.edu/kermit/helper.ksc ftp://kermit.columbia.edu/kermit/scripts/ckermit/helper.ksc
@start /w /min "C:\Program Files\Kermit 95 2.1\k95.exe" scriptname = args...
K95 2.1.3 and later also have a --minimized command-line option (--maximized too).
k95 -# 96
You can use it to make any kind of connection that you could make from a regular window: Telnet, SSH, Dialout, FTP, etc, and you can transfer files over the connection in the normal way.
The only fly in the ointment is that your keystrokes are read by EMACS, not K95, and EMACS intercepts Alt keys, F keys, and all Control characters, and furthermore, doesn't pass your keystrokes to Kermit until after you press the Enter key, so command-line editing (e.g. Ctrl-U), completion (Esc or Tab), ?-help, etc, don't work as they do when K95 has "direct access" to the keyboard. Escaping back from CONNECT mode is a bit tricky too; you have to type:
Ctrl-Q Ctrl-] c CR
That's Ctrl-Q followed by Ctrl-Rightbracket, then the letter C, then press the Enter key. In fact, every control character is intercepted by EMACS, so to pass it through to Kermit you have to quote it with Ctrl-Q, and you probably also have to hit Enter afterwards.
And of course, when K95 is using stdio, there is no terminal emulation, so you can't (for example) run EMACS in your CONNECT session to the host :-)
But on the plus side, your CONNECT session is an EMACS buffer, so you can move around in it, edit it, etc, with regular EMACS commands.
You can also write a simple Kermit script that awaits and handles incoming calls, something like:
set port tapi
set speed 57600
set flow rts/cts
while true {
cd some-directory
answer 0
if success {
server
hangup
}
}
Obviously many variations and refinements are possible.
set modem speed-matching { on, off }
SPEED-MATCHING ON means that Kermit should change its interface speed to match what the modem reports. Of course this setting is OFF by default.
The problem happens when Kermit's SPEED-MATCHING setting in ON but the modem is not really changing its interface speed. Then Kermit tries to change its interface speed to the one reported in the modem's CONNECT message. If it succeeds, you won't have any useful communication because the two interfaces are set to different speeds. If it fails ("ttsspd failed") it's because the reported speed (e.g. 31000) is not a legal interface speed.
This happens most commonly when you SET PORT TAPI to use Microsoft's built-in modem database, but the database erroneously calls for speed matching. The solution is to tell Kermit to SET MODEM SPEED-MATCHING OFF after you have selected the TAPI modem:
set port tapi set modem speed-matching off
Unfortunately, COM ports (or their modern substitutes) usually do not show up in the Control Panel Phone and Modems folder by default. If this is the case on your Windows PC:
Now when setting up Kermit 95, instead of using:
set port com1 (or com2, etc)
Use:
set port tapi Communications_cable_between_two_computers
If you have more than two COM ports, you might also have an interrupt conflict, since PCs have interrupt slots for only two COM ports. Solving PC interrupt conflicts is beyond the scope of this document.
SET TAPI MODEM-DIALING OFF SET PORT TAPI device-name SET SPEED 57600 ; Or other desired speed DIAL number>
Or if you want to dial the number by hand:
SET TAPI MODEM-DIALING ON SET CARRIER-WATCH OFF SET PORT TAPI device-name SET SPEED 57600 ; Or other desired speed CONNECT ; Enter terminal screen AT ; Now maybe you can type modem commands OK
By-hand dialing is not guaranteed to work with TAPI modems. Who knows, maybe the modem and its driver use some secret dialing protocol instead of AT commands.
If you are using the K95 Dialer:
Then when placing a call, make sure:
If the phone number is not in portable format, neither Kermit nor TAPI will be able to apply any prefixes or suffixes, including the credit card number. (This process is referred to as "Phone number conversions" in the menus.)
To create a new TAPI Location that uses a Credit Card:
Now when you dial, these dialing rules -- including the calling card number -- will be used.
SET PORT LPT1
(or other parallel-port device). Only DOS names are allowed. Parallel ports (like Serial ports) are not automatically installed as TAPI devices since they are not modems. If you want a parallel port installed as TAPI device you must manually install it as a "Direct Serial Connection" device.
set host hostname port set modem type name ... dial phone-number
However, since the modem is at the other end of a Telnet connection, you would not normally be able to control its serial-port settings. But if the terminal server supports RFC2217 Telnet COM Port Control K95 can do everything it could do with a local PC COM port: set the serial port interface speed and flow control method, sense modem signals, control the DTR signal, send BREAK, etc.
One user reported trouble using NASI until they selected "use hardware flow control always" in the NASI Workstation Global Settings configuration dialog.
Kermit 95 does not include a direct CAPI interface.
set host /server * 3000
to tell K95 to wait for an incoming TCP/IP connection on port 3000 and then automatically enter server mode when the connection comes in.
If your Windows user ID is the same as your ID on the host you are Telneting to, you only need to supply your password on the host, since it already has your user ID.
However, if they are not the same, or if you want to ensure predictable behavior, e.g. in a script program, you can instruct K-95 not to send your user ID with the command:
set login userid
(without a user ID). Then the host will give its normal login: or Username: prompt. Put this command in your K95CUSTOM.INI file or your script file, depending on where/when you want it to apply.
Also see: The Built-in FTP Client and Integrating Kermit 95 with Other Applications.
But on certain common types of terminals, notably the DEC VT100 series (VT100, VT102, VT220, VT320, etc), arrow keys can be in one of two modes: "Cursor" or "Application". In each mode, they send different codes. Thus, not only must Kermit's terminal type agree with the host, but so must the arrow keypad mode.
By default (that is, unless you give SET KEY commands to change things), Kermit uses the PC keyboard arrow keys as the VT terminal arrow keys. Each key has a "verb" assigned to it:
Key Keycode Assignment Description Up Arrow \4390 \Kuparr Sends what the terminal's Up-Arrow key sends Down Arrow \4392 \Kdnarr Sends what the terminal's Down-Arrow key sends Right Arrow \4391 \Krtarr Sends what the terminal's Right-Arrow key sends Left Arrow \4389 \Klfarr Sends what the terminal's Left-Arrow key sends
The \Kxxxx's are Kermit Keyboard Verbs (Kverbs). The arrow-key Kverbs track the arrow keypad mode automatically. For example, in VT100-series terminals:
Kverb Cursor Mode Application Mode \Kuparr CSI A SS3 A \Kdnarr CSI B SS3 B \Krtarr CSI C SS3 C \Klfarr CSI D SS3 D
CSI is ESC (ASCII 27) followed by left bracket ([) on a 7-bit connection or decimal 155 on an 8-bit connection, and SS3 is ESC followed by O (uppercase letter O) on a 7-bit connection and decimal 143 on an 8-bit connection. Thus, as you can see, in VTxxx emulation each arrow key can send any of four different code sequences depending on the arrow keypad mode (Cursor or Application) and Terminal Controls Mode (7-bit or 8-bit).
How does the arrow keypad mode change? The host can change it by sending special escape sequences, or you can change it yourself by using the command:
SET TERMINAL ARROW-KEYS { CURSOR, APPLICATION }
Ditto for Terminal Controls Mode:
SET TERMINAL CONTROLS { 7, 8 }
Key Keycode Assignment Description Num Lock \4496 \Kgold Sends what the terminal's "Gold" (PF1) key sends Keypad Slash (/) \4463 \Kpf2 Sends what the terminal's PF2 key sends Keypad Asterisk (*) \362 \Kpf3 Sends what the terminal's PF3 key sends Keypad Minus (-) \365 \Kpf4 Sends what the terminal's PF4 key sends Keypad Plus (+) \363 \Kpcoma Sends what the terminal's keypad comma key sends Keypad Enter \4365 \Kpenter Sends what the terminal's keypad Enter key sends
Problems occur when the terminal types don't match, the numeric keypad modes don't match, and/or the terminal controls modes don't match. Sometimes when the terminal receives "garbage" from the host, this can change the keypad mode. Relevant commands:
SET TERMINAL TYPE name
SET TERMINAL KEYPAD-MODE { NUMERIC, APPLICATION }
SET TERMINAL CONTROLS { 7, 8 }
The Kverbs that are assigned to the non-digit keypad keys by default vary with the terminal type. This example shows VT100-series terminal assignments. Other types of terminals do not have Gold or PFn keys and therefore have different verbs assigned.
Depending on the terminal type, the digit keys themselves can affected by the keypad mode. When the keypad is in Application mode, they send escape sequences (e.g. in VT100 emulation, the '4' key sends ESC, uppercase letter 'O', then lowercase letter 't'). When the keypad is in numeric mode, they send the digits that appear on their keytops (the '4' key sends the digit '4').
K95's numeric is in numeric mode by default. It can be changed by the SET TERMINAL KEYPAD command or by an escape sequence from the host (or "garbage" that mimics the escape sequence). To get the keypad back in numeric mode, you can:
Note that VT100-series terminals do not have function keys (although they do have four PF keys). Function (F) keys were introduced to DEC terminals with the VT200. Therefore if you are using Kermit to emulate a DEC VT100 or VT102, don't expect the F-keys to do anything unless you make explicit assignments to them (in this case, K95 treats F1-F4 as PF1-PF4 but F5 and above are undefined).
Higher-numbered function keys can be problematic. For example DEC VT220-series terminals have function keys up to F20, but the PC keyboard only has them up to F12. In this case there must be a mapping. Kermit's default mapping is Alt-F1 → F11, Alt-F2 → F12, ... Alt-F10 → F20.
set key \4397 \KdecFind ; Gray Insert = DEC Find set key \4388 \KdecInsert ; Gray Home = DEC Insert set key \4385 \KdecRemove ; Gray Page Up = DEC Remove set key \4398 \KdecSelect ; Gray Delete = DEC Select set key \4387 \KdecPrev ; Gray End = DEC Prev set key \4386 \KdecPrev ; Gray Page Down = DEC Next
This map assigns the functions "positionally", corresponding to the VT220 keys. Of course you can also assign them any other way you want, e.g. according to the keytop legends. Put these commands in an appropriate place: the Dialer entry's Keyboard page, in the user's K95CUSTOM.INI file, or in the site-wide K95CUSTOM.INI file (see the README FILE for deatils).
PCTERM Ctrl-CAPSLOCK to deactive.
(if your current emulation includes a status line). In any case, you can restore the keyboard to normal with another Ctrl-CapsLock or, in K95G, in the Actions menu.
To defeat this, you can tell Kermit to "do something" automatically every so often after you haven't transmitted anything on the connection for a given amount of time. The commands are:
And for Telnet connections:
If you have a Telnet connection, try one of these; it is preferable to sending characters to the host session, since these Telnet messages are intercepted by the Telnet server and never reach your host session, yet they count as activity on the connection and should defeat any idle monitors between here and there.
Example 1: Suppose a certain Telnet connection has a five-minute idle limit; If you don't transmit anything to the host for five minutes (300 seconds) your session is closed. To defeat this, do:
set terminal idle-timeout 270 ; 4.5 minutes set terminal idle-action telnet-ayt ; Send Telnet "Are You There?"
Example 2: Suppose a certain dialup connection has a 10-minute idle limit; If you don't transmit anything to the host for ten minutes (600 seconds) your session is closed. Since it's not a network connection, you can't send network protocol messages; you have to send an actual character. Pick a character that is least likely to cause anything to happen on the remote end, such as NUL (ASCII 0) or Space (ASCII 32):
set terminal idle-timeout 570 ; 9.5 minutes set terminal idle-action output ; Send NUL
or:
set terminal idle-timeout 570 ; 9.5 minutes set terminal idle-action output " " ; Send Space
If you want these commands to be in effect for all sessions, put them in your K95CUSTOM.INI file. If you want them to be in effect for certain connections only, put them in the text box of the Login Settings page of the Dialer entry for each desired connection, or just type the commands at the K-95> prompt.
Sometimes people want to have certain attributes shown as colors of their choice. K95 supports this for the following attributes: Blink, Protected, Reverse, and Underline. You need two commands for this. First disable normal treatment of the given display attribute with:
Then specify the colors to be used to simulate the attribute:
We don't support color substitution for all attributes (such as Bold, Dim, Italic, Invisible) since that gets into combinatorial problems: what happens when a character has multiple attributes, e.g. Bold, Blinking, Underlined, and Reverse? Plus that fact that color itself can be attribute. Similarly, assigning colors to a combination of attributes is not supported either.
set terminal type scoansi ; What I am set telnet terminal-type ansi ; What I say I am
The same might (or might not) apply to some or all releases of UnixWare and Open Unix 8. It's necessary in any SCO operating system that uses SCO ANSI but does not have a terminal type called "scoansi".
UNFORTUNATELY there are still some complications:
mapchan -n
VTNT is Unicode based. If you are using a Console version of K95, you must select a Unicode-based TrueType font such as Lucida Console.
Also see the section discussing Microsoft Windows Telnet Server and Kermit 95 in http://www.kermit-project.org/telnet.html.
Digital Part number LK-461-A2 from Digital Parts Source 1-800-225-5385, $75.00 USD: a PC-compatible version of the DEC VT 220/320/420/520 keyboard that has 20 function keys and Ctrl left of the 'A'. (Digital Equipment Corporation has since been bought by Compaq Computer Corporation, which was then bought by Hewlett Packard; it is not known if they still sell this part, but a search of the Compaq website in early 2002 for "LK-461" turned up 60 references.)
Most IBM mainframe operating systems support "linemode" sessions, which are similar to hardcopy sessions -- no screen formatting. Unless your IBM mainframe has linemode disabled, you should be able to establish a regular Telnet session to it. You can transfer files between K95 and Kermit-370 over any of these kinds of connections.
In the Console version, you can simply remap all the scrollback keys to execute the \Kignore verb:
set key \4385 \Kignore ; Gray Page Up set key \4386 \Kignore ; Gray Page Down set key \4388 \Kignore ; Gray Home set key \5409 \Kignore ; Ctrl Gray Page Up set key \5410 \Kignore ; Ctrl Gray Page Down
You can do this in the GUI version too, but that doesn't remove the scrollbar. However, it's harder to scroll back by accident with the mouse than it is to hit the wrong key by mistake.
In both the Console and GUI version, you can limit the scrollback capacity with:
set terminal scrollback number-of-lines ; (Terminal screen) set command scrollback number-of-lines ; (Command screen)
However, the minimum number of lines is 256.
<ESC>[2;1H<ESC>[J<ESC>[1;1H<ESC>[K
(replace <ESC> with an actual Esc character). What it does:
These forms of clearing do not enter anything into the scrollback buffer.
Purchase the manuals from the current marketer of the terminal. Manuals are still being sold for all Wyse and DEC VT terminals. Note that (a) DEC sold off its terminal products division years ago, and it has probably changed hands several times since then, and (b) DEC was sold to Compaq, and later Compaq was bought by Hewlett Packard. DEC and Wyse terminal manuals tend to be quite expensive.
For further information, visit Richard Shuford's Video Terminal Information site.
Kermit 95 virtualizes the display. This is how it is capable of functioning as both a console and a GUI application not to mention supporting other operating systems such as OS/2. Any perceptible delays are usually due to thread allocation algorithms within the OS. If you are using K95 on a Windows Server edition, you should be aware that the OS is tuned to favor server, rather than client, applications, e.g. by allocating longer timeslices, and of course it runs an increased number of processes with "service" priority, which can result in some jumpiness between the threads.
Normally K95 refreshes the entire screen every 100 milliseconds, i.e. 10 times per second. This has proven to provide the best overall throughput, which is always a tradeoff between (a) responsiveness to keystrokes, and (b) speed of displaying large amounts of scrolling text. You can change the balance and the frequency with the command:
A smaller interval might produce snappier echoing, but probably at the expense of scrolling speed. SMOOTH forces screen refresh with every incoming character, and so turns the balance to totally favor fast echoing.
In version 1.1.16, K95's echoing strategy was redesigned to give snappier echoing on modem connections, virtually eliminating any delay that can not be attributable to external causes. Echoing of a character from the local modem's command processor now takes less than 0.001 second, compared to about 0.110 second in 1.1.15.
Also, beginning in 1.1.16, screen updates are optimized. This results in noticeable speed improvements on most PCs, but paradoxically, slows down some others. To disable optimization, use:
SET TERMINAL SCREEN-OPTIMIZE OFF
On TCP/IP connections (Telnet, SSH, Rlogin) you might be able to speed up echoing by disabling the "Nagle algorithm" in Windows TCP/IP, which saves up characters for a while before deciding to send them in case any more will be added to the queue, thus allowing more efficient transmission (more characters per TCP packet) but, obviously, slower response to keystrokes. To do this, give the command:
SET TCP NODELAY OFFThis command must be given before the connection is made because it affects how the connection is opened.
So-called "WinPrinters" are presently not supported by Kermit 95. These printers are marketed specifically for use with Microsoft Windows operating systems, and work only with Microsoft Windows. It might seem strange that Kermit 95 does not support them, since Kermit 95 is a native Windows 32-bit application, but "WinPrinters" require the print job to be formatted by the Win32 application. Transparent printing material, however, contains escape sequences or other non-textual data that can not be formatted as text.Ironically, WinPrinters come with a 16-bit driver for use by DOS applications, but since K95 is a 32-bit application, it can't see this driver. Presently, the only way to print on a WinPrinter from Kermit 95 is to:
set printer xxxwhere xxx is a filename, and then to:
run copy /b xxx prn(i.e. run the DOS command to copy the print file in binary mode to the DOS printer). A series of macros can be defined to accomplish this, and can be assigned to hot keys to make printing to Windows printers relatively painless.
Sometimes file transfers -- especially uploads of binary files -- fail using these settings. Such failures can almost always be fixed by restoring full control-character prefixing:
SET PREFIXING ALL
Or in the Dialer, edit the connection's File Transfer page. Change Performance to Custom, and change Control Char Prefixing to Never.
If that doesn't help, then give this command:
CAUTIOUS
If you still have problems, give this command:
ROBUST
(You can choose these on the Dialer's File Transfer page too).
If none of that helps, then consult Chapter 10 of Using C-Kermit, 2nd Edition: "Solving File Transfer Problems". And if that doesn't help, maybe K95's file-transfer partner has a defective Kermit implementation. Kermit 95 offers workarounds for most of the implementation bugs we know about in other products; click HERE and HERE for details.
Passive is Kermit's default mode since it tends to work better with firewalls. This is because the choice of port numbers is controlled inside the server-side firewall, and thus the server and the firewall can be configured by the site's network and system administrators to accommodate each other.
On secure FTP connections, commands and responses are encrypted and therefore cannot be understood by firewalls. Which brings us to the next question...
K-95> set ftp authtype ssl K-95> set ftp debug on K-95> ftp open xyzcorp.com ---> AUTH SSL 234 SSL enabled and waiting for negotiation SSL accepted as authentication type ftp: SSL/TLS connect command error: error:00000000:lib(0):func(0):reason(0) SSL authentication failed K-95>
If you can't log in at all, you have to talk to the firewall administrator. If you can log in but can't transfer data (DIR, GET, PUT, etc), try switching modes (Active/Passive). FTP passive mode should work if the firewall is configured to allow connections to the ports that the FTP server chooses. If not, the problem can be solved only by your network/firewall administrator. Failing that, you'll have to make clear-text FTP connections (if the servers to which you need to make connections allow them), or else a different protocol (such as Kermit, which uses only one connection, not two).
You have to use a method that is supported by the server. Method 3 is currently favored; the other two are "deprecated". Method 1 is not used by Kermit unless you ask for it. Methods 2 and 3 are negotiated automatically, with the first preference going to TLS; i.e. Kermit sends AUTH TLS first and then sends AUTH SSL only if AUTH TLS is refused. If necessary you can force Kermit to send AUTH SSL first (or send only AUTH SSL) with the SET FTP AUTHTYPE command.
For a table of FTPS servers that shows which of the three methods each uses, see:
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
SET FTP AUTHTYPE TLS ; Forces AUTH TLS because AUTH SSL is "deprecated". SET FTP AUTOAUTH OFF ; Disables negotiation of an authentication method.
http://www.ipswitch.com/Products/file-transfer.html
the connection fails. Debugging messages show:
ftp: SSL/TLS connect COMMAND error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
The protocol for this is still in the discussion (Internet Draft) stage. The current draft is here:
http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-11.txt
According to the proposed specification, when negotiating AUTH TLS, the TLSv1 protocol is required. WS_FTP, however, does not seem to support SSLv3 or TLSv1 but only SSLv2.
Experimentation shows that the WS_FTP implementation of AUTH SSL and AUTH TLS is incorrect, or at least undependable, in WS_FTP versions 3.0 to 3.1.4 to 4.0.0. In each case it was possible to establish connections using SSLv3. However, more often then not after the SSLv3 client Hello packet was sent to WS_FTP the server Hello packet was never returned. Eventually the connection timed out and the Kermit client reported an incorrect version number because the connection was dropped. There is nothing that can be done about this problem from within the Kermit client, which follows the specification.
Note that there is no way to tell the client to select between SSLv2, SSLv3, and TLSv1. These are (and must be) negotiated between client and server.
Some Kermit commands have options to write their output to a file. For example, REMOTE commands allow Unix-like redirectors at the end, for example:
remote directory *.jpg > jpglist.txt
The DIRECTORY, GREP, and TYPE commands include /OUPUT: switches that tell them to write their output to the given file, e.g.:
directory /recursive /after:-5days /sort:date /output:recent.txt *.[ch]
K95 also lets you clear and save both command and terminal screens and scrollback into a file with the CLEAR and SAVE commands. To create a file showing the results of one or more commands, do this:
set command more-prompting off clear command scrollback (execute desired commands here) save command scrollback filename
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAIBAQEBAQIBAQECAgICAgQDAgICAgUEBAMEBgUGBgYF BgYGBwkIBgcJBwYGCAsICQoKCgoKBggLDAsKDAkKCgr/2wBDAQICAgICAgUDAwUKBwYHCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgr/wAARCAQNBgADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
So how to view that snapshot that Aunt Hilda sent you? The labor-intensive method is to save the message in a separate file, edit out the base-64 encoded picture, save that to still another file, decode it into its original JPG, GIF, or BMP format into yet another file using the appropriate decoder, and then either put it on your own host-based website and (after setting the permissions appropriately) and view it from your PC browser, or download it to your PC and tell K95 to "run start hilda.jpg" or whatever.
Here's an easier method, but one that's not quite as safe:
kermit -s xxx.eml (Substitute actual file name)
run start xxx.eml (Substitute actual file name)
This starts your Windows e-mail client (e.g. Outlook Express) with the mail message in it so you can see the picture(s). But again: be careful! If the message contained any enclosures other than pictures (such as Visual Basic scripts, Microsoft Word documents, HTML, ActiveX, etc), they could give your PC a virus, as explained in the Safe Computing document. In more recent versions of Windows, particularly those with security patches, the Microsoft mail client might refuse to show you any enclosures that are not pictures.
ssh add local-port 25 email.xyzcorp.com 25
in which email.xyzcorp.com should be replaced by the hostname of your own mail server, and 25 is the Simple Mail Transfer Protocol (SMTP, i.e. mail server) Internet port. This sets up TCP port 25 on your PC to forward to port 25 on the e-mail host through the SSH tunnel.
Now SSH to your login host. In your mail program, set the SMTP server to "localhost". Then as long as you keep the SSH connection open, you can use your mail program in the usual way.
The same trick can be used for any other TCP service that might be blocked from normal access.
If you have a C or C++ or Java application that already includes communications i/o and you just want to add Kermit file transfer protocol to it, you can use Embedded Kermit. If you need more than that, read on.
and on and on. And they desire this functionality to be packaged as a link library for this or that platform, a DLL, an OCX, a VBX, an Active X control, a Delphi component, a Netscape Plugin, a Java object, a Visual FoxPro object, a Windows Service, etc etc etc. The combinations of functionality and interface are many, and there is no way we can satisfy them without warehouses full of programmers, which nobody can afford to pay for.
Consequently we recommend that software makers who wish to embed Kermit functionality in their products (communications, scripting, file transfer, terminal emulation, character-set translation, etc) license and use the programs we already have available. See the next item for an example.
The "API" (Application Program Interface) is the command language. It is more fully expressive, precise, comprehensive, and portable than any other API that could be designed (look at all the commands in C-Kermit or MS-DOS Kermit or Kermit 95; each one is there for a reason). As new releases of the Kermit program come out, your product can be easily updated and will benefit from all the new features, fixes, and speedups automatically.
The recommended method of embedding Kermit in another application is via command-line invocation. The Kermit command line can contain a selection of simple commands, and it can also refer to more complex command files or scripts composed by or for your application. Kermit can be configured to create any kind of log you need, and it can return the status of its operations in various ways that can be used by your application.
When you license Kermit software for embedding in your application, we are happy to work with you to ensure it meets your needs. And if Kermit protocol transfers are important to you, then it should also be important to you to come to the source -- we designed and created the protocol, we continue to improve it, we believe in it, and we stand behind it.
Following this advice allows each party to concentrate on what they are good at, rather than unnecessarily duplicating efforts and "reinventing the wheel". You concentrate on your application; we'll do the communications. We support our software, you support yours, everybody is happy.
Kermit 95 version 2.1.3 (January 2003) includes new "lockdown" features of special interest to those who which to integrate Kermit 95 sessions with their own applications. For details, see the release notes.
k95 update.ksc
The command file can be prefabricated, or it can be created dynamically by your application. If it is not in the current directory, of course you must specify the full path:
k95 d:\scripts\update.ksc
If you want K95 to exit automatically when the script is complete, put EXIT commands in the script wherever you want to return control to your VB program.
To invoke K95 from VB, use:
Shell (commandline, windowstyle)
where commandline is the command with which to invoke Kermit 95, such as "k95 update.ksc", and windowstyle is one of the following:
0 - Hidden 1 - Window has focus and is restored 2 - Window is an icon with focus 3 - Window is maximized with focus 4 - Window is restored, current window keeps focus 6 - Window is an icon, current window keeps focus
The Shell() function returns Kermit 95's task ID.
"C:\Program Files\Kermit 95 2.1\k95g.exe" -l 664
Example:
"C:\Program Files\Kermit 95 2.1\k95g.exe" -j _636
If you want to invoke Kermit to perform only one action, such as receiving a file (as you might do when using Kermit as a file-transfer agent within another application), put the desired action option after the -l or -j argument:
"C:\Program Files\Kermit 95 2.1\k95g.exe" -j _636 -r
In this case you might also want to include other command-line options to inhibit execution of the initialization file (-Y), loading of unneeded DLLs (-#), suppress unwanted messages (-Q), etc. See the Kermit 95 manual or type "help options" at the K-95> prompt for documentation of K95's command-line options.
When you invoke Kermit with an open file or socket handle on the command line, Kermit does NOT close the connection when it exits.
For testing, you can use Kermit 95 to make a connection and then invoke a second copy of itself to use it. Example for serial-port connection:
K-95> set port com1 K-95> set speed 57600 K-95> run start \v(exedir)k95g.exe -l \v(ttyfd)
Kermit's \v(exedir) variable contains the full path of the directory containing the Kermit executable, complete with trailing directory separator. The \v(ttyfd) variable contains the numeric file handle of the open connection.
Example for Telnet connection:
K-95> set host xyzcorp.com K-95> run start \v(exedir)k95g.exe -j _\v(ttyfd)
When the spawned copy of Kermit exits, it does NOT close the connection; thus it should still be open and usable by the original process that spawned Kermit.
"pathname\k95g" -j xyzcorp.com:3000
then Kermit does not send Telnet negotiations. Obviously the target host must have a service listening on that port. Alternatively, you can use a short script such as the following:
set login userid ; Don't try to send authentication info set network directory ; Skip host lookups set network type tcp/ip ; It's a TCP/IP connection if fail end 1 TCP/IP Failed ; Make sure Kermit supports this set exit on-disconnect on ; (or OFF as desired) set host \%1:\%2 /raw-socket ; "Open" the connection as a raw socket if success connect ; (or whatever else you wish Kermit to do)
Suppose this script is called "rawsocket.ksc", it's in the PATH, and Kermit 95 is the registered application for ".ksc" files. Then your application can invoke it like this:
rawsocket.ksc = hostname port
Suppose you wanted to make K95, executing this script, the Telnet application for your browser, to force raw-socket connections for all "telnet://" URLs. In that case you would define the Telnet invocation string as:
"pathname\k95g.exe" rawsocket.ksc = hostname port
where pathname is the location of the Kermit 95 executable and hostname and port are in whatever notation required by your browser to indicate parameter substitution. This assumes your browser allows you to extract the hostname and protocol from the "telnet://" URL (as opposed to, say, passing the entire URL, which would force Kermit to use Telnet protocol).
If you wish to pass the socket handle of an already-open raw socket connection to Kermit, you can't do it as described in the previous section because at present there is no command-line option to specify the protocol (or lack of one), nor can you include a port number with a socket handle; thus when given a -j or -J command-line option with a socket handle number, Kermit assumes a Telnet connection and sends Telnet negotiations. To force Kermit to treat the connection as a raw (no-protocol) socket, you can create a short script, such as this:
set network directory "" ; Don't look anything up set telnet wait off ; Don't wait for Telnet negotiations set exit hangup off ; Don't close the socket upon exit set host _\%1 7777 /raw ; "Open" the already-open socket
and then instead of invoking Kermit 95 directly with the -j or -J command line option, you would invoke the script like this:
"pathname\k95g.exe" openrawsocket.ksc = socketnumber
replacing socketnumber by the numeric socket number. This replaces the \%1 formal parameter in the script so, for example, if you invoke the script as follows:
"C:\Program Files\Kermit 95 2.1\k95g.exe" rawsocket.ksc = 644
the SET HOST command becomes:
set host _644 7777 /raw ; "Open" the already-open socket
When any SET HOST class command is given a numeric argument preceded by an underscore (or a dollar sign), this indicates an already-open socket. The port number (7777 in this example) must be given but is ignored. The SET EXIT HANGUP command in the script prevents Kermit from closing the connection when it exits, so the invoking process will still have it available.
k95.exe -l 1234
where "1234" is the numeric file handle of the open serial port. Of course you can add any other desired command-line options; for example, the name of a script file to be executed:
k95.exe -l 1234 -C "take makethecall"
This tells Kermit the port is already open gives it the handle to use, and then has it execute the file called "makethecall", which contains Kermit commands (e.g. to make a modem call). This file should include the command SET EXIT HANGUP OFF, to prevent Kermit from hanging up when exiting. Here is the C++ code illustrating how to do this:
char buf[64];
SECURITY_ATTRIBUTES sec;
STARTUPINFO si;
PROCESS_INFORMATION StartKermitProcessInfo;
sec.nLength = sizeof(sec); // Set security parameters
sec.lpSecurityDescriptor = NULL;
sec.bInheritHandle = TRUE; // Let new process inherit handle
memset(&si, 0, sizeof(STARTUPINFO)); // Set desired startup info
si.cb = sizeof(STARTUPINFO);
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = ShowCmd;
HANDLE // Open real serial port
hComm = CreateFile( "COM1",
GENERIC_READ|GENERIC_WRITE,
0, // NOT exclusive access
&sec, // security attributes
OPEN_EXISTING, // device must exist
FILE_FLAG_OVERLAPPED, // use overlapped i/o
NULL // hTemplate
);
if (hFile == INVALID_HANDLE_VALUE) {
// handle error...
}
sprintf(buf,"k95.exe -l %ul",hComm); // K95 invocation command line
if (CreateProcess( NULL, // Start K95
buf,
NULL,
NULL,
TRUE,
CREATE_NEW_CONSOLE|CREATE_NEW_PROCESS_GROUP,
NULL,
NULL,
&si,
&StartKermitProcessInfo
) {
// handle error...
} else {
CloseHandle(StartKermitProcessInfo.hProcess);
CloseHandle(StartKermitProcessInfo.hThread);
}
Replace "k95.exe" with "k95g.exe" if you prefer the GUI version, and include the full path if necessary.
For further information, see the Microsoft Windows API Reference.
If you need to use the Console version (K95.EXE) for some reason, you have to work around problems with how javaw.exe starts Console applications, you must begin with a Console window, run java.exe in it, and then start K95.EXE from there.
If you want Kermit to use an existing network connection (one that was made from your Java application), the socket must be inherited from the parent process. Here's an example that starts K95G to have it receive a file (-r) on an open socket connection. In this case, it was found that the "$" prefix to the socket handle was required to prevent Windows from "aborting" the socket before control was returned to the Java process:
private void RunKermit_ReceiveFile(int socketHandle) {
Process p = null;
try {
p = Runtime.getRuntime().exec(
"C:\\Program Files\\Kermit 95 2.1\\k95g.exe -j $" +
Integer.toString(socketHandle) +
" -r"
);
} catch (IOException e) {
e.printStackTrace();
}
try {
p.waitFor();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
Here's the code snippet from the same application that returns the socket handle by using java.lang.reflect to extract the protected socket file descriptor, so it can be passed to Kermit 95:
private int getSocketHandle(Socket clientSocket) throws Exception {
// Get the SocketImpl impl object from the client socket
Field socketImplField = getFieldFromClass("java.net.Socket","impl");
socketImplField.setAccessible(true);
SocketImpl impl = (SocketImpl)socketImplField.get(clientSocket);
// Get the FileDescriptor fd object from the impl object
Field fileDescriptorField = getFieldFromClass("java.net.SocketImpl","fd");
fileDescriptorField.setAccessible(true);
FileDescriptor fd = (FileDescriptor)fileDescriptorField.get(impl);
// Get the int fd from the fd (FileDescriptor) object
Field socketHandleField = getFieldFromClass("java.io.FileDescriptor","fd");
socketHandleField.setAccessible(true);
int socketHandle = socketHandleField.getInt(fd);
return socketHandle;
}
private Field getFieldFromClass(String className, String fieldName)
throws Exception {
Class tempClass = Class.forName(className);
Field[] classFields = tempClass.getDeclaredFields();
for (int i = 0; i<fields.length; i++)
{
if (fields[i].getName().equals(fieldName))
return fields[i];
}
return null;
}
Thanks to Marcus Mullins for the Java code samples.
If your application contains all the necessary communications functions (connection establishment, i/o, etc) and you prefer to integrate Kermit file-transfer protocol code directly into your Java application, you can use the Java version of E-Kermit; contact us for details.
[ Top ]