From: IN%"fdc@watsun.cc.columbia.edu" "Frank da Cruz" 13-JUL-1990 21:05:38.89 To: Jonathan_Welch CC: Subj: RE: Fresh copy of VMS Kermit needed Hi Jonathan. I'm back from vacation. I couldn't retrieve the VMS Kermit files before I left because the net was messed up, and I assume that by now they are gone. But it seems pretty certain that the hackers did not tamper with the Kermit files anyway. All the other ones we checked were clean. Btw, here is the current VMS Kermit beware file. Feel free to remove all the material that no longer applies: BEWARE FILE FOR VAX/VMS KERMIT-32 VERSION 3.3.126, JULY 1990 The VMSMIT.HEX file was produced using VMSHEX on an .EXE file that was built from the .OBJ files linked together on a VMS 4.5 system. Use VMSDEH to convert the VMSMIT.HEX file back into an executable .EXE file. (VMS programs check the version numbers of the run time libraries. They will allow programs to migrate to newer versions of the library, but not the other way around. There is a dispatch table in the library, which can change between releases of VMS. The version checks are done against the VMS library, instead of the dispatch table version number which doesn't exist.) Known problems with VMS Kermit 3.3.111: o Commands are upcased so that LIB$TPARSE will scan the command correctly. This causes problems when attempting to set the prompt and sending server commands to a UNIX based Kermit. o Kermit-32 will quote multiple characters with "~" in a file name even if the REPEAT_QUOTE character is set to space. o Kermit-32 can hang on a virtual terminal due to XON-XOFF processing between the VAX and a remote system. o Kermit-32 can't receive text files that have very long "lines", e.g. continuous streams of ASCII characters with no line terminators. The maximum length for a text record is 4096 characters. The error message is "Record too long for internal buffer". In most cases, you can get around this restriction using "set file type binary". Miscellaneous messages, suggestions, and hints follow... ------------------------------ Date: Mon, 22 Dec 86 09:48 EST From: (brian nelson) Subject: VMS Kermit Settings To: sy.fdc@cu20b DMF/DHU/DHV terminal settings and PACX systems: Regarding VMS terminal settings, here are two examples from my 785. The first, TXA1, is on a DMF32 connecting into a Gandalf PACX 1000 system via an AMTB3. This line is used all the time to connect into both Vadic VA4224 modems for calling off campus, and also to connect to the other systems hooked into the Gandalf system. Kermit-32> CON TXA1 will get the Gandalf to recognize the DMF line as a terminal once it seems a transition in DTR (which can be done by exiting VMS kermit and going back into Kermit). Terminal: _TXA1: Device_Type: Unknown Owner: No Owner Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape No Hostsync TTsync Lowercase No Tab Wrap Scope Remote Eightbit Broadcast No Readsync No Form Fulldup Modem No Local_echo Autobaud Hangup No Brdcstmbx DMA Altypeahd Set_speed Line Editing Overstrike editing No Fallback Dialup No Secure server Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad No ANSI_CRT No Regis No Block_mode No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 This is just an example of the settings for user lines, all of which connect via the PACX 1000. Note the DISCONNECT setting, this is highly desirable for security. If the user hangs up, or otherwise disconnects without logging out, the drop of CD will have VMS disconnect the process and eventually delete the process (default is 900 seconds). Physical terminal: _TXF0: Username: CSDJR [(2(] Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape No Hostsync TTsync Lowercase Tab Wrap Scope Remote Eightbit Broadcast No Readsync No Form Fulldup Modem No Local_echo Autobaud Hangup No Brdcstmbx DMA Altypeahd Set_speed Line Editing Overstrike editing No Fallback Dialup No Secure server Disconnect No Pasthru No Syspassword No SIXEL Graphics Soft Characters Printer port Application keypad ANSI_CRT No Regis No Block_mode Advanced_video Edit_mode DEC_CRT DEC_CRT2 Brian ------------------------------ Date: Tue 9 Jun 87 10:32:37-EDT From: Frank da Cruz Subject: Bad bug in VMS Kermit To: rmcqueen@SITVXA.CCNET Bob, I got a call today from one of our supercomputer users, who is trying to transfer binary files between a VMS system (that front ends for a Cray in Pittsburgh) and a Mac (or a PC, or a PDP-11, all with the same results). The problem is that portions of the data are incorrect after transfer. This appears to be closely related to the following two bug reports (more on this below): ------------------------------ Date: Tue, 24 Feb 87 16:30:32 CST From: "Jeff Balvanz" Subject: Problems With VAX/VMS Kermit Keywords: VAX/VMS Kermit We have been having some problems with VAX/VMS Kermit here at ISU and I'm wondering if anyone can offer some advice. Here are some of the problems: 1. When uploading to VAX from MS-Kermit 2.29 (Zenith Z-158) using an eight-bit communications line, SET PARITY NONE on both ends usually results in 16 retries and no packets sent. Setting parity to EVEN on both ends causes a file to be uploaded, but often with repeated characters in the file (as in "This is a miiiiiiiiiiiiiiiiistake.") making the upload unusable. However, setting the parity back to NONE on both sides after an unsuccessful upload at EVEN sometimes results in a successful transfer. It drives us nuts because sometimes no parity works just fine, and some files will transfer successfully with EVEN parity. The files that give repeating characters are normal text files, and it is (to me, anyway) impossible to determine any difference between the files that work and those that don't. However, a file that doesn't work once usually will repeat the behavior. ------------------------------ Date: Tue, 21 Apr 87 06:48:55 PDT From: ROME%ORN.MFENET@nmfecc.arpa Subject: Kermit 32 3.3.077 bug I wrote a letter to you describing this bug. We just got a newer version of VMS Kermit and it seems to have the same bug. When sending a binary file from the VAX without using 8th bit quoting, characters 163 and 254 get prefixed with the '#' control character quote. Since the checksum is correct, I am reasonably sure that this analysis of the situation is correct. Is this a known problem? can you reproduce it? Jim Rome, Oak Ridge National Lab (615) 574-1306 ------------------------------ (Frank again) The guy who called said he discovered 3 problems: 1. If his file contains 8 null bytes in a row, only seven of them come through. 2. The sequence 3131 (hex) is received as 0C (hex). 3. The sequence 3030 (hex) is received as 0A0A (hex). Other repeated sequences, however, seem to be transferred correctly. There seems to be something bad lurking in Kermit-32's packet encoding, which is triggered whenever you have binary files and repeat counts. This is pretty serious. Is there any chance you can take a look? If there's anything Kermit should be able to do right, it's transfer files! I'll be calling the super- computer center to verify that they're not running some ancient version of VMS Kermit, but from the messages above, it appears that the problem persists even in recent versions. Thanks! - Frank ------------------------------ Date: 18 Sep 87 8:38 -0600 From: Grant Delaney Subject: Kermit 32 ESCAPE and VT330 terminal A note of caution the kermit-32 escape sequence is also the terminal reset and self test sequence for the NEW VT330 terminal. The escape sequence should therefore be changed before a connect if you want to get out again. Grant ------------------------------ Date: Tue, 5 Apr 88 15:28 EDT From: CARTER%MITBATES.BITNET@CUVMA.COLUMBIA.EDU Subject: Re: VAX/VMS Kermit "SET LINE" command Mike Rego asks: >When trying to use the VAX/VMS "set line" command on KERMIT, I encounter a >"no privilege for attempted operation". Does anybody know what VAX/VMS >category privilege (e.g. netmbx,share) I must allow a user to enable the >terminal line to be accessible to the user's processes? READALL is not a privilege that you want to give out casually, as it allows a user to read *any* file on the system regardless of access protections. What we do here is to set the protection on the particular device such that the world has read access. This allows a user with no special privileges to connect to the device. The command is: $ SET PROTECTION=(W:R) ddcu:/DEVICE where ddcu: is the device you want users to have access to. I do not know of any major security problems this creates. Tony Carter MIT Bates Linac CARTER@MITBATES.BITNET [Ed. - We received many replies similar to this one. Among them was the suggestion that the above technique might make it possible for one user to spy on another, with the workaround being something like: $ SET PROTECTION=(W:RWLP)/DEVICE/OWNER=[1,4] TXA0: There was also the idea of using access control lists for the dialout devices: $ SET ACL/OBJECT=DEVICE/ACL=(IDENTIFIER=INTERACTIVE,OPTIONS=NONE,- ACCESS=READ+WRITE) TXA10: This technique also allows you to grant access to only certain authorized users. In no case should users need to be given special privileges to assign an external TTY line.] ------------------------------ From: boulder!aspen.ASPEN!pvi!SYJMK@boulder.colorado.edu Date: Wed, 27 Sep 89 15:34:01 MST Subject: KERMIT-CMS XOFF Problems When I started to write this note I had a problem I needed to have solved and wanted to tell others what options allowed us to get Kermit functioning between a VAX system and a VM system. I no longer have the problem, but I'd like to help others avoid the problems I had. I hope you'll find this useful enough to put in the BEWARE file, and many thanks for your help when we were struggling with C-Kermit. Since we gained so much understanding by getting Kermit-32 running, I decided to try again with C-Kermit. No luck--it looks like C-Kermit doesn't see communications from Kermit-CMS. It would be nice if you would forward this note to whoever is responsible for the code that does the actual request to CP to send a record to the Kermit on the other machine and see if the XOFF that causes our problem described below can be eliminated or made optional. Regards, Mike Krieger uucp address: boulder!pvi!syjmk internet: boulder!syjmk@pvi.com ---------------------------------------------------------------------- This note documents the problems I had getting Kermit-32 on our VAX system to function correctly with Kermit-CMS on our IBM VM system. Our two Kermits communicate normally after significant trial and error efforts necessitated by ignorance, confusion of terms, and multiple sets of specifiable parameters. INSTALLATION AND TESTING OF KERMIT Three new versions of Kermit were installed and tested, C-Kermit 4E(072) and Kermit-32 Version 3.3.117 for the VAX and Kermit-CMS Version 4.0 for the IBM system. Installation was uneventful, but testing took a long time. C-Kermit was abandoned after encountering a problem we could not resolve even with Frank da Cruz' help. Problem: When we did a CONNECT to Kermit-CMS the logon message from CP was pure gibberish. Solution: Issue a SET TERMINAL/TYPE_AHEAD TXE2 in the command file (IBM.COM) before invoking C-Kermit. The message was apparently coming from Kermit-CMS into the buffer for TXE2 faster than VMS moved the characters to the output buffer for the physical terminal. Problem: When Kermit-CMS has been put into SERVER mode, a request sent from C-Kermit to GET fn ft times out. Solution: None--we had to abandon C-Kermit at the suggestion of da Cruz. Since Kermit-CMS responds to the BYE command from C-Kermit, and since Kermit-CMS successfully sends data records to Kermit-32, we're quite sure C-Kermit is not receiving data and/or messages properly. Kermit-32/Kermit-CMS tested our patience, but in the end we triumphed. Problem: We can successfully log on to VM after a CONNECT command is issued to Kermit-32, but the terminal locks up after the Kermit-CMS> prompt is displayed on it. Solution: The problem is caused by an XOFF being sent by CP at the beginning of the message that contains the prompt. Since one of the physical terminal SETUP options is to not allow any input on the terminal once an XOFF is received until an XON is received, and since neither CP nor Kermit-CMS sends the XON, we must either change the SETUP option on the terminal hardware or cause Kermit-CMS to send an XON. Since the power-on default for the terminal is to honor the XOFF, we prefer to have an XON sent by Kermit-CMS. This is accomplished by putting in the SYSTEM KERMINI file a SET PROMPT command that contains a hex 11 (XON) as part of the prompt. I tried the CP TERMINAL CNTL USR command with no visible difference in the operation. Unfortunately I didn't have a line monitor available to see precisely what WAS sent. Problem: We can't escape back to Kermit-32 after issuing a SERVER command to Kermit-CMS. Solution: Put in SYSTEM KERMINI file a SET HANDSHAKE 17 command. This causes Kermit-CMS to send an XON after each message or data record sent to Kermit-32, but NOT after the prompt which we had to fix in the problem above. True to its word in the message it displays during initialization when you bring up Kermit-CMS, the XON is not necessary for file transfer. However, the terminal XOFF problem above affects any message displayed on the terminal and, fortunately, SET HANDSHAKE 17 does cause Kermit-CMS to append an XON to the message saying that it has just gone into the SERVER mode. It seems like it really ought to do so with the prompt, but it doesn't. Problem: Under Kermit-32 the command SET IBM_MODE ON results in three commands being issued: SET PARITY MARK SET LOCAL_ECHO ON SET HANDSHAKE 21 ....which means SET HANDSHAKE XON The first two must be done to make Kermit-32 and Kermit-CMS communicate properly in our environment, but SET HANDSHAKE 21 seems to cause transmissions to take longer. Solution: We will not use SET IBM_MODE ON. Either our users will be instructed to issue the SET PARITY and SET LOCAL_ECHO commands, or we will find some way of automatically setting these. Since Kermit-32 is used for transmissions between other systems in addition to VM, we cannot put these directly into the Kermit initialization file. Perhaps some sort of 'logical' can be established for the VMSKERMIT.INI file. Otherwise we can build a TAKE file so the user's setup commands will be reduced to just one line. If we set ibm_mode on, the resulting set handshake 21 seems to cause transmissions to take as much as three times as long as when we do a set handshake none. At one time I had a line monitor connected to the line between the VAX and the IBM 3705 and saw approximately 5 seconds elapse after Kermit-CMS sent a record to the VAX before Kermit-32 would respond with an ACK--for each record sent. When we set handshake none on Kermit-32 (this was the ONLY change) the 5 second wait went away. I don't know why. Anyway, we will not set ibm_mode on for our use. We run successfully with the following options changed from their defaults: In the Kermit-CMS initialization file (SYSTEM KERMIT). SET CONTROLLER TTY SET PARITY MARK SET HANDSHAKE 17 SET PROMPT Kermit-CMS> " (where " represents hex 11) The resulting Kermit-CMS options are as follows: Kermit-CMS Version 4.0 (88/9/29) Tabs-expand is off Eof is off Debug is off Block-check is 1 8-bit-quote is & Prompt is Kermit-CMS> " Line is Controller is tty Handshake is 0 Parity is mark Warning is off Attributes is on Syscmd is off Ttable is off Delay is 10 Append is off Incomplete is discard Test is off Destination is A Search-all is off FILE Type is text Longline is truncate Lrecl is 80 Recfm is V MARGIN Left is 0 Right is 0 FOREIGN Prefix is Suffix is RETRY Initial is 16 Packets is 5 TAKE Echo is off Error-action is continue RECEIVE End-of-line is 13 Packet-size is 94 Pad-char is 0 Padding is 0 Quote is # Start-of-packet is 1 Timeout is 5 SEND End-of-line is 13 Packet-size is 80 Pad-char is 0 Padding is 0 Quote is # Start-of-packet is 1 Timeout is 0 In the Kermit-32 initialization file (VMSKERMIT.INI). or in some TAKE file. SET PARITY MARK SET LOCAL_ECHO ON The resulting Kermit-32 options are as follows: Kermit-32 Version 3.3.117 Block check type One character checksum Debugging OFF Delay 5 (sec) Server sends NAKs every 75 seconds while waiting for a command Escape character 035 (octal) File type ASCII File naming Normal form Handshaking character None Incomplete file disposition Discard Line used _TXE2: Local echo ON Parity type Mark Retry maximums Initial connection 5 (dec) Sending a packet 16 (dec) Send parameters Packet length 80 (dec) Padding length 0 (dec) Padding character 000 (octal) Time out 15 (sec) End of line character 015 (octal) Quoting character 043 (octal) Start of packet 001 (octal) Receive parameters Packet length 80 (dec) Padding length 0 (dec) Padding character 000 (octal) Time out 15 (sec) End of line character 015 (octal) Quoting character 043 (octal) 8-bit quoting character 046 (octal) Start of packet 001 (octal) Transmit parameters Delay 0.0 (sec) Echo OFF Repeat quoting character 176 (octal) Default terminal for transfers is: _TXE2: In the command file (IBM.COM) from which we invoke Kermit-32 we set some terminal options for TXE2, the port controlling the line between the VAX system and the IBM system. $ set terminal/speed:2400 txe2 $ set terminal/NoTTsync txe2 (not sure this is necessary) $ set terminal/NoWrap txe2 The resulting terminal options for TXE2 are: Terminal: _TXE2: Device_Type: VT100 Owner: SYJMK Input: 2400 LFfill: 0 Width: 80 Parity: None Output: 2400 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo No Typeahead No Escape No Hostsync No TTsync Lowercase Tab No Wrap Scope No Remote No Eightbit No Broadcast No Readsync No Form Fulldup Modem No Local_echo No Autobaud No Hangup No Brdcstmbx DMA No Altypeahd Set_speed Line Editing Overstrike editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad ANSI_CRT No Regis No Block_mode Advanced_video No Edit_mode DEC_CRT No DEC_CRT2 No DEC_CRT3 It was not necessary to change any of the VM system CP terminal options for Kermit-CMS, or any of the VMS system terminal options for the port controlling the physical terminal used for Kermit-32, or any of the physical terminal setup parameters. The CP terminal options are set as follows: LINEND # , LINEDEL X'AD' , CHARDEL @ , ESCAPE " , TABCHAR ON LINESIZE 072, ATTN ON , APL OFF, TEXT OFF, MODE VM, HILIGHT OFF CONMODE 3215, BREAKIN IMMED , BRKKEY PA1 , SCRNSAVE OFF TYPE TTY , PROMPT TTY, SCROLL CONT, CNTL SYS, ASCIITBL VM1 The terminal options for the login terminal to VMS are set as follows: Terminal: _VTA379: Device_Type: VT100 Owner: SYJMK Physical terminal: _LTA239: LAT Server/Port: DONALD/PORT_2 Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape No Hostsync TTsync Lowercase Tab Wrap Scope No Remote No Eightbit Broadcast No Readsync No Form Fulldup No Modem No Local_echo No Autobaud Hangup No Brdcstmbx No DMA No Altypeahd Set_speed Line Editing Overstrike editing No Fallback No Dialup No Secure server Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad ANSI_CRT No Regis No Block_mode Advanced_video No Edit_mode DEC_CRT No DEC_CRT2 No DEC_CRT3 The relevant 3705 gen parameters for line 21 (the address on the IBM system for the line between the 3705 and the VAX system) are: *********************************************************************** * DEFINE GLOBAL PARAMETERS * *********************************************************************** * EP3705 BUILD CRCLRC=NO, X HICHAN=2F, X LOADLIB=EP3705, X LOCHAN=20, X JOBCARD=YES, X OBJLIB=EP3705, X CA=TYPE4, X DYNADMP=(YES,NSC), X LINETRC=YES, X MODEL=3705-2, X NEWNAME=EP3705, X TEST=YES, X TYPGEN=EP, X TYPSYS=OS * *********************************************************************** * DEFINE CONFIGURATION PARAMETERS *********************************************************************** * CSB SPEED=(134,1200,2400), X WRAPLN=025, X MOD=0, X TYPE=TYPE2 * * *********************************************************************** * DEFINE GROUP 1 PARAMETERS - ASYNC INHOUSE LINES *********************************************************************** * * GROUP1 GROUP CHAREC=(NO,B1), X DELAY=NO, X LNCTL=SS, X DIAL=NO, X REPLYTO=0.0, X TEXTTO=0.0 * * 21: ASYNC TO VAIL LINE21 LINE ADDRESS=(021,21), X SPEED=2400, X CLOCKNG=INT, X DUPLEX=FULL, X FEATURE=(NOLRC,IMEND), X TERM=TWX The relevant DMKRIO parameters for the 3705 line above are: DMKRIO CSECT *********************************************************************** * C H A N N E L Z E R O * *********************************************************************** RDEVICE ADDRESS=009,DEVTYPE=3705,MODEL=E8,ADAPTER=TYPE4, X CPTYPE=EP,CPNAME=EP3705 RDEVICE ADDRESS=(020,7),DEVTYPE=3705,ADAPTER=TELE2,BASEADD=009 *********************************************************************** * C O N T R O L U N I T S * *********************************************************************** RCTLUNIT ADDRESS=008,CUTYPE=3705 RCTLUNIT ADDRESS=020,CUTYPE=3705,FEATURE=16-DEVICE *********************************************************************** * C H A N N E L S * *********************************************************************** RCHANNEL ADDRESS=0,CHTYPE=MULTIPLEXOR Since the power on defaults for the ASCII terminals can be used when running Kermit, the physical terminal setup options will not be shown. ------------------------------ Date: Fri Jul 13 19:13:27 1990 From: Christine M. Gianone Subject: VMS Kermit-32 Hint Several people have complained that Kermit-32 has been sending files incorrectly when the file type is set to binary. This can happen when the VMS file has a carriage control attribute; for example, VMS Lotus files are created this way. The recent release of Kermit-32 has a new command SET FILE TYPE BLOCK which seems to get around this difficulty.