cRIO 9068 cannot receive UDP multicast

[Reddata]

I want my cRIO 9068 to receive UDP multicast packets from my computer.  I'm using the UDP Multicast example project included with LabVIEW.

The example works when I place the Sender VI on my cRIO and run the Receiver VI on my computer.  However, the reverse situation (Sender VI on my computer, Receiver VI on cRIO) does not work: the Receiver VI repeatedly times out without receiving any data.  For both situations I altered the net address appropriately as described in this thread: forums.ni.com/t5/LabVIEW/needed-software-packages-on-cRIO-for-Multicast-UDP.

I pilfered code for a simple UDP multicast packet sniffer from the internet and ran it on the cRIO.  It works fine when I run the Sender VI on my computer.  This means the packets are arriving at the cRIO; the problem is in LabVIEW.

What do I need to change for LabVIEW to receive the UPD multicast packets on the cRIO?

[sassyaspy]

Hello Reddata,

I was able to run the Receiver VI interactively on a cRIO-9068 (and the Sender VI on my computer) without making any changes to the example, and could not reproduce the timeout error you have been seeing. Can you try again with the original example, leaving the IP address and port configuration, to see if that works for your system? 

[Reddata]

Thanks for replying.

I had tried that before.

It resulted in Error 42 from the Mulitcast Open VI call in the Receiver VI.  This is why I altered the net address as mentioned in the thread (forums.ni.com/t5/LabVIEW/needed-software-packages-on-cRIO-for-Multicast-UDP/).  Altering the address resolved the error 42 message, but no packets are received.

I tried it again this morning for the same effect.

Perhaps I should mention that my cRIO also has a slave 9144 chassis attached.  I tried removing the slave and changing the slave's port (eth1) from "etherCAT" to "disabled," but the unmodified Reciever VI still throws error 42, and my modified version receives no packets.

[sassyaspy]

Hey Reddata,

Usually in cases like this the problem is with a firewall (Windows, antivirus, etc). One thing you can do to confirm this is to do a Wireshark capture to see if any of the packets your computer generates while running the Sender VI are being blocked at the ports. It sounds like you have been able to connect just fine, but the packets the computer is sending aren't making it past the firewall. 

[Reddata]

The arrival of the multicast packets had been proven by the successful sniffer.  Regardless, I also ran tcpdump on the cRIO.  The tcpdump trace shows the UDP multicast packets arriving from the windows host just fine.

[sassyaspy]

Hey Reddata,

What does your network topology look like? Is the cRIO connected to a switch/router, is it link-local? Is the host computer using a wired or wireless connection? I think the next step will be to remove network problems as a source of error by directly connecting the cRIO to the host computer and trying the UDP example again. 

One more question I had for you -- what data are you sending to the cRIO? Are they strings, numbers formatted as strings, etc? Can you play around with the type of data sent, particularly sending simple strings rather than other data types formatted into strings?

[Reddata]

This my network topology.  Everything is statically addressed.  There are no wireless connections.

Per your request, I tried connecting the cRIO to the Dev PC directly.  I also tried sending simple strings rather than doubles formatted as strings (the default behavior of the example).  Neither attempt was successful: tcpdump and my sniffer see the incoming packets, but the Receiver VI obstinately refuses to see anything.

I recently reformatted my cRIO and upgraded to the NI-RIO 14.0.1 drivers.  The problem persists.

I suppose the real issue is that the unmodified Receiver VI returns error 42 when run on the cRIO.  But searching online I couldn't find any information about this error in connection with UDP.

[sassyaspy]

Hello reddata,

According to the research I have done on this, Error 42 with UDP typically indicates that the specified IP address is unreachable. That might be related to this KB I found:

http://digital.ni.com/public.nsf/allkb/640C2C0485AD6B8386257A2A005AD085?OpenDocument

Linux RT, with respect to UDP communication, behaves like a VxWorks target and will filter packets with the exact destination. That means that the network address input of the UDP Open should not be wired--is this how you have it set up?

Also, would you be able to post the results of the tcpdump trace you ran on the cRIO? Have a good weekend!

[Reddata]

---

sassyaspy wrote:

 ... the network address input of the UDP Open should not be wired--is this how you have it set up?

---

Unwired is the default configuration of the UDP Multicast Receiver VI:

---

reddata wrote:

It resulted in Error 42 from the Mulitcast Open VI call in the Receiver VI.  This is why I altered the net address as mentioned in the thread (forums.ni.com/t5/LabVIEW/needed-software-packages-​on-cRIO-for-Multicast-UDP/).  Altering the address resolved the error 42 message, but no packets are received.

---

In other words, I've tried both wired and unwired configurations for net address.  Unwired results in Error 42.  Wired resolves that error but doesn't receive any packets.

Attached is output from a 10-second run of tcpdump -i eth0 udp

Does LabVIEW have a packet filter of some kind?

[sassyaspy]

Hey reddata,

Since it does appear that your cRIO is receiving the packets, the problem is most likely an addressing issue (LabVIEW does not filter packets aside from looking only at the address and port that you specify). After doing a little research about addressing with UDP Multicast, I found an article on IANA's website detailing the purpose of each address range:

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

With that in mind, it might be helpful to try the Organization-Local Scope address range for UDP Multicast. Can you try dragging the first attached VI snippet into the block diagram of your Receiver.vi on the cRIO-9068? Then, make sure that the Sender.vi is using the same address to publish to. You could also try combining the sender and receiver on the cRIO as in the second snippet attached, and verifying that.