Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!ucbvax!daemon
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Ether Broadcast Bedlam
Message-ID: <10008@ucbvax.ARPA>
Date: Tue, 20-Aug-85 00:44:55 EDT
Article-I.D.: ucbvax.10008
Posted: Tue Aug 20 00:44:55 1985
Date-Received: Fri, 23-Aug-85 07:43:57 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 46

From: petry@trantor.ARPA (Michael G. Petry)

Since I haven't seen any recent war stories, I'll pass along one that just
attacked our shop.

	The story takes place on a moderately sized ethernet(tm) 
(~50 nodes) at the Univ of Maryland.  Panic struck just after
the gweat (go eat)crowd returned from lunch to find the ether in
a state disaster.  The carrier lights shown bright on our ether
boards, but no traffic was flowing.  Fingers were pointing in all
directions.  A few hours latter fingers stopped on a tucked away
Unix(tm) fileserver/workstation (Host X). The machine had problems
reading the hardware ether address from it's prom.  The software
decided it wanted to be heard and chose FF:FF:FF:FF:FF:FF as its
ether address.  Well imagine what took place when a simple ICMP PING
was attempted on host X by host Y.

	1) Send an ARP request to determine X's ether address
	2) X replys that it is FF:FF:FF:FF:FF:FF
	3) Y sends ICMP ping to X using FF:FF:FF:FF:FF:FF
	4) EVERY host sees the message. The Unix(tm) 4.X hordes decide
		to send an ICMP destination unreachable or
		forward it on to X
	5) EVERY forwarding host then ARPs for host X.
		(Most of our hosts have ipforwarding enabled)
	6) X replys that it is FF:FF:FF:FF:FF:FF
	7) The forwarding hosts then send the message to X using FF ... FF

Need I go any further...........

The first thing to do is get the bloody hardware fixed.  What should
be the second?  Should a host be allowed to ARP reply as the ether
broadcast address?  My first impression is not, since all boards are suppose
to be bound to a unique address.  (maybe its time for a fast hack to
disallow FF .. FF in if_ether.c)  As an exercise think what happens
if ipforwarding is off.  The scenario is mildy better.

Is this what is meant by radiation tolerant components?

P.S.	Thanks to Interlan for having activity lights on boards.
		(It WASN'T their board that was broken)
	Thanks to John Romkey and friends for writting the PC/IP Netwatch
		program. (finally a good use for a PC)

Mike Petry
UOM Computer Science Center