Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!ns-mx!umaxc.weeg.uiowa.edu!williams From: williams@umaxc.weeg.uiowa.edu (Kent Williams) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: More ZMODEM discussion Keywords: consistent errors Message-ID: <4081@ns-mx.uiowa.edu> Date: 22 Jan 91 17:29:30 GMT References: <6804@emory.mathcs.emory.edu> Sender: news@ns-mx.uiowa.edu Reply-To: williams@umaxc.weeg.uiowa.edu (Kent Williams) Organization: U of Iowa, Iowa City, IA Lines: 49 In article <6804@emory.mathcs.emory.edu> arasmith@mathcs.emory.edu (David Arasmith) writes: >I am, perhaps, abusing the real purpose of this group, but I've seen >alot of discussion lately concerning DSZ. I am trying to get it working >correctly online to a Sun running SunOS. I can transfer files but at the >cost of LOTS of transmission errors. I am getting consistent error >messages from dsz: > At byte 3072 - subpacket too long > at byte 7168 - subpacket too long > at byte 11264 - bad CRC > >with the occaisional "garbled data packet" thrown in. It is very difficult >for me to believe that this is due to noise. > > Just to include all the relevant info: > 386 DOS machine, > Practical Peripherals 2400baud MNP5 modem > MNP5 connection with UNIX machine > Problems occur in standalone, called from Kermit, called from Procomm+ > >Email would be good, but I'll also try to keep up with this group. > >Thanks a bunch, sorry for the abuse! You will see these problems if you don't have a 'true' binary line end to end. The problem might go away if you use 'sz -e' on the sending side. This will escape all control characters, instead of just the ones zmodem cares about. A major problem comes from the unix side of the transfer not successfully getting the tty device set fully raw. Since this is a non-portable operation, look at the source code where the port gets set. If all else fails, you can use the code that does a system("stty raw"); in order to raw the port. Another problem that I've never solved is that the sending side is supposed to sample the receive channel after each sub-packet to see if a packet has been nacked. This mechanism works as advertised between two DOS machines; but if you get a packet error when talking to a Unix machine, it can sometimes take 30 seconds to resync and back up. -- Kent Williams --- williams@umaxc.weeg.uiowa.edu "'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams" "This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"