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 disguiseDate: 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