mrharrison@orchid.waterloo.edu (Mike Harrison) (09/14/89)
I'm trying to use Kermit Version 4E(067) running on Unix 4.2BSD to send and receive files to and from Proterm on my IIgs. When I try to send a file, Proterm comes back with "Ack failure" and I get "Data Timeout" when trying to receive a file from Unix. Both times I specify the "kermit" file transfer protocol to Proterm. What am I doing wrong? Mike
SEWALL@UCONNVM.BITNET (Murph Sewall) (09/25/89)
On Thu, 14 Sep 89 15:35:50 GMT you said: >I'm trying to use Kermit Version 4E(067) running on Unix 4.2BSD to send >and receive files to and from Proterm on my IIgs. When I try to send a file, >Proterm comes back with "Ack failure" and I get "Data Timeout" when trying to >receive a file from Unix. Both times I specify the "kermit" file transfer >protocol to Proterm. What am I doing wrong? Using ProTeerm instead of Kermit-65 doesn't make life easy (ProTerm's Kermit implementation has a poor reputation), but... Are both ends set to to the same file-type (usually 'text')? Are both ends set to the same byte-size? Do both ends have eight-bit-quoting set the same (usually off)? Do both ends have parity set the same (some hosts don't care if you haven't set the correct parity, but Kermit DOES care)? Any of the above can cause Kermit file-transfer to fail. Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@cunyvm.cuny.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] The opposite of artificial intelligence is genuine stupidity! -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
greyelf@WPI.WPI.EDU (Michael J Pender) (09/25/89)
Proterm before version 2.1 has chronic problems using Kermit. If you're using version 2.1 or later just be sure that both versions are expecting either batch or file transfer, depending on what you're doing.
dougs@pro-tcc.UUCP (Doug Stevenson) (09/27/89)
Network Comment: to #354 by SEWALL%UCONNVM.BITNET@cunyvm.cuny.edu I have fooled with Kermit x-fers and have found some VERY intersting things about it: When x-fered from an Apple to a Mac, the mac registers MORE blocks coming through than the Apple registers going through. It does NOT affect the x-fer in any way that I have found as the text file was sent error free. I thinkI remember hearing that Kermit was made specifically for different computer x-fers, but my sources may be wrong. All I know is that it seems slower that a normal x-fer on the Apple side and FASTER on the Mac side. Maybe I could get an IBM to fool with it...
SEWALL@UCONNVM.BITNET (Murph Sewall) (09/28/89)
On Tue, 26 Sep 89 22:39:28 EST you said: >When x-fered from an Apple to a Mac, the mac registers MORE blocks coming >through than the Apple registers going through. It does NOT affect the x-fer >in any way that I have found as the text file was sent error free. If you're using Kermit-65 on the Apple, it counts blocks in HEX. I'm not sure about the Mac side, but it wouldn't be the first Kermit implementation I've seen that counts blocks in decimal. >I thinkI remember hearing that Kermit was made specifically for different >computer x-fers, but my sources may be wrong. All I know is that it seems >slower that a normal x-fer on the Apple side and FASTER on the Mac side. The original problem was: most mainframes use either mark or even parity, leaving only 7 bits for data (conceived of LONG before anyone thought that commputers would 'talk' to anything other than dumb-terminals and other ASCII devices), but users need to transfer 8-bit files. Kermit was designed to be able to encode 8-bit data into 7-bit characters AND transfer over packet oriented networks. The speed HAS to be the same on both ends (any differences are illusions), but the Kermit protocol has all sorts of optional features (which have to be implemented on both ends to work, of course) - 3 levels of CRC error checks, long packets (up to 1K?), 'sliding windows', etc. So, depending on what's transfering to what with what features active, the wall clock time for a transfer can vary somewhat :-) Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@cunyvm.cuny.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] The opposite of artificial intelligence is genuine stupidity! -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
sschneider@pro-exchange.cts.com (The RainForest BBS) (09/30/89)
Comment to message from: SEWALL%UCONNVM.BITNET@cunyvm.cuny.edu (Murph Sewall) Ooops... not Glen... Gary! /steve and he offered to send pictures of the girls on Tahita too!!! ----------------------------------------------------------------------------- | UUCP: crash!pro-exchange!sschneider COMPU$ERVE : 75166,2544 | | ARPA: crash!pro-exchange!sschneider@nosc.mil GENIE : sschneider | | INET: sschneider@pro-exchange.cts.com * My son is a Georgia Tech freshman | | I work for Xerox Corporation for decent bucks but dream of Palto Alto RC | | The RainForest @ 305-434-4927 / PO Box 841422, Pembroke Pines, Fl, 33084 | -----------------------------------------------------------------------------
pyrros@udel.EDU (Chris Pyrros) (10/12/89)
In article <218@orchid.waterloo.edu> mrharrison@orchid.waterloo.edu (Mike Harrison) writes: >I'm trying to use Kermit Version 4E(067) running on Unix 4.2BSD to send >and receive files to and from Proterm on my IIgs. When I try to send a file, >Proterm comes back with "Ack failure" and I get "Data Timeout" when trying to >receive a file from Unix. Both times I specify the "kermit" file transfer >protocol to Proterm. What am I doing wrong? > >Mike I had the same problem. Be sure to give 8N1 as the format to proterm. Also, your version of Kermit should be dated Jan 88 or later. If it still doesn't work, try a different machine; switching can create problems.