[En-Nut-Discussion] ARP Problem, Again

[Harald Kipp]

Hi all,

This was indeed a nice problem to study.

A Nut/OS node is directly connected to notebook. The notebook
is running Windows and the Ethernet link is down, because
the Nut/OS node is switched off.

When switching on the embedded system, the Ethernet link
will be negotiated by both systems.

As soon as the interface is up again, Windows sends out 3 ARP
requests with its own IP in order to make sure, that this
is not used by any other node. During this time, it doesn't
respond to ARP requests from other nodes.

Without DHCP, SNTP or any other UDP protocol, the Nut/OS
application will immediately try to connect to a server
on the notebook. However, the failed ARP request (Windows is
still busy with gratuitous ARP) results in 10064 (Host down).

Early Nut/OS releases send out several ARP requests before
giving up. This had been changed in order to follow the
RFCs and in the hope, that upper layers will handle the
problem. BUT, the IP layer reports back a transmit error
and TCP thinks: "OK, a transmit error is something fatal,
so better give up immediately."

The fix is, that the IP layer should not report failed
ARP requests as errors. It's similar to lost packets
and definitely no transmit error. Transmit errors are
major problems like hardware problems or running out of
memory.

http://www.ethernut.de/arc/?M=D
contains a file named ip-arp-fix.zip.

Regards,

Harald