On Tue, Jun 10, 2003 at 12:55:58PM +0900, Takahiro Kambe wrote:
> In message <20030610015920.149B789@coconut.itojun.org>
> 	on Tue, 10 Jun 2003 10:59:20 +0900,
> 	itojun@iijlab.net wrote:
> > >Do a 'netstat -sfarp' on a network with a lot
> > >of arp traffic and notice the large count of
> > >'failures to allocate llinfo'.  arplookup()
> > >shouldn't be incrementing arpstat.as_allocfail++
> > >if creation wasn't specified.  Here's a suggested
> > >diff:
> > 
> > 	i don't see why the diff helps the above situation.  are there any
> > 	other conditions to consider?

Please look again.  If an entry is found and none of the
criteria that were previously were to set 'why' are satisfied,
it is now returned early.  If create is not set, the entire
block of calculating 'why' and incrementing arpstat.as_allocfail
is now skipped and 0 is returned.

> My analysis with much corner-cutting, here is minimum patch for
> stopping "failures to allocate llinfo" count.
> 
> --- if_arp.c.orig	2003-03-01 16:21:05.000000000 +0900
> +++ if_arp.c	2003-06-10 12:50:05.000000000 +0900
> @@ -1165,7 +1165,8 @@ arplookup(m, addr, create, proxy)
>  	if (rt->rt_flags & RTF_GATEWAY)
>  		why = "host is not on local network";
>  	else if ((rt->rt_flags & RTF_LLINFO) == 0) {
> -		arpstat.as_allocfail++;
> +		if (create)
> +			arpstat.as_allocfail++;
>  		why = "could not allocate llinfo";
>  	} else if (rt->rt_gateway->sa_family != AF_LINK)
>  		why = "gateway route is not ours";

This will work too but still goes through the unnecessary, and low
runner, work of setting 'why'.

> 
> 
> BTW, I found that arpstat.as_allocfail is incremented in arpresolve()
> after calling arplookup(), too.  Dosen't it cause double counting
> arplookup() error?
> 
> -- 
> Takahiro Kambe <taca@back-street.net>
>