lkml.org 
[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
From
Date
In article <19990102173219.C32627@mini.gt.owl.de>,
Florian Lohoff <flo@rfc822.org> writes:
> On Sat, Jan 02, 1999 at 03:51:02AM +0100, Andi Kleen wrote:
>> In article <19990101180821.B19906@mini.gt.owl.de>,
>> flo@rfc822.org (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
that.

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?

-Andi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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