11-Dec-84 11:18:23-EST,2323;000000000001
Return-Path: <EIBEN@DEC-MARLBORO.ARPA>
Received: from columbia.arpa (CU-GARFIELD.ARPA.#Internet) by CU20B.ARPA with TCP; Tue 11 Dec 84 11:18:20-EST
Received: from DEC-MARLBORO.ARPA (dec-marlboro.arpa.ARPA) by columbia.arpa; Tue, 11 Dec 84 11:16:10 est
Date: 11 Dec 1984 1114-EST
From: B.Eiben LCG Ext 617-467-4431 <EIBEN%DEC-MARLBORO@columbia.arpa>
To: sy.fdc@cu20b
Subject: [LCG.KERMIT: CP4ROBIN-KERMIT dies after receiving 16k.]
Message-Id: <"MS10(2124)-1+GLXLIB1(1135)" 12070597967.39.249.17048 at DEC-MARLBORO>

--via DECUS --
- - - - - - - Begin message from: LCG.KERMIT
Date: 11 Dec 1984 0251-EST
From: LCG.KERMIT
To: EIBEN
Subject: CP4ROBIN-KERMIT dies after receiving 16k.

To Charles Carvalho:
The fact that version 4.03 of CPM KERMIT does not flush the serial line input
buffer is not just a deficiency.  For a VT180 "Robin" with ZCPR2, it is a
serious bug that causes an infinite NAK loop.  It only shows up when 2 packets
are received during the time it takes the VT180 to write 16K to the disk.
When it does, the lights on the modem show the receive line continuously active
with NAKs being tranmitted every 80 bytes or so.  The only way to stop it is
to press the NO-SCROLL key, and wait for the BIOS to hang on the XOFF when
KERMIT updates the screen.  At this point, the modem lights show no activity.
Wait until the modem lights show that KERMIT-20 has sent another packet before
pressing the NO-SCROLL key again.  Only then is the protocol re-established.

BUG:	Applicable to all KERMITS
NAKs and packets cross in transmission, protocol never resynchronizes.

CURE:
1) Always empty the input buffer and wait for the serial line to become idle
   for at least 1 second before tranmitting any NAK packet.
2) Keep track of the status of the last 8 packets.  If 4 or more of them got
   NAKed, protocol has been seriously disrupted.  When this occurs, pause
   10 seconds and clear input buffer before sending next packet.

This problem is reproducible on my system, and results in KERMIT-20 sending
each packet twice - every other one is NAKed because Robin KERMIT-80 gets
out-of-sync with respect to the interrupt level input buffer.

Joe Smith, CSM Computing Center, Golden, CO 80401  (303)273-3448.
   ========
- - - - - - - End forwarded message
   --------
11-Dec-84 11:38:56-EST,807;000000000001
Return-Path: <EIBEN@DEC-MARLBORO.ARPA>
Received: from columbia.arpa (CU-GARFIELD.ARPA.#Internet) by CU20B.ARPA with TCP; Tue 11 Dec 84 11:38:46-EST
Received: from DEC-MARLBORO.ARPA (dec-marlboro.arpa.ARPA) by columbia.arpa; Tue, 11 Dec 84 11:36:19 est
Date: 11 Dec 1984 1137-EST
From: B.Eiben LCG Ext 617-467-4431 <EIBEN%DEC-MARLBORO@columbia.arpa>
To: SY.FDC@CU20B
Subject: Re: How did MS-Kermit 2.27 work out?
Message-Id: <"MS10(2124)-1+GLXLIB1(1135)" 12070602066.39.249.38812 at DEC-MARLBORO>
Regarding: Message from Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
              of 11-Dec-84 1133-EST

I think (in all the excitement) , I sent You a msg - BREAK works ..
regarding CP4, the "fast patch" is to go down to 8k buffering, the long-term
is obviously clearing the buffer..
   --------
