Path: utzoo!attcan!utgpu!watserv1!watcgl!jmberkley From: jmberkley@watnext.waterloo.edu (J. Michael Berkley) Newsgroups: comp.sys.atari.st Subject: Re: What Kermit/UNITERM bugs? Message-ID: Date: 1 Dec 89 17:30:29 GMT References: <8912010813.AA04349@ucbvax.Berkeley.EDU> Sender: daemon@watcgl.waterloo.edu Reply-To: jmberkley@watnext.waterloo.edu Organization: University of Waterloo, Waterloo, Ontario, Canada Lines: 58 In-reply-to: 01659@AECLCR.BITNET's message of 30 Nov 89 19:26:00 GMT > On 30 Nov 89 19:26:00 GMT, 01659@AECLCR.BITNET (Greg Csullog) said: GC> The ONLY Kermit I trust is UNITERM's so WHAT problems are there? I too like and trust Uniterm, but there is a small, subtle bug in the 8th bit quoting negotiation. Here is a copy of the message I tried to send to Simon Poole: --------------------------------------------------------------------------- Date: Mon, 31 Jul 89 13:03:36 EST From: jmberkley Subject: Uniterm Kermit and 8th bit quoting negotiation I'm having trouble with Uniterm and 8th bit quoting. When Uniterm and Ckermit negotiate, the transfer does not correctly go into 8th bit quoting. I asked Frank da Cruz for advice and debugging assistance. A summary of his reply is printed below. The problem seems to be that Uniterm says '&' for 8th bit quoting, and Ckermit replies with 'Y' (meaning yes I'll do it). But Uniterm takes the 'Y' to be the 8th bit quoting character (!). The 'Y' reply by Ckermit is documented in the kermit protocol manual from Columbia. If I set the 8th bit quoting character to be 'Y' in Uniterm, then 8th bit quoting is properly and successfully performed. I am using the latest version of Uniterm from cs.orst.edu (sorry, but I cannot remember the version number right now) and Ckermit 4F(085). Thank you Mike Berkley, University of Waterloo PAMI Lab jmberkley@watnext.waterloo.edu {utai,uunet}!watmath!watnext!jmberkley ------------------------------------------------------------------------- On Wed, 19 Jul 1989 12:44:01 EDT,Frank da Cruz said: FdC> I checked 8th bit quoting between C-Kermit 4F(085) and MS-Kermit FdC> 2.32/A. These two function perfectly together -- 8th-bit FdC> prefixing is negotiated correctly, and binary files are uploaded FdC> from the PC to Unix correctly. FdC> I looked at the packet log. There are only a few "&" characters FdC> inside the data packets (well under 50), whereas the file is FdC> about 14K long. In an average binary file, you would expect to FdC> find 50% of the characters with their 8th bits on, in this case FdC> about 7000. This would indicate to me that Uniterm is not doing FdC> 8th-bit quoting. FdC> It appears that although Uniterm is putting the right things FdC> about negotiating 8th-bit-prefixing in its S-packet, that it is FdC> not following through with this during the data transfer. The FdC> protocol says that if one side says "&" (as Uniterm did) and the FdC> other side says "Y" (yes, as C-Kermit did), then 8th-bit FdC> prefixing will be used. Apparently, it was not.