cRIO 9068 cannot receive UDP multicast

[Reddata]

Nice find on the multicast address registry: might be handy later.  Unfortunately, changing the multicast address to use organization-local scope did not resolve the issue.

Combining the receiving and sending loops into one VI was a great troubleshooting idea.  However, the receiver still refuses to see anything, despite tcpdump showing the packets merrily arriving at the interface regardless of multicast address usage.

As I've mentioned before, I can't duplicate your snippet exactly.  If I leave the net address unwired (see attached image) I get the mysterious error 42.

[sassyaspy]

Hello reddata,

There are a couple of settings to check on your cRIO. First, we should make sure that the Linux kernel on the cRIO-9068 has been compiled with multicast support. To do so, enable the secure shell server on the device from NI MAX and create an SSH connection to the device's IP address at port 22 (can use a program such as PuTTY). Log in to the cRIO (by default the username should be admin with a blank password) and then enter "ifconfig eth0" to show the settings on your primary ethernet port. Make sure that the device reports that it is "RUNNING MULTICAST".

If that seems to be correct, we can verify that when you run the example you are in fact subscribing to a multicast group. Try using the "cat /proc/net/igmp" command to list the groups you are in before and after you begin running the example, and compare to see if a group is added when the Receiver.vi is deployed to the cRIO.

A final thing that would be beneficial to test is, if you haven't already done so, try removing the etherCAT chassis from the system, disable the eth1 port from MAX, and make sure the ethernet cable connecting the device to the network switch is plugged into port 1 (eth0). It might be a long shot, but because of the behavior concerning the "net address" input to the UDP Multicast Open.vi I think it might be worth trying. Linux RT systems will always scan all network addresses and not just the ports that are specified by the "net address" input: http://digital.ni.com/public.nsf/allkb/640C2C0485AD6B8386257A2A005AD085?OpenDocument

Thanks,

[Reddata]

1. Running ifconfig eth0 shows that the interface is RUNNING MULTICAST.
2. I can confirm that a new group is added when I begin running the example.
3. The etherCAT chassis has been removed (physically and in software) since I reformatted my cRIO some days prior.  I also removed the Industrial Communications for EtherCAT driver from the cRIO.

This post seemed to be addressing similar problem to mine: forums.ni.com/t5/LabVIEW/Problems-with-multicast-UDP-not-putting-NIC-in-promiscuous-mode.  However, I've tried manually placing the interface in promiscuous mode with ifconfig eth0 promisc.

These steps would help discover problems if I wasn't receiving any UDP packets at all, but since tcpdump and my sniffer successfully read the packets, I doubt the network configuration is to blame.

[Reddata]

New information: I got the example to work on a DHCP network (unwired net address with no Error 42), but the error comes back as soon as I revert to a static network.  I was also able to reproduce the error on a separate cRIO 9068 running different software versions.

In trying to reproduce this error, do you have a cRIO 9068 on a static network?  You asked about this earlier.

[Reddata]

For anyone visiting this thread in the future: NI contacted me out-of-band from this forum about this issue, and the resolution led to the creation of this knowledge base article a few days later: http://digital.ni.com/public.nsf/allkb/BC971735E7A2A02B86257DE8006D101D

That was LabVIEW 2013. LabVIEW 2014 obsoletes that approach. Between those versions NI moved away from using /etc/network/interfaces to configure the NICs, instead using their own /etc/natinst/networking/ifplugd.script startup script. This means that the fix needs to be added to the #static section under the "up" case of  that script (as detailed here: https://decibel.ni.com/content/message/106961).

I have no data on whether this has broken again in LV2015, and who knows what 2016 will bring. NI will eventually fix this I'm sure.

Please join me in a moment of silence for the thousands of man hours that will be spent by LabVIEW users researching and fixing this esoteric issue. Repeatedly, in the worst cases.

[ibberger]

sorry for digging out this old thread.

I had the same issues, using a cRIO 9067 with LabVIEW 2015SP1 (RealTime).

I had to catch an UDP broadcast from a device, but my Code - working good otherwise, e.g. from an RT-Device to Windows - didn't work. I knew the UDP packets were there (catched them with a sniffer ...), but the UDP-Read Node refused to read anything.

The solution was to remove the wire from the "net address" input of the UDP open node.

As the cRIO-9067 has 2 ethernet ports, I wanted to make sure it listens on eth0 for incoming packets, not on eth1 (which was not in use, but configured as "DHCP / Link Local").

As the entered IP-Address is "auto generated", it's sure, it's the correct IP-Address.

Maybe this is a Bug in the "UDP Open" node?

[MrJackHamilton]

ib,

Let me add to this, that Having Dual ethernet on the cRIO and you PC receiving the data requires extra steps to assure UDP connection.

1. You MUST on both the cRIO and the PC specifiy by wiring in the Physical IP address of the ethernet adapter physically connected between the cRIO and the PC. PC's on wifi have 2 ethernet adapters ;).

See wiring screen shot, see attached VI.

2. Of course, you NEED TO TURN OF THE WINDOWS FIREWALL!!!!. Just Turn it completely OFF, get cute later about 'modifying' the Firewall rules...once you get it working.

Regards

Jack Hamillton