From owner-freebsd-hackers  Wed May 24 11:06:48 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id LAA19343
          for hackers-outgoing; Wed, 24 May 1995 11:06:48 -0700
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA19337
          for <freebsd-hackers@freebsd.org>; Wed, 24 May 1995 11:06:47 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14451(3)>; Wed, 24 May 1995 11:06:05 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <49871>; Wed, 24 May 1995 11:05:48 -0700
X-Mailer: exmh version 1.6 4/21/95
To: Thomas Graichen <graichen@sirius.physik.fu-berlin.de>
cc: freebsd-hackers@FreeBSD.org
Subject: Re: more about: "arp info overwritten" problem 
In-reply-to: Your message of "Wed, 24 May 95 00:18:16 PDT."
             <9505240718.AA03965@sirius.physik.fu-berlin.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 24 May 1995 11:05:46 PDT
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <95May24.110548pdt.49871@crevenia.parc.xerox.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

In message <9505240718.AA03965@sirius.physik.fu-berlin.de> you write:
>>> No, it's because some stupid machine on your network is arping for the
>>> broadcast address.

Sending arp requests for the broadcast address will not cause this behavior.  
Someone sent an ARP packet with a "Sender IP address" of the broadcast 
address, which could either be an ARP request coming from a host who thinks 
that its IP address is the broadcast address, or an ARP reply for the IP 
broadcast address.
(it's a pretty easy bug to write...) 

>that he can't exclude that some machines are arping for the broadcast address
>but he also said that should not disturd FreeBSD - a broadcast address should
>never come into an arp-table - it's the thing for FreeBSD to make sure that
>this might never happen

FreeBSD does not discard any ARP traffic that it recieves.  There is no reason 
to compare for the broadcast address because there shouldn't be any ARP 
traffic for the broadcast address. 

>he also said it might be that FreeBSD has problems with that if the broadcast
>entry can be resolved by the nameserver

Nope, that only has to do with how the user-level "arp" program displays the 
data; it has nothing to do with how the kernel processes ARP requests.

I know you said that you can't run tcpdump on your machine; is there another 
machine somewhere else that you can snoop on the network with?  This would be 
a *lot* easier to figure out if we could see who was arp'ing for what.

>p.s.: yesterday i got the following message - what does that mean ?
>
>/vmunix: arp: ether address is broadcast for IP address 130.133.3.193!

That means that 130.133.3.193 sent out either an ARP Request, or an ARP Reply 
to one of your requests, saying that its ethernet address was 
ff:ff:ff:ff:ff:ff .  Understandably, FreeBSD doesn't really want to insert the 
ethernet broadcast address into its ARP table, so it prints that message 
instead.

  Bill