[Berlin-wireless] Does the arp-refresh plugin works correctly ?

[Sven-Ola Tücke]

G'evening,

that's an implmentation problem. The task for refreshing those ARP entries has 
a very low priority. My fault. I presumed this works with such a low prio, 
but obviously that needs more prio/CPU time to work reliable for all neighs. 
Better start slow was the idea...

// Sven-Ola

Am Dienstag 30 Oktober 2007 19:48:02 schrieb Bluse:
> Hello Freifunkers,
>
> We guessed that the task of the arprefresh-plugin is to update the
> arp-cache of a node with it´s real 1-hop neighbors, so that it is
> unnecessary to arp request them - they are already known. This idea should
> speed up the ip resolution.
>
> But:
> We observed the following:
>  If you check the current arp-cache  of a node with:"ip -s neigh" you will
> see that there a even good olsr-1-hop-heighbors in the state:"nud stale"
> and some other in the state:"reachable" or "delayed".
>
>  The problem is the state "stale":
>  "stale -- the neighbour is valid, but is probably already unreachable, so
> the kernel will try to check it at the first transmission."
>
> So this will lead to an unnecessary Arp-refresh even if this is a good
> neighbor. We do not know if this is a bug in the arp-refresh plugin, maybe
> fixable with static arp settings. Or if this is regarding the kernel.
>
> Any hints ?
>
>  Bye Basti & Bluse