Subject: Re: ARP problems.
To: Greg Troxel <email@example.com>
From: Eric Haszlakiewicz <firstname.lastname@example.org>
Date: 03/19/2004 15:10:33
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
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?)