NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to self-reboot when the device has no IP?

I have an RT-application running on a Linux RT target with both netwrok interfaces set to DHCP only (no link local fallback) where the application should:

a) be able to start and run normally even though none of the network connections are up

b) restart the target (itself) in this offline state

Now, the good news is that it seems that requirement a is fulfilled. Even though none of the network interfaces get an IP, the RT application still runs as it should. However, it is not able to restart itself if the network interfaces are in such a state.

I am using the System Configuration API's Restart function. It works fine if one of the network interfaces are up, both if I'm using a session input constant to the reboot function set to localhost, or if I use the init function to get a session. Is this because in either case it will try to point the command to "locahost", and with no network up - the command will fail to connect to localhost?

If that is so, is there a different approach that will work (using the API, or do I need to use system exec perhaps)?

The old RT API had a Restart "Self" command, but that's not available anymore.

0 Kudos
Message 1 of 14
(6,994 Views)

Is this because in either case it will try to point the command to "locahost", and with no network up - the command will fail to connect to localhost? 

Yep, you are correct the System Configuration reboot command implementation relies on a connection to localhost. I'm going to file an internal bug report so we can fix this. In the meantime, you can use a system exec VI and call the '/sbin/reboot' command from your application.

__________________
Daniel Jaramillo
National Instruments
Message 2 of 14
(5,314 Views)

@DJaramillo: Just to be clear, lvuser has enough privilege to reboot the device?  Isn't that a rather significant security vulnerability?  Is there a list somewhere of what lvuser can and can not do?  Thanks for your response on this.

0 Kudos
Message 3 of 14
(5,314 Views)

LabVIEW RT's elevated capabilities are:

CAP_SYS_RAWIO,CAP_NET_BIND_SERVICE,CAP_SYS_BOOT,CAP_SYS_NICE,CAP_IPC_LOCK,CAP_SYS_TIME

Capabilities grant processes privileges which can definitely affect security. See http://man7.org/linux/man-pages/man7/capabilities.7.html for details.

These are listed in the LVRT post-install script, I'm not sure they're documented elsewhere. I'll see about getting a doc created on the community for this information.

Message 4 of 14
(5,314 Views)

Thanks for the quick response @ScotSalmon!

0 Kudos
Message 5 of 14
(5,314 Views)

Is it possible for us to edit the list of capabilities given to the lvuser?

I'm just thinking that if the lvuser had CAP_NET_ADMIN I could resolve the ARP issue described here, by getting access to ip link commands(?)

0 Kudos