NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DHCP with fallback to last known address / automated address handling on LinuxRT

In short:
How can we configure a LinuxRT device so that if the DHCP client does not get contact with a DHCP server, the OS will revert back to a static IP (which we then want to dynamically set to be whatever the DHCP client received on the last successful communication with a DHCP server)?This is a required behaviour for SIIS Level 3 devices.

This link points to the closest answer I've found on Linux-forums...(and if that was the whole answer we would need to add code somewhere to change the static addresses whenever the DHCP client is able to get a new address...). But (how) does the LabVIEW RTE intefere with the IP setup? Perhaps we will need to do multiple changes to get this to run properly? Based on my preliminary tests it is not enough for example to define this in the interfaces file...

The longer story:
On VxWorks / cFP-2220 it was difficult but doable to achieved this kind of fallback behaviour; we used the System Configuration API in the LV startup application to always revert back to DHCP, then check if DHCP had failed, and if it did the target would reconfigure itself to static with the last known IP and reboot. This had several negative side-effects; 1.  the startup time would be several minutes due to the need for several reboots - and the fact that the application was doing the job, so it had to start, 2. if the dhcp client failed the target would unwantedly temporarily fall back to APIPA/a link local address, 3. once the device was set to static the only way to get the dhcp client up to do a retry would be to restart the whole target...and finally we had no control over the timing of the DHCP client.

I believe and hope that we can remove many of the problems we had with the cFP-2220/VxWorks based solution now that we have LinuxRT. We should be able to handle the whole logic *outside* the startup application (without needing to start the app), it should be possible to speed it up significantly, and we should have better control over how the process is done / DHCP timing etc. But to do this we need to learn a bit more about Linux, LinuxRT...and how it all is tied together with the LabVIEW RTE. Hopefully we can use startup scripts to do the whole thing (including saving the last known IP to the static option in the config). Another alternative perhaps would be to rewrite the dhcp client itself...but then you run into the problem of always having to ensure that we have replaced the default client...and it is not so tempting to fiddle with the standard client when it comes to future maintenance etc. either...

0 Kudos
Message 1 of 2
(3,970 Views)

Off the top of my head, untested etc., what if you change the "leasefail" case in /etc/natinst/networking/udhcpc.script? You should be able to disable the link-local address through our normal tools (that is, switch from "DHCP or Link Local" to "DHCP only" in MAX/WIF). Then that leasefail case will do nothing and leave you with, I think, 0.0.0.0. You can then put in whatever code you want to run instead, I guess something like "/sbin/ifconfig $interface up $(uboot_var_for_interface dhcpipaddr $interface)" to get the previously saved IP address from our config file (we store it so we can request it from the DHCP server).

Message 2 of 2
(3,314 Views)