[net.unix-wizards] 4.2 RFNM count problem

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