ART@ACC.ARPA (10/27/84)
From: Art Berggreen <ART@ACC.ARPA> Recently several people have remarked on the bug/feature in the 4.2 IMP driver code that only resets per host RFNM counts when a BADLEADER msg from the IMP is seen. Has anyone implemented and TESTED a fix for this? I'd like not to reinvent the wheel if possible. Please send me a note or post to TCP-IP or UNIX_WIZARDS if you have such a fix. Also, did anyone get a definite reading on when the IMP resets its RFNM counters? Art Berggreen <Art@ACC.ARPA> "Too illiterate to have any cute quotes." ------
stanonik@nprdc.ARPA (10/27/84)
In response to our query about rfnm's, Bill Nesheim (cu-arpa.bill@Cornell) provided the following fix which we've installed. RCS file: RCS/if_imp.c,v retrieving revision 1.1 diff -c -r1.1 if_imp.c *** /tmp/,RCSt1017941 Fri Oct 26 11:26:49 1984 --- if_imp.c Fri Sep 21 14:16:42 1984 *************** *** 293,298 */ case IMPTYPE_RESET: impmsg(sc, "interface reset"); impnoops(sc); goto drop; --- 293,299 ----- */ case IMPTYPE_RESET: impmsg(sc, "interface reset"); + hostreset(sc->imp_if.if_net); impnoops(sc); goto drop; He said their rfnm problems disappeared, and now apparently so have ours. Of course, disappearance of the problems isn't quite the same as testing. Hitting the ecu reset button would probably be a good test, if I could think of a way of bumping up the rfnm counts (short of adb'ing /dev/kmem). I never did get a response about when the imp's clear their counts, and I couldn't find that information in bbn's 1822 report. Ron Stanonik stanonik@nprdc
malis@BBNCCS.ARPA (10/27/84)
From: Andrew Malis <malis@BBNCCS.ARPA> Art and Ron, The IMP always resets its RFNM counters under any of the following circumstances: 1. The IMP was restarted by the NOC. 2. The host flapped or dropped its ready line to the IMP. 3. The host went tardy to the IMP, and then recovered. All of these conditions cause the IMP to send NOPs and an Interface Reset to the host, which the host can use as a signal that RFNM counters have been reset. So, the code in Ron's message should do the trick, given that "hostreset()" does the right thing. Section 3.2 of BBN Report 1822 accurately discusses the second and third cases that I list above, but does neglect to mention that the RFNM counters are reset. Andy