Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!caen!uflorida!haven!wam!dmb
From: dmb@wam.umd.edu (David M. Baggett)
Newsgroups: comp.sys.atari.st
Subject: Re: Kermit/UniTerm/Vax Problem...
Keywords: Vax, Kermit, UniTerm
Message-ID: <1990Dec10.132402.24016@wam.umd.edu>
Date: 10 Dec 90 13:24:02 GMT
References: <1990Dec10.040058.24452@udcps3.cps.udayton.edu>
Sender: usenet@wam.umd.edu (USENET Posting)
Reply-To: dmb%wam.umd.edu@uunet.uu.net (David M. Baggett)
Organization: University of Maryland at College Park
Lines: 25

In article <1990Dec10.040058.24452@udcps3.cps.udayton.edu> 
vanleejf@udcps3.cps.udayton.edu (James Van Leeuwen) writes:
>                                              Specifically, while uploading
>a .LZH or .ARC file,I'll get about four packets into the transfer and then the 
>Vax comes back with an error to the effect of: "Packet too large for internal
>buffer."  I am in binary mode on my end and in server mode on the Vax (so that
>all of the settings should be automatically set).

I've noticed that with all the Unix C-Kermit implementations I've
tried, setting the packet size > 94 (on both ends) will cause sends to
fail, but not receives.  This happens in binary mode (don't know about
text mode).  I don't know whether this is a C-Kermit bug or a Uniterm
bug, but I don't think the behavior is exclusive to Vax systems.  (It
happens to me with Suns too.)

Interestingly enough, I don't get "packet too large" messages; in my case
Uniterm just sends about 15 packets in rapid succession and then says
"too many retries".  I've never discovered a solution; hence all my
uploads now run with 94 byte packets.  :(

BTW, It does not seem to be the case (for me, at least) that server
mode sets all the params automatically...

Dave Baggett
dmb%wam.umd.edu@uunet.uu.net