From Thursday, May 23rd (05:00 PM CDT) through Friday, April 24th (1:30 AM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP Broadcast on RT PXI gets sent out all NICs

I have an application running on an RT PharLap chassis which sends a UDP message out as a broadcast to 255.255.255.255 at port X.

 

Based on the documentation for the UDP Open primitive, I would expect this to to be received by anyone on the same subnet listening on port X, and I would expect them to see that broadcast as having been sent from my PXI’s default NIC.

 

However, what I see instead is multiple copies of the same message being received, each one originating from a different NIC on the PXI.  Moreover, those NIC don’t even have to be physically connected to the receiver for it to get a message indicating it came from the NIC.

 

For example, say my PC has IP 192.168.10.1 and my PXI has IP 192.168.10.2 as it’s default NIC on the front of the controller.  That PXI also has several additional NICs in the form of PXI modules with IPs 192.168.0.1 and 192.168.0.2.  Finally let’s say 192.168.10.1 is physically connected via a cable to 192.168.10.2 and 192.168.0.1 is physically connected to 192.168.0.2.

 

I then send 0xABCD via a UDP connection opened on 192.168.0.1:1234, to 255.255.255.255:2345.  I would expect this message to be received by 192.168.0.2 if it is listening on port 2345, and I would expect that message to have originated from 192.168.0.1:1234, which it does.  However, two duplicate messages are also received from 192.168.10.2 and 192.168.0.2 (this one is actually the IP of the NIC that receives the message).  

So it seems like anytime I broadcast a UDP message to 255.255.255.255, this is sent out all available NICs on the PXI.  This does not seem like expected behavior and has anyone seen this before/have an idea how to only broadcast from a single NIC?



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
0 Kudos
Message 1 of 4
(2,815 Views)

Look at the termnials for the UDP broadcast, either the Open or Write UDP. One of the parameter - which is NOT required to be wired, sets the UDP to 'Broadcast All - echo to all attached IP ports' and one setting is 'only' to the TCP address.

This should then work as expected. BTY: it's not an excessive network burden to have the UDP broadcast on all networks.

 

Also Multicast UDP is a bit cleaner way to UDP, it can send multiple UDPs' to a single 'virtual' TCP port. Very useful.

 

Regards

Jack

0 Kudos
Message 2 of 4
(2,754 Views)

You are referring to, I believe, the address terminal on UDP Open.  If you leave this unwired, then that connection will listen on all interfaces and if you wire it with a specific IP, it will only listen on that interface.  However, this does not seem to have any effect on where you write from.  Looking at some other information I’ve found, this appears to be controlled by the OS and routing tables which I don’t have much access to on a PharLap system.

 

As far as network load goes, the concern is t additional burden on the system but rather the DUT which is expecting an incoming UDP broadcast from a specific IP and it apparently does not actually check to make sure that IP is correct.  

It would seem that sometimes PharLap decides it’s going to write out a different interface as long as it determines that there is a routable path which makes the DUT reachable via that interface.

 

I’ll look into multicast but I may be stuck with broadcast because of how the DUT operates.



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
0 Kudos
Message 3 of 4
(2,718 Views)

Following up on this in case someone runs into a similar issue.  It appears to be a problem with PharLap and how it handles routing.  Rather than sending the UDP traffic out the NIC with the assigned IP, it sends it out the first NIC which is determined to have the shortest path to the receiving IP. 

 

Switching to NI Linux RT allowed access to the routing table so that traffic sent to IP X can be forced to be sent out physical NIC Y.

 

I wouldn't say this is solved because as originally implemented under PharLap, I do not believe there is a solution.



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
Message 4 of 4
(2,187 Views)