Here's a post to the list from 12/94 on using sz/rz with the opion "-e"
for escaping control characters. Don't know if there's new problem with
though with ComOS 3.5, but doubt it as haven't heard anything the past 8
months. See if this works for you. Also be sure to use sz/rz from our ftp
site:
ftp://ftp.livingston.com/pub/src/sz.tar.Z - the best version of rz/sz we
know of.
Date: Wed, 7 Dec 94 01:22 PST
From: ade@pacifier.com (Adrian Miranda)
To: Robert Shady <rls@zeus.id.net>
CC: portmaster-users@msen.com
Subject: Re: Z-Modem uploading through a Portmaster 2E-30
In-Reply-To: <199412070443.XAA18628@zeus.id.net>
References: <199412070443.XAA18628@zeus.id.net>
Reply-To: Adrian Miranda <ade@psg.com>
Sender: owner-portmaster-users@garnet.msen.com
Precedence: bulk
Status: R
Robert Shady writes:
> Okay, I've posted this once before, and didn't get a satisfactory response.
Well, I have some different solutions, and I consider them more
satisfactory then what you cite below, but still not exactly perfect.
I hope some will find this useful... Note that I have our Portmasters
configured to use telnet to connect to remote systems, (and I assume
Robert is doing the same) if you use some other service like rlogin
none of the following applies to you.
> They can Z-Modem download without any problems, but when it comes to
> Z-Modem uploading it get's to about 4k & dies, usually with CRC errors.
>
> The responses I've gotten so far are, tell them to use "sz -e" or "sz -w"
> when they upload. Can't do that. Shouldn't have to. It *DOES* work,
> I've tried it, but 99% of our users are calling in using Procom, Telix,
> or Q-Modem. They DO NOT want to configure external protocols, and I don't
> blame them.
In case anyone doesn't realize it, the "-e" option means to escape
control codes, and is needed because some control codes are not making
it from the modem to the rz process on your unix system unmolested
(more about this below). Of course, they can't really specify sz -e
when they are uploading with a program other than sz, however they can
invoke "rz -e" on the unix system. This is not too onerous, and you
could even modify your rz to always have the -e option on (perhaps
only if the user appears to be connecting from a Portmaster). This
will work with most PC/Mac based zmodem programs, but NOT all - some
programs will simply hang. This (either sz -e or rz -e) is what
Livingston seems to be recommending these days (though not before some
of us spent considerable time figuring it out on our own)...
Of course, since the -e option means to escape control codes, that
will slow down transfers of binary files.
The "-w" option is used to specify a window, if that helps the user
has probably got hardware handshaking problems. (Of course, it is
assumed that you have hardware handshaking configured between your
modem and terminal server, if you don't you should probably do so
immediately.) This will NOT fix the problem that the -e option
addresses. However many users do not configure their systems and/or
modems correctly, so if you have a user complaining about bad
transfers, it is may be helpful to suggest they try invoking "rz -w
1024" on the UNIX system. Note that some terminal emulation programs
may gag when rz is invoked this way.
> At least two of our users claim that when they were with MSEN, they were
> able to upload through their portmaster without any problems. Does anyone
> at MSEN want to give some insite into this little problem?
The telnet client on the portmaster is, indeed, 8-bit transparent.
However, when it connects to the telnetd on the remote system, it does
not tell that system that the connection is 8-bit transparent. This
is probably wise, since most (all?) telnet daemons do some generally
undesirable things when you negotiate the telnet binary option.
The problem is that most (all?) telnet daemons, if they are not in
binary mode, will eat the line-feed whenever they see a
Carriage-Return Line-Feed pair. (I think some daemons may also play
with other characters, eg: eating the NULL in a carriage-return NULL
pair.) The solution is to modify your telnet daemon to not do this.
This works fine with most telnet clients, however several mac telnet
clients default to sending Carriage-Return Line-Feed pairs when the
user hits return. Some of these clients do not even seem to be
configurable, however NCSA telnet for the Mac is reported to have an
option to control this.
Of course, you don't have to use telnet to connect from your
portmaster to your UNIX system, however many of us do prefer it...
Incidentally, when I was first working with the Portmaster, there was
some evidence it was not 8-bit transparent, however I have seen no
evidence of this with newer versions of the Portmaster software. I'm
not really certain the older software had a problem either, but it
doesn't hurt to make sure you are running the newest software.
Adrian Miranda
>
> Is the co-lo server running Linux? I've reported it before, and several
> other people have confirmed that Comos 3.5 does not like sz under linux
> (well particuarlly 2.0.30 since that's what everyone who reported the
> problem seems to be running) My personal belief, is that something in the
> rlogin code in ComOS and in Linux is making it not be 8 bit clean, and
> Linux is getting an XOFF and suspends transmittal until it receives an
> XON again. However, so far I haven't found anything deffinate about
> the situation, though it's been strking us for the past several months.
>
> ---
> |Douglas ``Wildcat'' Warren |Email: dwarren@netusa.net| Jura gur tbireazrag
> |Network/Security Consultant|Phone: (516) 543-0234 | bhgynjf Pelcgbtencul,
> |President of SBCS a chapter| Fax: (516) 543-0274 | bayl pevzvanyf jvyy
> |of the ACM. | PGP: finger dwarren | unir cevinpl
>
>
Theo Van Dyne Livingston Enterprises Inc. Phone: (800) 458-9966
Network Drano 4464 Willow Road Fax: (510) 737-2110
support@livingston.com Pleasanton, CA 94588 http://www.livingston.com