ARP Request, superfluous according to RFC?

Hi,

I have a question about the ARP mechanism in Linux systems, which seems to
use superfluous ARP Requests, contradicting RFC 826
(http://www.faqs.org/rfcs/rfc826.html).

From that RFC I deduced that when an ARP Request is made to a specific host
(the target host),

that target host not only replies with an ARP Reply, but also uses the
hardware and IP address from the source host to update it's own ARP cache.
This ensures that the target is able to communicate with

the source host, without sending an extra ARP Request. Such an extra ARP
Request would thus be superfluous.

I tried this out in my home network, consisting of a Mandrake 9.0 (the
client, IP=192.168.0.105) and a Debian 3.0 (the server, IP=192.168.0.104)
system.

I verified that the ARP caches on both systems were empty (arp -a),
whereafter I sent an ICMP echo request from the client to the server. In the
meanwhile, I sniffed the network using Ethereal on a third host.

I expected the client to send out an ARP Request to resolve the hardware
address of the server, and that happened indeed.

I also expected that the server wouldnt send out an ARP Request to resolve
the hardware address of the client, because he already could have fetched
that from the ARP Request from the client earlier. Such an ARP Request would
therefore be superfluous.

This also seemed the case. The ping succeeded, with only one ARP Request
sent.

But, after sniffing a few seconds (about 4) longer, I noticed that the
server DOES send its own ARP Request to the client, albeit with some
delay...

Other tests gave the same results.

The entire Ethereal dump is printed below.

Now my question arises: why does the server still sends out an ARP Request,
if he could have fetched the necessary info earlier from the ARP Request of
the client? And are those "4seconds" a delay, introduced by bad capturing by
Ethereal, or is this some predefined value?

Some comments on this would be greatly appreciated,

Kristof

**************************ethereal dump************************************

No. Time Source Destination Protocol Info

1 0.000000 00:0c:29:95:58:d1 ff:ff:ff:ff:ff:ff ARP Who has 192.168.0.104?
Tell 192.168.0.105

2 0.004513 00:0c:29:ae:6a:25 00:0c:29:95:58:d1 ARP 192.168.0.104 is at
00:0c:29:ae:6a:25

3 0.004517 192.168.0.105 192.168.0.104 ICMP Echo (ping) request

4 0.029150 192.168.0.104 192.168.0.105 ICMP Echo (ping) reply

5 4.560555 00:0c:29:ae:6a:25 00:0c:29:95:58:d1 ARP Who has 192.168.0.105?
Tell 192.168.0.104

6 4.560559 00:0c:29:95:58:d1 00:0c:29:ae:6a:25 ARP 192.168.0.105 is at
00:0c:29:95:58:d1

***********************end dump*****************************************

Never mind, a little more research after posting this question provided me
the answer:

it seems that linux systems wanna verify whether the information they fetch
from ARP Request is still valid.

They do so by "probing", and the first probe is send after a value
delay_first_probe_time (in /proc/sys/net/ipv4/neigh/*/), which seems to
default to "5".

Grtz,

Kristof