SUMMARY: Anyone use ZMODEM on a Sun? <- Detailed

From: Bob Witmer (bw3576@u.cc.utah.edu)
Date: Sun Feb 27 1994 - 13:32:47 CST


SUMMARY: Anyone use ZMODEM on a Sun?

Thanks go to:

Alan Hightower,
Ben Taylor,
Dave Lynn,
David Beckemeyer,
Donald Nichols,
Leeling Ho,
M.V.S. Ramanath,
Michael Peppler,
Rob Vassar,
Steve Kelley,
Thad Floryan and others.

3 solutions were proposed:

1. How to use tip with rz.
2. How to increase performance with Kermit-5A.
3. Pcomm, Minicomm, Ulayers, Seyon. Other unix comm programs.

What follows are detailed fragments of responses grouped
by the above topics.

Zmodem:

The way to use Zmodem from two Suns is to use a tip connection
and escape "~C" and then run rz locally.

The way I do it is:
 - use tip to call, connect with, and log into the other machine;
 - via tip, tell the other machine to send or receive (sz fnames or
   rz, respectively)
 - tell tip to invoke the corresponding software on your side using
   the ~C command (e.g., ~Crz or ~Csz fnames, respectively)
 - log off the remote machine via tip.

If I want to transfer a file from a remote system to local, I use tip
to call the remote system, in the remote shell I type 'sz filename',
then I do '~C rz' to start rz locally, and that's it!

>But I
>don't see anyway to get it to initiate the call through
>the modem.

        It, (rz, sz), was designed to simply act as a server
to zmodem-capable programs calling in to the system, and
never designed to call out.

BUGS
       Calling sz from most versions of cu(1) doesn't work
       because cu's receive process fights sz for characters from
       the modem.

I have gotten better throughput using ZMODEM, however,
all the little games with making it work has left me a
little disillousioned with it.

