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: <10018@ucbvax.ARPA>
Date: Tue, 20-Aug-85 15:04:25 EDT
Article-I.D.: ucbvax.10018
Posted: Tue Aug 20 15:04:25 1985
Date-Received: Fri, 23-Aug-85 08:35:58 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 31

From: David C. Plummer in disguise 

    Date: Mon, 19 Aug 85 23:30:25 EDT
    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 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.

I've seen this kind of story before.  Maybe it was only in-house and
didn't get out into the big-wide-world.  The solution is to ignore ARP
packets from people claiming to have any form of multicast hardware
address (and that includes broadcast).  You still need a low level
netwatch program to realize somebody is trying to confuse the world.

    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