R_Tim_Coslet@cup.portal.com (06/21/88)
I have encountered a bug in UniTerm's Kermit File Transfer Protocol.
I thought other users of UniTerm might like to know about this Bug, so
below is a copy of the e-mail I sent to Simon Poole on the problem
I encountered.
===============================================================================
I am currently using UniTerm 2.0c 008
The UniTerm Kermit has the following bug in its 8th-Bit Prefixing
Algorithm when it is Receiving...
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.
During the transfer (about 11K Binary) the following occures...
Data in file: 26 B0 (Hex Bytes)
Other Kermit Sent: #&&0 (Ascii in "D" Packet)
UniTerm Kermit Wrote: 66 26 30 (Hex Bytes)
Somehow the UniTerm Kermit is converting (what should be) 2 Bytes
of data into 3 Bytes (also UniTerm Kermit failed to set ANY 8th-Bits
anywhere in the file it wrote!). It looks to me like UniTerm Kermit
does not recognize that it has agreed to do 8th-Bit Prefixing, and has
1) controlified the first "&" even though it isn't a "control character",
2) then saved the "&0" directly without decoding the Prefix.
The UniTerm Kermit does correctly perform 8th-Bit Prefixing
when it is Sending...
UniTerm Kermit Other Kermit
Mode: Sending Receiving
"S" Packet QBIN field: "Y" (I can Prefix) "&" (Prefix)
Thus the two Kermits have again agreed to do 8th-Bit Prefixing.
During the transfer (about 11K Binary) the following occures...
Data in file: 26 B0 (Hex Bytes)
UniTerm Kermit Sent: #&&0 (Ascii in "D" Packet)
Other Kermit Wrote: 26 B0 (Hex Bytes)
I have verified this Bug both in UniTerm 2.0c 008 and in an old
UniTerm 2.0a that I still have available.
If it would be any help in debugging this problem, write me and
I will send you a UUENCODED copy of the about 11K Binary file I
tested it with.
R. Tim Coslet
Usenet: R_Tim_Coslet@cup.portal.com
BIX: r.tim_cosletpoole@forty2.UUCP (Simon Poole) (06/27/88)
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 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 - Name and version of the other Kermit - a list of all the settings of the RS232 port and Kermit. >During the transfer (about 11K Binary) the following occures... ... Rest of letter irrelevant ....... ... -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
R_Tim_Coslet@cup.portal.com (06/29/88)
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
R_Tim_Coslet@cup.portal.com (07/03/88)
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 >problem is actually one of the following: > - UniTerm not receiving the send-init packet correctly Yes, I found the bug in my Kermit-UCSD. Sorry about the False Alarm. I had looked through all my code before I reported the "bug" but had missed the bug in my code. I found it today while putting in some new code for something entirely unrelated. My "S" packet was one byte short (i.e. I had not really sent the "&" even though the debug messages said I had). >... >Rest of letter irrelevant ....... >... Thanks again for responding so quickly to my "Bug Report". Sorry for the False Alarm. Uniterm is a very good Terminal emulator and I use it all the time. Unfortunately it is the only implementation of Kermit I had that supported 8th-Bit Prefixing to test my Kermit-UCSD against. If I had been able to test it against another Kermit I would have realized sooner where the bug REALLY was. That little bit of information on the QBIN field that Uniterm responds with helped. R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet
poole@forty2.UUCP (Simon Poole) (07/05/88)
In article <6952@cup.portal.com> R_Tim_Coslet@cup.portal.com writes: >In article <344@forty2.UUCP> poole@forty2.UUCP (Simon Poole) Writes: >>In article <6720@cup.portal.com> R_Tim_Coslet@cup.portal.com writes: ... >>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. ... Sorry, I should have provided the reference: "Kermit Protocol Manual" by Frank da Cruz, Sixth Edition Page 24: "Y I agree to 8-bit quoting if you request it (I don't need it)" (This manual does have the advantage of being free). So the question is: how compatible is Frank da Cruz with himself? :-) Anyway I don't see why the Protocol allows 'Y' in a response to a send-init packet, it being totally redundant (as the table you quoted shows nicely). -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------