[lkml]   [1999]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Arp expire/timeout 2.1.132/2.2pre1
In article <>,
Florian Lohoff <> writes:
> On Sat, Jan 02, 1999 at 03:51:02AM +0100, Andi Kleen wrote:
>> In article <>,
>> (Florian Lohoff) writes:
>> > If you statically hardcode the arp entry via arp -s it works
>> > perfectly. Has recently something changed in the arp state machien etc ?
>> ARP has been completely rewriten. You can configure the ARP timeout using
>> the /proc/sys/net/ipv4/neigh/<interface>/base_reachable_time interface.
>> The problem with tftp is that it is not handled by the kernel. For kernel
>> connection oriented protocols (TCP) the kernel signals forward process for
>> any successfull ack to the neighbouring cache, which will restart the
>> neighbour entry expiry time. The user level tftp code has no way to do this,
>> so the neighbour expires rather quickly.

> Wouldnt this work when:
> - Restart neighbour entry expiry time on receive of an packet which matches
> the correct IP/MAC address pair ?

Only good fix would be to add a new socket command/option that signals
forward process for a specific address to the kernel, and change tftp to use

When the neighbour entry expires the kernel first tries to send an ARP
probe directly to the other end (ucast_solicit). Is your Ultrix box
dumb enough to not answer to these probes?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.071 / U:3.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site