HELP! Using zmodem across a telnet session.

HELP! Using zmodem across a telnet session.

Post by John H. Chauv » Mon, 03 Jul 1995 04:00:00



I am currently experiencing a persistent problem transferring
files across a telnet connection using zmodem and would like
some assistance in solve this problem.

Here is a description of my data path:

I dial into a SUN sparc (sun-sunos4.1.3_U1) UNIX workstation from
a Macintosh IIci (System 7.5.1) using White Knight
Telecommunication program (v12.06) and a US Robotics Courier HST
dual standard with V.32bis and ASL modem. I connect to the SUN
with 14400/ARQ/V32/LAPM/V42BIS. I then telnet from the SUN to a
Silicon Graphics Crimson Elan UNIX workstation (IRIX 5.3) using
the following syntax:

               telnet [IP address]

rlogin has been diabled on the SUN for security reasons and is
not available.

I am able to send and receive files on the SUN using zmodem. I am
also able to receive files from the SGI using zmodem. BUT I
cannot send files to the SGI from my Macintosh using zmodem. All
transfer are done in binary mode. It appears that zmodem
basically just times out.

This same problem also occurs if I telnet into another SUN sparc
workstation (instead of the SGI). I can receive files from the
SUN but am unable to send files.

The fact that I can receive files from my SGI using zmodem would
imply that I should be able to send files. It appears that
telnet is somehow preventing the transfer. Any idea why? Is the
problem on the SUN side or SGI side?

Do I need to use the stty command to adjust my terminal settings
on the SUN/SGI side? What should I change?

On the SUN stty shows:
           speed 38400 baud; evenp -inpck imaxbel -tabs iexten crt

On the SGI stty shows:
           speed 9600 baud; -parity hupcl clocal line = 1;
           brkint -inpck icrnl onlcr tab3
           echo echoe echok e*

I have tried changing these settings on both the SUN and SGI
without any success.

It has been suggested that my data path might not be 8-bit clean. If
this is true, why am I able to transfer data from my SGI to the Mac?
Or send and receive to the SUN? How would I check this? Is there a
program which can check the data path?

By the way, I did try kermit (C-Kermit 5A(190)) and it works fine
(no surprise). But I have been unable to boost the transfer rate
to an acceptable level despite using every combination of window
count and packet size. I have read Frank da Cruz's books and
reviewed past issues of Kermit News. He might be able to
outperform zmodem but I have not been so lucky. I did use kermit
in 8-bit mode which would seem to imply that I do indeed have a
8-bit clean data path.

I really need to solve this problem and any help would be greatly
appreciated. See P.S. for rz debug information.

Thanks,

John Chauvin
Northrop Grumman Corporation
Pico Rivera, California

P.S.

The following messages are generated by rz when executed on the
SGI with the -vvv option.

-----------------------------
argv[0]=rz Progname=rz
rz 3.00 4-19-89 for SYS III/V

mode:1
rz ready. To begin transfer, type "sz file ..." to your modem program

zshhdr: f 4 ZRINIT 0
Sendline: 2a
Sendline: 2a
Sendline: 18
Sendline: 42
Sendline: 30
Sendline: 31
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 31
Sendline: 32
Sendline: 66
Sendline: 34
Sendline: 63
Sendline: 65
Sendline: 64
Sendline: d
Sendline: 8a
Sendline: 11
Calling read: alarm=10  Readnum=133 Read returned 2 bytes
1b 7a Calling read: alarm=10  Readnum=133 Read returned 21 bytes
2a 2a 18 42 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0d 0a zgethdr: B 4 ZRQINIT
 42
zshhdr: f 4 ZRINIT 18
Sendline: 2a
Sendline: 2a
Sendline: 18
Sendline: 42
Sendline: 30
Sendline: 31
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 31
Sendline: 32
Sendline: 66
Sendline: 34
Sendline: 63
Sendline: 65
Sendline: 64
Sendline: d
Sendline: 8a
Sendline: 11
11 Calling read: alarm=10  Readnum=133 Read returned 1 bytes
2a Calling read: alarm=10  Readnum=133 Read returned 28 bytes
18 41 04 00 00 00 00 09 06 Retry 0: Bad CRC
Retry 0: Got ERROR
zgethdr: A 4 ERROR 5
zshhdr: f 4 ZRINIT 2a
Sendline: 2a
Sendline: 2a
Sendline: 18
Sendline: 42
Sendline: 30
Sendline: 31
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 31
Sendline: 32
Sendline: 66
Sendline: 34
Sendline: 63
Sendline: 65
Sendline: 64
Sendline: d
Sendline: 8a
Sendline: 11
6d 64 6d 66 61 71 00 38 39 32 37 33 20 00 18 6b 65 1c 11 Calling read: alarm=10
 Readnum=133 Readline:TIMEOUT