The problem is that the source for rz/sz is shareware.
Chuck Forsberg has put in little things in the code
to make it harder for you to us rz/sz from cu or kermit,
or Seyon. Depending on the version of rz/sz, you may
have to hack it up. (I've got the mods at home).
To use it with kermit, you can use the following only
iff you have bash or ksh. This goes in your
.kermrc file. These would be kermit commands. At
local mode in your above example, you would type rz
after having started your sz on the remote side.
If you are doing this, you definitely want kermit using
flow control (RTS/CTS)

---------------------------------------------------------------

; Send specified file(s) with ZMODEM
;
define sz if = \v(argc) 1 FATAL {Send what file ?}, -
  if not exist \%1 FATAL {File \%1 not found.}, -
  run sz -
    \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 <&\v(ttyfd) >&\v(ttyfd), -
  connect

; Receive file or files with ZMODEM
;
define rz run rz <&\v(ttyfd) >&\v(ttyfd), connect

Conversely, if
the zmodem side balks at being redirected, pick up an OLDER copy of
rzsz from numerous FTP sites.

You need an 8 bit connection for zmodem. Put a "set terminal bytesize
8" in your .kermrc, or issue manually.

Dial out and establish usual connection with kermit.

To send files:
   Escape to local kermit prompt (Control-\ C).
   Type "push" at kermit> prompt and you'll get a shell prompt.
   Type "sz filename > /dev/ttyx" where x is your serial port (probably
      /dev/ttya or /dev/ttyb)
   "exit" from shell prompt when complete, and then "c" at kermit>
   prompt to re-connect to session.

make sure that "rz" is in your path on the remote system.

To receive files:
   Type "sz filename" on remote system
   Escape to local kermit> prompt
   Type push
   Type "rz < /dev/ttyx > /dev/ttyx"
   "exit" and "c" as above.

BTW, sometimes the remote sz times out before you have the local rz up
and running. In that case, just delay the remote sz by 5 seconds or
so, but escape and start to prepare rz immediately, e.g.:
   remote_system% sleep 5; sz filename
for csh.

I find zmodem faster and prefer it for longer files, especially for its
"resume" capability (an interrupted file transfer preserves the
partially received file, and will pick up where it left off when you
send the file again),

Running zmodem on your local machine is possible, but it requires
hacking the source code to rz and sz to redirect the devices.
The only reason to mess with it is so you can communicate with
other systems such as BBS's which don't support Kermit.

After you do this, you can run rz/sz from the Kermit command line
on your local machine using the ! function. The best rz/sz to use
is the PD one from about 1988.

Kermit:

Increased throughput can be had with Kermit

        This is with: C-Kermit 5A(189), 30 June 93, SunOS 4.1 (BSD).
Presumably, later versions would offer the same choices and more.

Use the following on both ends:

set send packet 512
set receive packet 512
set block 3
set window 8

        The first two set the packet length to use a far more efficient
size. (Less time wasted handshaking per byte transferred.)
The third is necessary with the larger packet sizes.
The fourth keeps the system from waiting for an acknowledge on one packet
before starting to send the next. This is a major good except when a packet
fails, in which it throws away the subsequent ones to retry from the point
of failure. (At least, that's what it looks like through a Telebit
WorldBlazer between the SPARC at work and the 3/280 here at home. (The
SPARC at work is a farily busy server, and it is during backups that I wind
up doing transfers most often, so I suspect overruns of the serial ports at
that end.)
        Depending on the speed of the modem, and the machines at each end,
you may be able to extend the packet sizes shown above to some extent, but
if noise causes a resend, the larger the packet, the more information needs
to be resent, and the greater the hit on the effective transmission rate.

    Reguarding the rz/sz ZModem problem, you can do the dialup through kermit
then exit into local mode. Either quit kermit, or flip windows and execute
a rz (or sz) < /dev/modem > /dev/modem or whatever your modem device or tty
is on. Worked for me..... It will not have any kinda screen output, but you
can either use ps or run it in the background and wait for a termination
to
tell when it is done...

To improve your kermit throughput, try the following:
(with 5A(189) C-Kermit or better)

Use hardware flow control - set flow rts/cts
Use a big buffer - set buffer 100000 100000
  or whatever seems reasonable. Just realize that the packet size
  times windows is the minimum of what your buffer should be
Use a big packet - set [send/receive] packet [1000-5000]
  this also requires - set block 3
Use multiple windows - set windows [5-31]
To improve performance on a sun-modem-modem-sun connection, you
can probably disable the control prefixes - set control unprefix all
  If you have problems, it is probably due to XON/XOFF flow control
  being set. You can reprefix ascii 17/19 and the 8-bit versions
  with - set control prefix 17 19 145 147. If you are going through
  a terminal server, you will have to experiment.
If you do the above, you will want to "probably" disable file
cancellation. What this means is you can pass 2 ^C and kermit
on the server side will quit and go back to terminal mode.
I think Frank fixed this to be 3 ^C's in the 190 release.

but you can squeeze tolerable performance out of
kermit with little hassle. From my .kermrc:

set speed 38400
set file type binary
set send packet-length 2048
set receive packet-length 2048
set buffers 100000 100000
set windows 8
set flow-control rts/cts

Get the long-awaited rts/cts patch for Sun's serial ports, or use "set
speed 19200" (on a busy system without the patch, you may even have to
set the speed lower).

I leave binary enabled all the time, so I won't forget to set it for .Z
and other binaries. For unix-unix transfer, you don't need the
text-mode translations anyway.

The packet-length can be set even longer if you have clean lines and a
V32.bis modem, but if you have neither even an occasional corrupted packet
takes too long to resend.

        I use kermit to initiate the call, and as a basic terminal prograam.
When I'm ready to download something, I start the zmodem download on the
remote system and then escape back the the local kermit prompt and
execute rz withe the command "! rz </dev/ttyb >/dev/ttyb". This performs
the zmodem transfer, and returns me to kermit when its done. Zmodem is
much more effecient. I nearly doubled my transfer speed by switching to it
from the kermit protocol.

        Note... I'm told there's a way to get kermit to insert the
/dev/<device> statement into the shell command by writing a macro. But I
do not know how to do this. I only have one modem on /dev/ttyb, so I've
never really felt the need.

 Be sure you have C-Kermit 5A(189)
or newer on both machines. This corresponds to MS-Kermit 3.13
on the PC. It has long packets, sliding windows, and the ability
to defeat prefixing of control characters (particularly effective
when sending binary files). All of these used together will give
you performance equal to or better than zmodem. This was documented
in the most recent issue of Kermit news from Columbia. Here is my
.kermrc for the remote Kermit (Unix system). The commented lines
are left over from my local Kermit.

#set line /dev/tty000
#set speed 2400
#set modem hayes
#set fi ty bin
set fi nam lit
set send pack 1000
set rec pack 1000
set parity none
set block 3
set window 2
set control unprefixed all
set control prefixed 0 1 3 129 131

Pcomm, Minicomm, Ulayers, Seyon:

>Or if I had some comm software on the local Sun.

        For that, you have options. Look for pcomm (which is a unix-based
version of the shareware/commercial program ProComm). I have built and used
it on a 3b1 (AT&T UNIX-PC, a 68010-based machine). I have not built it on
the Sun, because by then the advanced versions of Kermit were here, and they
give all the transfer speed that I need.

pcomm version 2.0.2 works just fine on all my Suns (Sun-3/60, IPX, ELC, etc.)
as an interactive comm program. It interfaces nicely to external programs
such as rz & sz, and has the usual suite of [xy]modem protocols built-in.

Using pcomm and rz/sz and with the modems I have, I average 4MB/hr to/from
any of my Sun systems and to/from other systems.

pcomm can be found using archie and/or in the comp.sources.[misc or unix]
archives. Note, though, you probably need the older versions of rz/sz
(circa 1987) since the newer versions were deliberately crippled by its
author.

I would recommend getting
some comm software. Minicomm, originally for Linux, can be compiled on a sun
using GCC and GNU make... this is a pretty good package. You can find it at
most Linux sites....

You might also want to look at my "ulayers" program
which was posted to comp.sources.misc and is on netcom
in pub/davidb/ulayers.

Yes! (seemingly) exponentially faster than the brain fried green frog!
If you have a sparc at home get "seyon" (try contrib dir at mit - home
of X) as a comm util. A bit awkward but has tele dir, login scripting,
and AUTOMATIC ZMODEM detection/down-load. I have yet to get the
ZMODEM uploading working but it downloads fine.

(APPLAUSE!) for the author.



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:57 CDT