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

Sven-Ola Tücke sven-ola
Di Okt 30 20:46:25 CET 2007


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

Mehr Informationen über die Mailingliste Berlin