Subject: Re: ARP problems.
To: Eric Haszlakiewicz <erh@nimenees.com>
From: None <ragge@ludd.luth.se>
List: tech-net
Date: 03/20/2004 14:14:54
> On Fri, Mar 19, 2004 at 01:48:15PM -0500, Greg Troxel wrote:
> > The proposed solution sounds nice from a functionality point of view.
> > One could have some slowtimeout hook that walked the arp table and
> > sent requests for anything that is close to expiring, in order to
> > avoid adding any per-packet processing.
> > This is in fact exactly how racoon gets replacement SAs for ones that
> > are about to expire (due to soft timer expiration, rather than walking
> > the table, but it's semantically identical) and have been used.
> > 
> > So this could be 'option ARP_PROACTION', to avoid compiling in the
> > code for those that don't need it.  That might even keep everybody
> > happy...
> 	ugh.. why bother.  This is change is basically adding something like this:
> if (rt->rt_expire && rt->rt_expire <= (time.tv_sec + ARP_REFRESH_PRETIME))
> 	send arp request
> to the arptimer() function, which I believe _is_ triggered due by a soft
> timer.  Even if you're going to look up the routing entry activity it doesn't
> seem like enough code to warrant an option to choose it.  (why would you
> turn it off?)
> 
Exactly my point.  The only difference to the example above is that 
it should check against the time of last sent packet instead of rt_expire,
in your example even unused arp entries would be refreshed.

-- Ragge