lbafrin%clemson.csnet@CSNET-RELAY.ARPA (Larry Afrin) (09/04/85)
[Also posted to Info-Kermit@CU20B, but some of you wizards may have a relevant contribution you can make (I hope).] Fellow Froggers, Hi, it's me again with an update (and a new problem) on using Kermit to do file xfer between a PC and an NCR Tower via GTE Telenet. Thanks goes to Herm Fischer (hermix!fischer@rand-unix) for supplying a solution (SET PARITY EVEN on both ends) that solves the file xfer problem (more or less -- see below). Also, thanks to Keith Petersen (w8sdz@simtel20), who found an old Info-Kermit message on this subject (suggesting that a "SET? 0:33,63:0" command be given to Telenet) -- good try, but no cigar. Anyway, here's the new problem. Downloading from the Tower to the PC works just dandy now. Uploading is the problem. The symptoms of the problem are that every few packets (*regardless* of what packet length the sender has chosen) some characters get lost, resulting in the Tower Kermit's request for retransmission. No garbage characters, just lost characters. No discrimination as to text or binary files, and no discernible pattern as to which packets get hit or when a packet will get hit. The odds of any given packet getting hit seem to range from about 1 in 10 to 1 in 5, with the interesting observation that if a packet is hit, the retransmission of the same packet is *much more likely* to get hit, apparently at least a doubling of the probability. Eventually the upload completes successfully, but not without a significant number of retries. I did some tracing by (1) turning on Tower Kermit's packet logging feature (LOG PACKETS) and (2) starting up the Tower's Data Capture Utility, which is a piece of diagnostic software that (I believe) links in somehow to the lowest levels of the tty driver and can show me exactly what is being received through any port (we're talking low-level here, folks -- even before any parity-bit stripping is done). The DCU is transparent to any software using the port being monitored. In this case I told the DCU to only monitor incoming data (Tower Kermit's acknowledgement packets make it back to the PC OK). Other particulars of this test: the PC Kermit is the latest, version 2.28, running on an early model (16/64K motherboard) IBM-PC at 1200 baud, even parity (since that's what Telenet likes). The Tower Kermit is also the latest, version 4C(057) of C-Kermit, running on an NCR Tower 16/32 under Release 2.00 (that's right, Tower trivia fans, 2.0*0*) of the Tower operating system, which is NCR's first attempt at System V (closest comparison would probably be what you UNIX fans think of as "System V Release 1", I think). Tower Kermit is also running at 1200 baud, even parity. (If anyone needs more details on the configuration, please let me know.) For this test I attempted an upload of a 1.7K Pascal source file. Below are excerpts from the packet log and the DCU report showing the protocol of a successful packet transmission followed by the protocol of a quadruply- retried transmission. Note that the DCU report shows a dump of the characters received before they were stripped of their even-parity bit by the tty driver. Note that the packet length was set to 75 so that retried transmission. Note that the packet length was set to 75 so that each line in the packet log would fit on one line on a terminal screen. This setting in no way prejudices the results, as the same effects have been observed in tests with packet lengths ranging from 40 to 94 characters. Excerpt from Packet Log h.Degin#M#J~- writeln(^G'invalid file name');#M#J~- halt;#M#J~- end;#M#J6 #.YL (Comment: this is a positive acknowledgement of the above packet) g/D#M#J~& ~$ write('New File Name: ');#M#J readln(file_name);#M#J~* f:J #.YL (Comment: this is a negative acknowledgement of the above packet) g/D#M#J~& ~$ write('New File Name: ');#M#J~* readln(file_name);#M#J~ f: #.YL (Comment: this is another negative ack) g/D#M#J~& ~$ write('New File Name: ');#M#J~* readln(file_name);#M#J~* f #.YL (Comment: another negative ack) g/D#M#J~& ~$ write('New File Name: ');#M#J~* readln(file_name);#M#J~* f: #/YM (Comment: finally, positive acknowledgement) Excerpt from DCU Report SEQ# = 002f CAPTURE TYPE = INPUT CHARS CAPTURED = 0001 0000 01 (Comment: Start-of-Pkt for good packet) |. | SEQ# = 0030 CAPTURE TYPE = INPUT CHARS CAPTURED = 004a 0000 68 AE C4 E5 67 E9 6E 23 CD 23 4A FE AD 20 F7 F2 |h...g.n#.#J.. ..| 0010 E9 F4 E5 EC 6E A8 5E C7 A7 E9 6E 76 61 EC E9 64 |....n.^...nva..d| 0020 20 E6 E9 EC E5 20 6E 61 6D E5 A7 29 3B 23 CD 23 | .... nam..);#.#| 0030 4A FE AD 20 68 61 EC F4 3B 23 CD 23 4A FE AD 20 |J.. ha..;#.#J.. | 0040 E5 6E 64 3B 23 CD 23 4A B6 0D (Good pkt data) |.nd;#.#J.. | SEQ# = 0031 CAPTURE TYPE = INPUT CHARS CAPTURED = 0001 0000 01 (Comment: Start-of-Pkt for first attempt) |. | SEQ# = 0032 CAPTURE TYPE = INPUT CHARS CAPTURED = 0049 0000 67 2F C4 23 CD 23 4A FE 26 20 FE A4 20 F7 F2 E9 |g/.#.#J.& .. ...| 0010 F4 E5 A8 A7 CE E5 F7 20 46 E9 EC E5 20 CE 61 6D |....... F... .am| 0020 E5 BA 20 A7 29 3B 23 CD 23 4A FE 2A 20 F2 E5 61 |.. .);#.#J.* ..a| 0030 64 EC 6E A8 E6 E9 EC E5 DF 6E 61 6D E5 29 3B 23 |d.n......nam.);#| 0040 CD 23 4A FE 2A 20 E6 BA 0D (Data is good!?!?) |.#J.* ... | SEQ# = 0033 CAPTURE TYPE = INPUT CHARS CAPTURED = 004a 0000 01 67 2F C4 23 CD 23 4A FE 26 20 FE A4 20 F7 F2 |.g/.#.#J.& .. ..| 0010 E9 F4 E5 A8 A7 CE E5 F7 20 46 E9 EC E5 20 CE 61 |........ F... .a| 0020 6D E5 BA 20 A7 29 3B 23 CD 23 4A FE 2A 20 F2 E5 |m.. .);#.#J.* ..| 0030 61 64 EC 6E A8 E6 E9 EC E5 DF 6E 61 6D E5 29 3B |ad.n......nam.);| 0040 23 CD 23 4A FE 2A 20 E6 BA 0D (2nd try: good!?) |#.#J.* ... | SEQ# = 0034 CAPTURE TYPE = INPUT CHARS CAPTURED = 004a 0000 01 67 2F C4 23 CD 23 4A FE 26 20 FE A4 20 F7 F2 |.g/.#.#J.& .. ..| 0010 E9 F4 E5 A8 A7 CE E5 F7 20 46 E9 EC E5 20 CE 61 |........ F... .a| 0020 6D E5 BA 20 A7 29 3B 23 CD 23 4A FE 2A 20 F2 E5 |m.. .);#.#J.* ..| 0030 61 64 EC 6E A8 E6 E9 EC E5 DF 6E 61 6D E5 29 3B |ad.n......nam.);| 0040 23 CD 23 4A FE 2A 20 E6 BA 0D (3rd try: good!?) |#.#J.* ... | SEQ# = 0035 CAPTURE TYPE = INPUT CHARS CAPTURED = 0001 0000 01 (Comment: SOH, 4th try: again note *same* data) |. | SEQ# = 0036 CAPTURE TYPE = INPUT CHARS CAPTURED = 0049 0000 67 2F C4 23 CD 23 4A FE 26 20 FE A4 20 F7 F2 E9 |g/.#.#J.& .. ...| 0010 F4 E5 A8 A7 CE E5 F7 20 46 E9 EC E5 20 CE 61 6D |....... F... .am| 0020 E5 BA 20 A7 29 3B 23 CD 23 4A FE 2A 20 F2 E5 61 |.. .);#.#J.* ..a| 0030 64 EC 6E A8 E6 E9 EC E5 DF 6E 61 6D E5 29 3B 23 |d.n......nam.);#| 0040 CD 23 4A FE 2A 20 E6 BA 0D (C-Kerm now gives + ack) |.#J.* ... | The Discussion Continues Did you catch the bizarre aspect of this problem? The packet log shows that characters are missing from the bad packets. But the DCU report shows that every character that should be there actually *did* make it all the way from the PC through Telenet into the Tower. The full, correct packets are making it to the Tower's tty port *every time*. Note that other tests have shown that (1) data may be missing from anywhere in the packet, not necessarily at the end; (2) the number of consecutive missing characters has been observed to be as high as 5; and (3) on rare occasions *multiple* noncontiguous sequences of one or more characters may be missing. Conclusion: somewhere between the low levels of the tty driver and Kermit, data is disappearing. Beyond this, I cannot speculate. Other pertinent information includes the observations that both direct (i.e., non-Telenet-involved) PC-Tower dial-up and PC-Tower direct connections at 1200 baud do not have any problems uploading or downloading. This tidbit would seem to point the finger at Telenet, and yet the DCU report is solid evidence for Telenet's innocence in the matter. Also, when the PC-Telenet connection is established at 300 baud, the dropped/missing data problem still persists. (I think I can explain this, though, as not being any different than a 1200 baud PC-Telenet connection because the Telenet node at the PC's end only forwards data to the Telenet node at the Tower's end when the `user' (i.e., PC Kermit) types a carriage return (the end-of-packet indicator for Kermit) or pauses for one second in his typing.) Finally, as an aside, I have been able to successfully upload files from the PC to a VAX on Telenet, thereby doubly proving the PC's innocence in this mess. So I am at a loss whether to proclaim Telenet, the Tower operating system, or Kermit as the guilty party. Because the Tower O.S. may be involved, I am also posting this message to UNIX-Wizards Digest (unix-wizards@brl). I apologize for the length of this message, but I figure too much detail is better than too little. I don't know where to go from here, and yet the solution of this problem is imperative if our installation is to make available some promised new services to our user community. Any help that anyone can offer will be GREATLY, GREATLY appreciated. Please send any and all email on this subject directly to me. I will forward all received mail to interested parties and will summarize to Info-Kermit when a solution is achieved. Sincerely, -- Larry Afrin Dept. of Computer Science Clemson University ================================ Please send replies, if any, to: lbafrin@clemson if you're on CSNet lbafrin.clemson@csnet-Relay if you're on ARPANet any reasonable-looking string with if you're on any other net "lbafrin" and "clemson" in it "If the Constitution guarantees free speech, then why do I get a phone bill each month?"