Retry 0: Got TIMEOUT
zgethdr:  4 TIMEOUT 0
zshhdr: f 4 ZRINIT 401480
Sendline: 2a
Sendline: 2a
Sendline: 18
Sendline: 42
Sendline: 30
Sendline: 31
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 31
Sendline: 32
Sendline: 66
Sendline: 34
Sendline: 63
Sendline: 65
Sendline: 64
Sendline: d
Sendline: 8a
Sendline: 11
Calling read: alarm=10  Readnum=133 Readline:TIMEOUT
Retry 0: Got TIMEOUT
zgethdr:  4 TIMEOUT 0
zshhdr: f 4 ZRINIT 401480
Sendline: 2a
Sendline: 2a
Sendline: 18
Sendline: 42
Sendline: 30
Sendline: 31
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 30
Sendline: 31
Sendline: 32
Sendline: 66
Sendline: 34
Sendline: 63
Sendline: 65
Sendline: 64
Sendline: d
Sendline: 8a
Sendline: 11
Calling read: alarm=10  Readnum=133 Readline:TIMEOUT
Retry 0: Got TIMEOUT
zgethdr:  4 TIMEOUT 0
Sendline: 43
Calling read: alarm=10  Readnum=133 Readline:TIMEOUT
Calling read: alarm=3  Readnum=133 Read returned 1 bytes
2a Calling read: alarm=3  Readnum=133 Read returned 9 bytes
18 41 08 00 00 00 00 02 2d Calling read: alarm=3  Readnum=133 Readline:TIMEOUT
Sendline: 43
Calling read: alarm=10  Readnum=133 Readline:TIMEOUT
Calling read: alarm=3  Readnum=133 Readline:TIMEOUT
Sendline: 43
Calling read: alarm=10  Readnum=133 Readline:TIMEOUT
Calling read: alarm=3  Readnum=133 Readline:TIMEOUT
Sendline: 43
Calling read: alarm=10  Readnum=133 Readline:TIMEOUT
Calling read: alarm=3  Readnum=133 Readline:TIMEOUT
Sendline: 43
Calling read: alarm=10  Readnum=133 Readline:TIMEOUT
Calling read: alarm=3  Readnum=133 Readline:TIMEOUT
Sendline: 43
mode:0

--

Netcom - Online Communication Services San Jose, CA

 
 
 

HELP! Using zmodem across a telnet session.

Post by Frank da Cr » Tue, 04 Jul 1995 04:00:00




: I am currently experiencing a persistent problem transferring
: files across a telnet connection using zmodem and would like
: some assistance in solve this problem.
: ...
: By the way, I did try kermit (C-Kermit 5A(190)) and it works fine
: (no surprise). But I have been unable to boost the transfer rate
: to an acceptable level despite using every combination of window
: count and packet size. I have read Frank da Cruz's books and
: reviewed past issues of Kermit News. He might be able to
: outperform zmodem but I have not been so lucky. I did use kermit
: in 8-bit mode which would seem to imply that I do indeed have a
: 8-bit clean data path.
:
Not necessarily.  Unless you have gone out of your way to prevent it
from doing so, Kermit might well have adapted itself to whatever type
of path it happened to find itself on.  That's one of its major
strengths.

Now that you have convinced yourself that Kermit works and Zmodem
doesn't, you have the choice of making Kermit work faster, or making
Zmodem work at all.

If you need assistance on making Kermit work faster, I'll be glad to
help.  Just send email.

- Frank

 
 
 

HELP! Using zmodem across a telnet session.

Post by Chuck Forsberg WA7K » Wed, 05 Jul 1995 04:00:00




>I am currently experiencing a persistent problem transferring
>files across a telnet connection using zmodem and would like
>some assistance in solve this problem.

>Here is a description of my data path:

>I dial into a SUN sparc (sun-sunos4.1.3_U1) UNIX workstation from
>a Macintosh IIci (System 7.5.1) using White Knight
>Telecommunication program (v12.06) and a US Robotics Courier HST
>dual standard with V.32bis and ASL modem. I connect to the SUN
>with 14400/ARQ/V32/LAPM/V42BIS. I then telnet from the SUN to a
>Silicon Graphics Crimson Elan UNIX workstation (IRIX 5.3) using
>the following syntax:

>               telnet [IP address]

>rlogin has been diabled on the SUN for security reasons and is
>not available.

>I am able to send and receive files on the SUN using zmodem. I am
>also able to receive files from the SGI using zmodem. BUT I
>cannot send files to the SGI from my Macintosh using zmodem. All
>transfer are done in binary mode. It appears that zmodem
>basically just times out.

>This same problem also occurs if I telnet into another SUN sparc
>workstation (instead of the SGI). I can receive files from the
>SUN but am unable to send files.

>The fact that I can receive files from my SGI using zmodem would
>imply that I should be able to send files. It appears that
>telnet is somehow preventing the transfer. Any idea why? Is the
>problem on the SUN side or SGI side?

>Do I need to use the stty command to adjust my terminal settings
>on the SUN/SGI side? What should I change?

>On the SUN stty shows:
>           speed 38400 baud; evenp -inpck imaxbel -tabs iexten crt

>On the SGI stty shows:
>           speed 9600 baud; -parity hupcl clocal line = 1;
>           brkint -inpck icrnl onlcr tab3
>           echo echoe echok e*

>I have tried changing these settings on both the SUN and SGI
>without any success.

>It has been suggested that my data path might not be 8-bit clean. If
>this is true, why am I able to transfer data from my SGI to the Mac?
>Or send and receive to the SUN? How would I check this? Is there a
>program which can check the data path?

>By the way, I did try kermit (C-Kermit 5A(190)) and it works fine
>(no surprise). But I have been unable to boost the transfer rate
>to an acceptable level despite using every combination of window
>count and packet size. I have read Frank da Cruz's books and
>reviewed past issues of Kermit News. He might be able to
>outperform zmodem but I have not been so lucky. I did use kermit
>in 8-bit mode which would seem to imply that I do indeed have a
>8-bit clean data path.

It's becoming apparent that Frank doesn't think Kermit really outperformed
ZMODEM based on his continued refusal to rerun Columbia University's so-called
"True-Life Benchmarks" under public scrutiny.

There are a number of ZMODEM options to use for dealing with pathological
situations.  Please check the relevant chapters in the ZCOMM user's manual
(zcommdoc.zip).

--

   Omen Technology Inc      "The High Reliability Software"
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, GSZ and DSZ
TeleGodzilla BBS: 503-621-3746  FTP: ftp.cs.pdx.edu pub/zmodem