How to configure persistent static route on cRIO-9068

[aalexander]

I've developed a protocol to allow auto-negotiatation of network streams using multicast and i've hit a snag (well will be a snag in deployment) in that on boot or reboot, Linux-RT does not automatically create a route for the multicast address.  I've used the following link:

     http://digital.ni.com/public.nsf/allkb/BC971735E7A2A02B86257DE8006D101D

to manually enable multicast by SSHing into the cRIO as admin/superuser and running the command.  This isn't ok for deployment as this code will go to more than one cRIO and i certainly won't be there after every reboot to SSH into each and create a route for multicasting.

I've found the commands that do work, but due to restrictions on su, I can't run them using the sytem exec command from within the labview source. command below:

     su admin -c '/sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0'

with the password in standard input.  I get the error that this command must be used from a terminal/ssh session.

I also attempted to ssh into the cRIO and run a command using the system exec command:

     ssh admin@localhost '/sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0'

which was also unsuccessful. [Pseudo-terminal will not be allocated because stdin is not a terminal. Host key verification failed.]

I also went the linux route trying to add items to the /etc/network/interfaces file, but it doesn't seem to be executing on bootup, or requires some registering or something another? Also looked into this:

     https://decibel.ni.com/content/docs/DOC-38960

which is a bit much to set up a static route.  It feels like an over-engineered solution, but this may be what i fall back on if there are no other time-viable solutions.

Not necessarily at my wits end, but i'd hate to have to rewrite the protocol to use something else other than multicast and is confirmed to be working because i can't automate or create a persistent static route.  Also none of this is specifically accessible via the system configuration as far as i can tell. If anyone has any tips, pointers or solutions, i'd really appreciate it. 

Thanks.

[EM_John]

The address 234.5.6.7 seems to always work without fail for me on the 9066.

[aalexander]

This helps, but this "issue" is (as far as i can tell) specific to the cRIO-9067/9068. I tried a handful of things and found out the following:

I modified the /etc/network/interfaces configuration file and found that the settings ONLY took place if I ran the /etc/init.d/networking restart command. Upon bootup, it seems as either A) the runlevel was executed but was later overwritten (e.g. something NI speicfic is running and overwriting those settings) or B) upon bootup, the OS does not use ifup/down to bring the interfaces up which doesn't make too much sense.  Contents of /etc/network/interfaces is as follows:

auto eth0

iface eth0 inet static

        address 192.168.1.5

        netmask 255.255.255.0

        up route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

If I run the /etc/init.d/networking restart command while logged in as admin/root, the command is run and the route is persistent and the example for UDP multicast will work.

I tried to create an rc script to run on bootup with the runlevel as per https://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian. Doesn't work, i can run it as admin/root and it works fine, can't run it from labview because no root access (access denied). 

I'm very close to considering writing a PC-side script that will ssh into a database of cRIOs on startup and run the command (this defeats the purpose and takes away some of the beauty of using multicast) to bring the interfaces down then up to ensure the routes are put together.

[BradM]

We need to actually remove the /etc/network/interfaces file, you are not the first to get confused by it. It is not used when configuring the networking interfaces, we instead use ifplugd and some scripting to setup interfaces.

You should not be running a RC-style initscript as a user, you instead just need to make sure that the script is enabled to run at a particular priority/runlevel, then root/admin will run the script for you.Checking the actual location of the ifplugd script, starting somewhere after 20 (sysv init systems run lower-sequence numbers first, and we want to run ours after the ifplugd daemon starts) is what you want.

// As admin

admin@NI-cRIO-9068-5-feedface:~# rc-update.d $your_script defaults 25 75

// Break-down:

// rc-update.d $your_script... - You want to modify how the sysv-init system handles $your_script

// ... defaults... - You want to set starting/stopping this script at the normal runlevels

// NOTE: A runlevel is simply a notion of what software you want to be running at a particular time, think of Windows' safemode, safemode w/ networking

// ... 25 75 - Start the script at the runlevels it is set to start on at seqence 25, stop at the runlevel it is set to stop on at sequence 75

For a thorough treatment of what exactly runlevels are and how they are used, I would recommend http://www.tldp.org/LDP/sag/html/run-levels-intro.html

However, I would actually just recommend updating our ifplugd script (located at /etc/natinst/networking/ifplugd.script) to add the route in the "up)" case)

[aalexander]

Edit: saw the rest of your post (or it was updated while i was writing this one). Thanks again! You sir deserve a beer/handshake.

Okay, this is making more sense.  I was able to get a persistent route by adding the line:

         /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0;

to /etc/ifplugd/ifplugd.actions . Is there any disadvantages to this? What would cause this to be overwritten or rather what actions would require me to have to edit this again?

Dump of ifplugd.actions below for those interested:

#!/bin/sh

# Usage: ifplugd.script <interface> <up|down|error> <extraVariableSetWith-xOption>

# Also the following envvars are set:

# IFPLUGD_PREVIOUS=<up|down|error>

# IFPLUGD_CURRENT=<up|down|error>

[ -z "$1" ] && echo "Error: should be called from ifplugd" && exit 1

. /etc/natinst/networking/functions.common

INTERFACE=$1

# If there are drivers that need priorities changed, do it

update_driver_priorities

