Ignoring ARP; arpresolve: can't allocate llinfo

["Michael Lee Crogan" <michael_(_dot_)_l_(_dot_)_crogan_(_dot_)_1_(_at_)_purdue_(_dot_)_edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I run behind a very limited firewall where the only host with which I am
interested in communicating on our direct network is the default
gateway.  I know its MAC address, and I have placed a static entry for
it so that it is immutable.  However, even though I can filter many
types of IP packets, I find that my kernel routing table has almost a
hundred of entries which are due to ARP messages.  They are dynamically
created and just map IP to and from the MAC address.

The question is, since I only need to communicate through one host on
the network (our gateway) and all others are filtered out via ipf, is
there any way to prevent the automatic addition of these mappings to the
`netstat -arn' output?  They fill up fairly quickly and are spurious.
Furthermore, I am also getting about 200 kernel messages every 10
minutes of the form:

  /bsd: arpresolve: can't allocate llinfo

I am running `stable' on an i386.  The adapter is Intel Etherexpress Pro
10/100.  I took a preliminary step in debugging to find that in
`sys/netinet/if_ether.c', the `arplookup' command is being invoked, and
its return value is NULL.  However I have not had the time to debug
further (i.e. where in `arplookup' the return of NULL is occuring).  Is
there any obvious explanation for so many kernel messages of this type?
I can `filter' the messages (by commenting out the kernel print from
source) but still I would like to address the source of the problem.
Any ideas on how this might be tracked down?

        if (rt)
                la = (struct llinfo_arp *)rt->rt_llinfo;
        else {
                if ((la = arplookup(SIN(dst)->sin_addr.s_addr, 1, 0)) != NULL)
                        rt = la->la_rt;
        }

Michael Lee Crogan -- <mcrogan_(_at_)_purdue_(_dot_)_edu> -- Purdue University

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)

iD8DBQE529JeIw2dkfh5sRQRAneqAJ43uGdm4yP+EJUhk+fodTjMNF6aQwCeIdFX
x26bx0Ri6Z/i+KGyWKp3TRg=
=3nha
-----END PGP SIGNATURE-----