>Number:         925
>Category:       port-amiga
>Synopsis:       Amiga ARCnet drivers send queue might starve
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 29 13:35:02 1995
>Originator:     Ignatios Souvatzis
>Organization:
"	private Internet site"
>Release:        1.0A
>Environment:
	
System: NetBSD beverly 1.0A NetBSD 1.0A (BEVERLY) #41: Mon Mar 27 10:35:09 MET DST 1995 is@beverly:/usr/src/sys/arch/amiga/compile/BEVERLY amiga


>Description:
	If the peer is up and the ARCnet interface running (that is, the token
	is received and passed on), but has no free receive buffers, our send
	queue would actually starve, as the SMC chipset retries the send forever.

	This was discovered after reading and carefully comparing the SMC90C66 
	docs with the three (2 text, 1 flow diagram) in the SMC 90C65 docs.

	SMC claims that the ARCnet protocol state machine is the same for all 
	three chipsets (66, 65 and 26), so this applies to us, too.

	This would potential make a denial of service attack possible (if real
	world ARCnets) were long enough to not be able to find and switch
	off the culprit and bash its owner. :-)

>How-To-Repeat:
	Err...
	configure a PC with ARCnet card using debug, but don't enable the
	receiver. Every NetBSD-Amiga on the same ARCnet, which at some time 
	send a packet to us, will be blocked from sending to the ARCnet. (I
	don't have the equipment at one place to check all this. but in doubt,
	I believe the worst scenario the docs suggest).
>Fix:
	Apply the diffs below to 
	/sys/arch/amiga/dev/if_bah.c, which add a watchdog timer to the
	send code.


94a95,97
> /* for watchdog timer. This should be more than enough. */
> #define ARCTIMEOUT (5*IFNET_SLOWHZ)
> 
181a185
> int bah_watchdog __P((int));
279c283,284
< 	/* might need later: ifp->if_watchdog  = bah_watchdog */
---
> 	ifp->if_timer = 0;
> 	ifp->if_watchdog  = bah_watchdog;
358,360c363,364
< 	printf("bah%ld: reset: card reset, status=0x%02x\n",
< 	    ifp->if_unit,
< 	    sc->sc_base->status);
---
> 	printf("bah%ld: reset: card reset, status = 0x%02x\n",
> 	    ifp->if_unit, sc->sc_base->status);
436a441,443
> 	/* Stop watchdog timer */
> 	sc->sc_arccom.ac_if.if_timer = 0;
> 
675a683
> 		sc->sc_arccom.ac_if.if_timer = ARCTIMEOUT;
687,693d694
< 	/*
< 	 * We dont really need a transmit timeout timer, do we?
< 	 * XXX (sighing deeply) yes, after 10 times reading the docs,
< 	 * I realized that in the case the receiver NAKs the buffer request,
< 	 * the hardware retries till shutdown.
< 	 * TODO: Insert some reasonable transmit timeout timer.
< 	 */
947c948,952
< 	/* XXX insert retransmit code etc. here. For now just: */ 
---
> 	/*
> 	 * XXX insert retransmit code etc. here; and dont forget
> 	 * to not retransmit if this is a timeout int.
> 	 * For now just: 
> 	 */ 
981a987,988
> 		/* init watchdog timer */
> 		sc->sc_arccom.ac_if.if_timer = ARCTIMEOUT;
1000a1008,1009
> 		/* ... and watchdog timer */
> 		sc->sc_arccom.ac_if.if_timer = 0;
1206a1216,1243
> }
> 
> /*
>  * watchdog routine for transmitter.
>  *
>  * We need this, because else a receiver whose hardware is alive, but whose
>  * software has not enabled the Receiver, would make our hardware wait forever
>  * Discovered this after 20 times reading the docs.
>  *
>  * Only thing we do is disable transmitter. We'll get an transmit timeout,
>  * and the int handler will have to decide not to retransmit (in case
>  * retransmission is implemented).
>  *
>  * This one assumes being called inside splimp(), and that imp >= ipl2
>  */
> 
> int
> bah_watchdog(unit)
> int unit;
> {
> 	struct bah_softc *sc;
> 	struct ifnet *ifp;
> 
> 	sc  = bahcd.cd_devs[unit];
> 	ifp = &(sc->sc_arccom.ac_if);
> 
> 	sc->sc_base->command = ARC_TXDIS;
> 	return 0;
>Audit-Trail:
>Unformatted:


Ignatios Souvatzis