Reading a UDP Broadcast

[CharlesD3]

So the top loop errors out (56) every time unless I click the 'broadcast value' button; then the top loop reports 'iteration xxxxx' as written by the bottom loop.

I've re-attached the latest version; shown in the screenshot from earlier.

Perhaps (or not) relevant:  the hardware in question can be set to operate in UDP or TCP mode, but always broadcasts this message regardless.  It is currently set to operate in UDP mode, but when I have set it for TCP mode I can command and communicate with it just fine (with a TCP based LV vi).  The only reason I don't just use TCP mode is because my customer wants it to run UDP.

[altenbach]

You still have the FFFFFFFF wired, remove it!

(You still have not said how many Ethernet interfaces your computer has)

---

@CharlesD3 wrote:

The only reason I don't just use TCP mode is because my customer wants it to run UDP.

---

TCP is connection based, so you cannot do broadcasts with TCP. It has to be a connectionless protocol such as UDP.

[CharlesD3]

I have 2 ethernet interfaces.

If I send messages in one VI, I can read them in a separate VI.  I can see this traffic and the hardware's broadcast in wireshark, but can not get the LV VI to receive the ones from the hardware.

I have further been able to send messages to the hardware, and confirm in wireshark that it has received the message and and sends good data back.  I just can't get LV to read any of it.

[altenbach]

Firewall rules have been mentioned:

• Is LabVIEW allowed to use the network?
• Does the windows firewall allow unsolicited incoming UDP connections?

Does it work once you disable the firewall in the OS? (And any other third party software under the "Security" umbrella such as Norton, etc.)

If you have two configured ethernet interfaces, you should listen on the IP that is connected to the network where the device is. can you show is the latest version of your program?

[CharlesD3]

This wireshark screen shows two send/receive message sets.  In the image I have highlighted the data that I know to be correct; validating that the message was received by the relay board.  My IT guy assures me, that since I can verify that the relay board did receive the message I sent to it, then that confirms that the ports are working properly and there are no firewall issues.

[altenbach]

Firewalls make a huge distinction between outgoing connections and unsolicited incoming connections.

What is your netmask? Are 192.168.168.82 and 192.168.1.18 on the same subnet? Broadcasts typically don't cross subnet boundaries, such as routers (unless configured to do so)

Can you give a full description of your network topology? Can you configure wireshark to show port numbers instead of descriptions.

You send a broadcast from 192.168.1.82 and a device at 192.168.168.18 responds with a unicast within milliseconds. Do you need to send this broadcast for every new request? Maybe something to try!

What is the purpose of the code up to and including the stacked sequence? Are you aware that index array is resizable?

[CharlesD3]

The information leading up to the stacked sequence is the UDP open/write sequence; I have the close in the stacked sequence just so I can have a delay after closing before trying to re-open the port an read.  The delay is currently 10 seconds.

In as far at 'this' network's topology, I am directly connected from my laptops ethernet jack to the relay board in question.  My laptop is acting as the server I guess.  The subnet mask is set to 255.255.0.0; which allows that 3rd part of the IPs to be different.  I have a TCP version of this program that works just fine.

I don't know of any way to reconfigure wire shark.  I know that for some UDP traffic, such that wireshark shows it as UDP in the protocol column, will show the port information in the info column.  For these recent transactions the port information is in the detail section.

This current VI is a single transaction.  I send a query for ADC values, and the relay board responds with those values.  You can see the 8 bytes in the middle of that highlighted area is this information.  "AA 08" is a response header of some sort, followed by 8 bytes representing the individual ADC values in counts, then a checksum.  I am not sure what the remaining "00" bytes are, but that do not seem to have an effect.

There is a broadcast to port 13000 that the board puts out every 10 seconds.  I have tried extensively and without luck to read that data as well.  This particular iteration of the VI mostly serves to prove that I can send messages that the board does receive and respond to correctly.

Your tip about the 'index array' is very helpful.  It will definitely make alot of my VIs cleaner 🙂

[altenbach · Accepted solution]

So first of all, terminology. You are not reading a broadcast, but a unicast return triggered by a broadcast you sent. That responds comes within milliseconds, so if you close the connection, wait 10 seconds, and then try to read it, you are way (way!!!) too late!

I do believe that you should keep the connection open for the duration of the program. Try for example something as follows:

What does wireshark say when you run it?

[CharlesD3]

That would appear to be the solution 😃

I'm guessing closing the port between the 'write' and the 'read' may have been part of the problem?  I've seen a few other similar 'read' functions where the while loop just repeats around the 'read' part, but that never worked.

I'm not sure if I can apply this format to the unsolicited broadcast that this board transmits, but I don't really need that anyway.

Thanks!

[altenbach]

If the device continuously sends out data, all you need is the read function. This one needs to be tickled to send exactly one response per request.

UDP is not connection based, so it's just send it and forget it. The sender has no way to tell that anyone received it. Once it is on the wire and nobody listens at that very moment, it is irreversibly lost.