Fallback to last known IP if DHCP fails

[Mads]

Currently many controllers from NI only have one way to deal with a failure to contact a DHCP server - they will try to use a link local address (APIPA). If this too fails (due to Proxy ARP e.g.) the controller will not even start the RT Application (which might have other tasks to do regardless of the lack of netorking and/or might run code that will remedy the IP problem), but go into Safe Mode. This in itself is bad enough and should be changed to allow the application to be run, however the main request / idea I have will fix this indirectly:

- It should be an option to not fall back to APIPA, but to use the last known configuration (as long as the lease time is still valid). If the DHCP server is down the controller will have the IP-configuration it received the last time the server was up, and will use that configuration.

[Texas_Diaz]

What happens in the case where there has never been a DHCP server present, or if the lease time has expired?  What IP Address should the system then use?

[Mads]

Basically it should behave as close to how other units with this capability does as possible. Intuitively I would say that it should behave the same way it does when you set the IP reset switch:  go to 0.0.0.0. 

It would be nice to have some options; e.g. the ability to define (also programmatically) a fallback to a static configuration (other than a pseudo-random link local address), but it is important that the behaviour is highly flexible/configurable. That way if someone has a very specific request we can still deliver.

Our main case for this is a newly developed sensor system for subsea use. It might become a standard for subsea instrumentation (defined by SIIS) that DHCP must be supported  with fallback to the last known IP (to ensure continued operation if the DHCP server goes offline. DHCP is used instead of static addressing due to the complexity of managing static addresses on what can be a very wide range of devices), and then we have to adhere to that standard. We currently support this behaviour in a non-ideal way by using the RT application to override any fallback to link local, but that fallback in itself is causing us problems (including the critical fault of not starting the RT app that is supposed to override the in-built behaviour among other things), and it has other negative effects like long system initialization time etc.