Path: utzoo!attcan!uunet!portal!cup.portal.com!R_Tim_Coslet From: R_Tim_Coslet@cup.portal.com Newsgroups: comp.sys.atari.st Subject: Re: 8th-Bit Prefixing Bug in UniTerm Kermit Message-ID: <6952@cup.portal.com> Date: 29 Jun 88 02:30:10 GMT References: <6720@cup.portal.com> <344@forty2.UUCP> Organization: The Portal System (TM) Lines: 86 XPortal-User-Id: 1.1001.4086 In article <344@forty2.UUCP> poole@forty2.UUCP (Simon Poole) Writes: >In article <6720@cup.portal.com> R_Tim_Coslet@cup.portal.com writes: >... >> >>The UniTerm Kermit has the following bug in its 8th-Bit Prefixing >Algorithm when it is Receiving... > >Thanks for taking the trouble to report this problem and making >such a 'in depth' analysis, but as so often the reason for the effect >you are seeing is something completly different than the conclusion >you arrived at, and definitly is NOT a bug in the 8th-Bit Prefixing >Alogrithm. >> Other Kermit UniTerm Kermit >> >>Mode: Sending Receiving >>"S" Packet QBIN field: "&" (Prefix) "Y" (I can Prefix) >> >>Thus the two Kermits have agreed to do 8th-Bit Prefixing. >No, they haven't! What you CAN'T know, is that UniTerm actually >responds with the prefix character the other Kermit wants to use >if it gets the send-init packet correctlly (it only uses 'Y' if it >is initiating the transfer and doesn't need prefixing or the other >Kermit has sent 'Y' aswell (the correct meaning of 'Y' being: >I don't need to prefix, but I'll do it if you want to...), so the No, sorry, quoting from page 241 of "KERMIT, A File Transfer Protocol" by Frank Da Cruz, Table 10-2. Eight-Bit Prefix Negotiations. ------------------------------------------------------------ Sender Receiver Prefixing? ------------------------------------------------------------ Y & Yes & Y Yes & & Yes Y Y No & N No N & No & % No Y (blank) No ------------------------------------------------------------ Therefor, if EITHER the sending or recieving Kermit requests prefixing (by specifying a prefix character) if the other says it is capable of prefixing (by specifying Y), then the Kermits have negotiated that 8-Bit Prefixing WILL be done by BOTH Kermits. If both only say that they are capable (by specifying Y), then 8-Bit Prefixing WILL NOT be done. Also if EITHER Kermit says it is not capable of prefixing (by specifying N) or BOTH Kermits request but do not agree (by specifying DIFFERENT prefix characters), then 8-Bit Prefixing WILL NOT be done. >problem is actually one of the following: > - UniTerm not receiving the send-init packet correctly > - UniTerm not interpreting the contents of the send-init packet > correctly >(later being rather unlikely, as it works without problems with >C-Kermit 4d and 4e (caveat: don't try it with 4e, it's got a few problems >with 8-bit prefixing), VM/CMS Kermit, VMS Kermit, Kermit-11 and MS-DOS >Kermit (I retested with exactlly the sequence you had problems with)). >To get an analysis of what is causing the problem, I need: > - a copy of the log file (packets only), the first few packets > will be enough I will do this when I can, but as neither Kermit (UniTerm or the Other one) do logging to files I can't do it at this time. I will add debug packet logging to the other Kermit eventually. By the way, the data I gave you from the QBIN fields came from DEBUG messages printed by the other Kermit but as it did not write a file I only showed the "relavent" data, to save typing. > - Name and version of the other Kermit The other Kermit is Kermit-UCSD. I am currently in the process of upgrading this Primitive Kermit to full capabilities. As of right now it has no version number. > - a list of all the settings of the RS232 port and Kermit. I will also forward this to you as when I get logging added and can provide full information. However the most important thing is that the Kermit-UCSD is running with "Space Parity" as I have trouble with setting the machine's serial port I/O drivers to pass all 8-Bits. Thank you for responding promptly to my Bug Report. R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet