Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!crdgw1!ge-rtp!ge-dab!peora!rtmvax!bilver!bill
From: bill@bilver.UUCP (Bill Vermillion)
Newsgroups: comp.dcom.modems
Subject: Re: xyzmodem problems
Message-ID: <206@bilver.UUCP>
Date: 17 May 89 13:26:57 GMT
References: <24404@agate.BERKELEY.EDU> <8457@chinet.chi.il.us> <24440@agate.BERKELEY.EDU>
Reply-To: bill@bilver.UUCP (Bill Vermillion)
Distribution: usa
Organization: W. J. Vermillion, Winter Park, FL
Lines: 25

In article <24440@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:
>In article <8457@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>>In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:
>>>machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols)
>>>work for downloads, but uploads INVARIABLY stop after 16 blocks have
>>>been transferred.  This is consistent over half a dozen different machines
  
>>>Any ideas?  kermit works (with mark parity).

>>Something in the link is set to use XON/XOFF flow control.  Packet 17
>>in x/ymodem will use a literal 17 (control-S) as the packet number
>>and hang the link. 

Something doesn't sound right here, to me at least.  17 (decimal) is a control
Q which is a restart after xoff.  Control S is decimal 19.  The way I see it,
either kermit doesn't use the lower numbers, and sends a 19 for 17 - that
doesn't seem at all logical, or something else is coming in to play.

I counted on my fingers TWICE! :-)

What am I missing here 

bill
-- 
Bill Vermillion - bill@bilver.UUCP