stanonik@nprdc.ARPA (09/22/84)
According to the bbn 1822 report, after the imp sends a RESET, it should respond to the first message with a BADLEADER. So berkeley's expectation of a BADLEADER seems in accordance with the report. Why they chose to wait for the BADLEADER before clearing rfnm's beats me. Why we don't see a BADLEADER beats me too, and makes it necessary for us to reboot to clear the rfnm counts. The report doesn't seem to mention when the imp clears its rfnm counts. I guess we'll assume on RESET. Thanks, Ron stanonik@nprdc
stanonik@nprdc.ARPA (09/27/84)
We have a problem with rfnm counts in 4.2bsd going to 8 during line problems (between our ecu and the imp's ecu) and then never coming down. We are not overriding ecu generated reset. We get the IMPTYPE_RESET message (logged on our console as "interface reset"), but we don't seem to get the IMPTYPE_BADLEADER message (should log on our console as "leader error") which 4.2bsd uses to hostreset, clearing the rfnm counts. Even more puzzling is that manually reseting the ecu doesn't clear the rfnm counts. Again we get the RESET, but not the BADLEADER, so no hostreset. Any ideas? Maybe the imp's not sending BADLEADER? Have any 4.2bsd sites observed BADLEADER in repsonse to manually reseting the ecu? (As an aside, can anyone tell me where the bbn 1822 report specifies when the imp clears it rfnm counts?) Thanks, Ron Stanonik stanonik@nprdc
MRC@SU-SCORE.ARPA (09/27/84)
From: Mark Crispin <MRC@SU-SCORE.ARPA> It is a horrible idea to test for bad leader. Interface reset should always be used as the condition to "reset everything". My old NCP code for WAITS ignored all messages from the IMP after IMP Ready cycled down until it got an Interface Reset. If it failed to get the Interface Reset within 10 (or was it 30?) seconds after IMP Ready/Host Ready were up, it dropped Host Ready, held it down a few seconds, then tried again. In general, this worked quite well. -------