Zmodem upload problems

[Dave Platt]

In article <1989Dec21.200309.17636 at ux1.cso.uiuc.edu> garyf at mehlville.ncsa.uiuc.edu (Gary Faulkner) writes:
> In article <80 at ucunix.SAN.UC.EDU>, rainwatr at ucunix.san.uc.edu (Don
> Rainwater) writes:
> > > 	I'm able to download (sometimes very large) files from Ultrix
> > without any trouble, but uploads don't even get past the first byte.
> > The error I get is "ZRPOS=0".  I have the same problem trying to upload
> > from an IBM/PC-AT compatible running DSZ, so I think we can eliminate
> > the Mac from the list of suspects.
> > 
> 
> Yep, we have the same problem with our ultrix and our sun hosts using
> rzsz, again for uploads only.  I am taking the liberty of cross posting
> this response to comp.sources.bugs to attempt to get a dialog/fix going
> in that area.  I don't think anyone has complained (at least not very
> loudly) about this yet, and hopefully someone has a fix for the problem.

The ZMODEM protocols requires that the sender->receiver channel be able
to transmit 8-bit-wide data;  the receiver->sender backchannel only
needs to be 7 bits wide.

I suspect that your Ultrix and Sun systems, or perhaps your
terminal-servers, are set up so that they expect to see data arriving
in 7-bit-plus-parity-of-some-gender, and that they are stripping the
parity bit off of the data before passing it on to the receiver (rzsz,
in this case).  This will entirely confuse a ZMODEM transfer;  the
packet CRCs will not match, and the receiver will repeatedly ask the
sender to retransmit the first packet (ZRPOS=0).  Eventually the transfer
will choke and abort.

ZMODEM also transmits control-characters in its data... both as part of
the packet-control sequences, and in the data.  It normally "escapes
out" a limited set of control-characters... XON and XOFF, and a few
others which tend to be "eaten" by network hardware or software.  It's
possible to tell a ZMODEM sender to escape all control characters...
in ZTerm 0.85 this is done in the "ZMODEM Parms..." dialog box.  This
might help...

It is not possible to transmit data using ZMODEM if your sending
channel is only 7 bits wide.  You may be able to configure your
terminal-server so that it will grant you a clean 8-bit-wide input
channel... "8 data bits, no parity, 1 stop bit" is the usual
incantation in telecom programs.  I recall that "tip" hardware could be
persuaded to do this, by giving certain commands during the connection
sequence;  your term'server may have similar capabilities.

If you can't arrange for an 8-bit clear input channel, you won't be able
to use ZMODEM to upload, and will need to fall back and punt... use
MacKermit (or the equivalent).  Recent Kermits can use large packets...
1K bytes or so... and can deliver decent throughput.  You'll lose some
bandwidth because Kermit will be forced to escape all characters whose
8th bit is on... but this is inevitable if you don't have an 8-bit-wide
data channel.

I've used ZTerm (many versions) to upload data to my Sun systems running
rzsz.  As long as I go in through a serial-port configured for 8-bit
input, everything works fine.

I believe that rz attempts to put the tty channel into "raw" mode when it
starts receiving.  This apparently turns off parity checking and enables
8-bit input.  It's possible, I suppose, that this feature isn't effective
if you're logged in over a TELNET-style connection from a terminal
server.
-- 
Dave Platt                                             VOICE: (415) 493-8805
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: dplatt at coherent.com
  INTERNET:       coherent!dplatt at ames.arpa,  ... at uunet.uu.net 
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303