Subject: Re: ARP problems.
To: Eric Haszlakiewicz <firstname.lastname@example.org>
From: None <email@example.com>
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.