No UDP traffic when built into an applications

[WhatIsGoingOn]

I have LabView 2019 application that works great when run through the development environment, but when I build it into a standalone executable / installer it no longer seems to send any UDP traffic.  I've been able to confirm via netstat -ab that the application is successfully claiming all of the UDP ports it needs and that there are no conflicts.  I've tried both with the Windows firewall on and with it off and I even added ruled into the firewall to ensure that the executable was allowed through.

The application receives data fine and isn't throwing any errors.  I also tried running the simple UDP sender and receiver and have the same behavior (works in LabView, but no data in executable).

If my application is being given the ports it requests (as shown by netstat), what else could cause it to send UDP data in LabView, but not as a standalone application.  Is there some build option I missed?

I'm monitoring my NIC with Wireshark and see no UDP traffic on the ports I've identified (and the remote device doesn't receive the data)

[billko]

Even though you say it only happens with the executable, it will still be of great value if we could see the source code.

[rolfk · Accepted solution]

---

@WhatIsGoingOn wrote:

If my application is being given the ports it requests (as shown by netstat), what else could cause it to send UDP data in LabView, but not as a standalone application.  Is there some build option I missed?

---

Firewall? A built application is an independent process with its own firewall rules. Usually when you start up a new program for the first time, the firewall will prompt you to allow traffic for this process. This dialog is easy to dismiss as "yet another stupid startup dialog"(TM) which will then prevent your application from sending and receiving any data.

In order for attacking code to not be able to detect that it is actively blocked, the firewall usually lets the process create sockets and even bind them to network addresses and ports, but any data send through them is simply sinkholed to /dev/null. So your network monitoring will see the open ports but there is still no data transfer.

[WhatIsGoingOn]

Unfortunately, it's a pretty massive queued message handling and data acquisition project.  Between that and business rules, I can't post the bigger project.  

However, even the basic LabView provided example for UDP sender / receiver behaves in the same way.  It works fine in the build environment, but then no traffic leaves the machine when running as an executable.  

[Mark_Yedinak]

And as stated, you need to make sure that your applications are allowed network access in your firewall. You need a rule for your specific application name.

[WhatIsGoingOn]

Thanks all for the replies - for anyone else that hits this issue - here's what I did to fix it

It turns out there were two issues.  One was something you pointed out that I didn't know.  I thought that the firewall behaved by blocking the application from even claiming the ports, so I had incorrectly assumed that if my executable showed in netstat to have claimed the ports, that meant the firewall was allowing the application through.  I added the application to the list of trusted applications in the firewall.  Doing that fixed the LabView Example UDP sender receiver program as an executable. 

However, my main application still wasn't working properly.  This change did make the UDP packets show up in Wireshark though.  When reviewing the packet contents, I noticed that the CRC portion of the packet was all 0's.  It turned out that when I built the project, I have a CRC lookup table that I included in the distribution, but it was incorrectly placed in the support folder in the build.  Once I created the folder for the build that the application expected to hold that file, all was well.

So, root cause(s) - firewall entries and build environment folder structure didn't match LabView environment

[billko]

---

@WhatIsGoingOn wrote:

Thanks all for the replies - for anyone else that hits this issue - here's what I did to fix it

It turns out there were two issues.  One was something you pointed out that I didn't know.  I thought that the firewall behaved by blocking the application from even claiming the ports, so I had incorrectly assumed that if my executable showed in netstat to have claimed the ports, that meant the firewall was allowing the application through.  I added the application to the list of trusted applications in the firewall.  Doing that fixed the LabView Example UDP sender receiver program as an executable. 

However, my main application still wasn't working properly.  This change did make the UDP packets show up in Wireshark though.  When reviewing the packet contents, I noticed that the CRC portion of the packet was all 0's.  It turned out that when I built the project, I have a CRC lookup table that I included in the distribution, but it was incorrectly placed in the support folder in the build.  Once I created the folder for the build that the application expected to hold that file, all was well.

So, root cause(s) - firewall entries and build environment folder structure didn't match LabView environment

---

You might want to mark your post as a solution because you never know who it's going to help.  🙂