Need Help on Tower Kermit/Telenet problem (long, sorry)
Larry Afrin
lbafrin%clemson.csnet at CSNET-RELAY.ARPA
Wed Sep 4 19:38:17 AEST 1985
[Also posted to Info-Kermit at 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 at 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 at 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 at 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 at clemson if you're on CSNet
lbafrin.clemson at 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?"
More information about the Comp.unix.wizards
mailing list