I have a sticky situation, and hope someone can help me find a solution. The setup is a Dell laptop (Open Suse 11.3) with a wired ethernet (also wireless, but that doesn't seem to be involved with this problem). The laptop serves as a router between the wireless and the wired ethernet. Exactly one device lives on the wired side; an Arm single-board Linux box connected directly through a cross-over cable (it works with a straight cable, too, and I thought that may have exacerbated the problem, but it seems to have been irrelevant). The laptop also serves as a NFS server for the Arm linux box. All that works great.
The problem is that when the Arm box reboots, the wired ethernet link seen by the laptop goes down, and the ethernet loses its IP. The message log says:
This becomes a real problem when the Arm box wants to establish an NFS connection to the laptop. It seems only human intervention will bring the wired ethernet back to life, and by that time the re-boot of the single-board Arm box has stalled. The overall system is intended to run for long periods unattended, and at times in remote locations.
It would be great if the link-down condition would not cause the wired ethernet to lose its IP. I have tried disabling the avahi-daemon, but this does not work either.
The ifcfg-eth0 file for the unruly ethernet looks like:
The problem goes away if I put an ethernet switch between the two devices, but the reason I'm using a laptop is that it supposed to be a highly portable system, and an extra box in the system (including power source and an additional cable) is considered quite undesirable. A software solution is strongly preferred.
Thanks.

--- rod.

1000base-t and most 100Base-t have auto-sense capabilities so a cross over cable is not required anymore. My first guess is that when the ARM box reboots it can not reestablish a link which means the laptop does not have a line either and so the address is withdrawn. Is the ARM box set for auto negotiation? Try configuring both boxes for auto negotiation and see what happens.

Thanks for your response.
It doesn't even get that far. As soon as the Arm board shuts down, the laptop loses its link-up state, and the IP is withdrawn. Also, if the cable is disconnected, even briefly. I have tried enabling/disabling auto-negotiation on both ends, and it hasn't changed anything.
Do you know where the connection is made between the link status and the maintenance of an IP? It doesn't seem that the two should be necessarily tied together? Could the origins of this lie in the ethernet driver? Perhaps a driver argument can fix it? Just spitballing; I will explore that avenue.

--- rod.