case "$2" in

   up)

      # On link-up, we're not guaranteed to be on the same network as

      # we were before, so we should reprobe for an address if it's

      # automatically configured.

      if ( is_dhcp_enabled $INTERFACE ); then

         if [ $(get_var section=$INTERFACE,token=dhcpserverenabled) = 1 ]; then

            reload_dhcp_server $INTERFACE;

         else

            # DHCP, or DHCP+LinkLocal

            reload_dhcp_client $INTERFACE;

         fi

      elif ( is_linklocal_enabled $INTERFACE ); then

         # LinkLocal only

         reload_linklocal_client $INTERFACE;

      else

         # static

         start_static_interface $INTERFACE;

         /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0;

      fi

      update_interface_info $INTERFACE

      ;;

   down)

      stop_dhcp_server $INTERFACE;

      stop_dhcp_client $INTERFACE;

      stop_linklocal_client $INTERFACE;

      # We clearly aren't going to be able to do DNS on this interface anymore.

      rm -f /etc/resolv.conf.$INTERFACE

      update_resolv_conf

      update_interface_info $INTERFACE

      ;;

esac

Dump of ifplugd.script below for those interested:

#!/bin/sh

# Usage: ifplugd.script <interface> <up|down|error> <extraVariableSetWith-xOption>

# Also the following envvars are set:

# IFPLUGD_PREVIOUS=<up|down|error>

# IFPLUGD_CURRENT=<up|down|error>

[ -z "$1" ] && echo "Error: should be called from ifplugd" && exit 1

. /etc/natinst/networking/functions.common

INTERFACE=$1

# If there are drivers that need priorities changed, do it

update_driver_priorities

case "$2" in

   up)

      # On link-up, we're not guaranteed to be on the same network as

      # we were before, so we should reprobe for an address if it's

      # automatically configured.

      if ( is_dhcp_enabled $INTERFACE ); then

         if [ $(get_var section=$INTERFACE,token=dhcpserverenabled) = 1 ]; then

            reload_dhcp_server $INTERFACE;

         else

            # DHCP, or DHCP+LinkLocal

            reload_dhcp_client $INTERFACE;

         fi

      elif ( is_linklocal_enabled $INTERFACE ); then

         # LinkLocal only

         reload_linklocal_client $INTERFACE;

      else

         # static

         start_static_interface $INTERFACE;

        /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0;

      fi

      update_interface_info $INTERFACE

      ;;

   down)

      stop_dhcp_server $INTERFACE;

      stop_dhcp_client $INTERFACE;

      stop_linklocal_client $INTERFACE;

      # We clearly aren't going to be able to do DNS on this interface anymore.

      rm -f /etc/resolv.conf.$INTERFACE

      update_resolv_conf

      update_interface_info $INTERFACE

      ;;

esac

[BradM]

aalexander wrote:

...

Okay, this is making more sense.  I was able to get a persistent route by adding the line:

         /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0;

to /etc/ifplugd/ifplugd.actions . Is there any disadvantages to this? What would cause this to be overwritten or rather what actions would require me to have to edit this again?

...

You hit on exactly the one downside: it will be lost anytime there is a reinstallation of the Base OS component from MAX. Of course, any format/reinstall will cause this change to be lost, and if you install a newer version of NI software to your development machine (e.g. a new Compact RIO support install), if you install additional software to the controller (especially if you upgrade the software on the controller or do a Custom Install) will likely lose these changes.

You can do some work to capture this change in an installable component that will shelter you a bit from this stuff, but it's probably more work than it is worth. I'll also make sure that we are internally aware of the issue.

[BradM]

Also, one additional datapoint: what versions of NI software are you using when working with this 9068? LVRT, RIO, any additional software that you've installed to the target to make sure we have a complete picture

[aalexander]

Let me know if this is sufficient, if you need more i can generate a report and send it to you via email.

• NI-cRIO-9067
  • Devices and Interfaces
    • ASRL1::INSTR
    • Network Devices
    • NI cRIO-9067 "RIO0"
  • Software
    • Network Streams 14.0
    • Network Variable Engine 14.0.0
    • NI CompactRIO 14.0.1 - August 2014
      • LabVIEW Real-Time 14.0.0
      • NI System Configuration Remote Support 14.0.0
      • NI-RIO 14.0.1
        • CompactRIO Support 14.0
      • Run-Time Engine for Web Services 14.0.0
      • SSL Support for LabVIEW RT 14.0.0
      • WebDAV Server 14.0.0
    • NI Scan Engine 4.3
    • NI System Configuration 14.0.0
    • NI Web-based Configuration and Monitoring 14.0.0
      • Hardware Configuration Web Support 14.0.0
      • Network Configuration Web Support 14.0.0
      • Time Configuration Web Support 14.0.0
    • NI-Industrial Communications for EtherCAT 14.0
    • NI-RIO IO Scan 14.0.1
    • NI-VISA 14.0.0
    • System State Publisher 3.3.0
    • Variable Client Support for LabVIEW RT 14.0.0

[BradM]

That'd do it, thanks aalexander

[Reddata]

BradM wrote:

...it will be lost anytime there is a reinstallation of the Base OS component from MAX ..., any format/reinstall will cause this change to be lost, ... if you install a newer version of NI software to your development machine (e.g. a new Compact RIO support install), if you install additional software to the controller (especially if you upgrade the software on the controller or do a Custom Install) ...

Is this an exhaustive list of the things that can revert ifplugd.script? Is there anything else that blows it away?

I just lost the route from the ifplugd.script on two of three cRIOs in my system. There has been no change in any of the elements you listed. The unaffected cRIO is a 9068, the other two are a 9033 and a 9039. I was doing development work with LabVIEW at the time this happened (running VIs and building and deploying them), but I've been doing that for months without killing mulitcast.