Linux Server:TCP Listener Active

[RVallieu]

I have LabVIEW 2018 on CentOS 7.6

Building App - Set My Computer Properties to enable VI Server on 3364 (instead of 3363 to not collide).

Main VI has Property node to check the Server:TCP Listener Active = T/F

Build the application - it runs fine - Server: TCP Listener Active = F

Firewall is turned off as this is a disconnected system.  The config file does list TCP Server Enabled, and localhost access allowed and Exported VIs = *

Not sure what else could be causing the listener not to be running on the EXE?  Anyone have any insight?

[RVallieu]

Hmm.  Seems like the LabVIEW Dev environment was holding that port.  I closed LabVIEW Dev and ran the EXE and Server TCP Listener was then TRUE.

Added an error out from my property node and with Dev Env running, got Error 60.

I wonder if I change the property after the build and restart if Dev environment will not collide and I can test with VI acces...I will try it.

[RVallieu]

Bah - still getting error 66 from Client VI trying to open a connection to the VI Server for the EXE on the port configured for the VI Server.  I am using Port 3364, nothing else is using that port on the system.

Allowable connection is set to 'localhost'

Not sure what is now blocking the connection.  There is no firewall.

lsof -iPn | grep LISTEN does show my EXE listening on Port 3364.

Yet when I try to connect, I get error 66.

[rolfk]

Try to connect how? TCP Open Connection node or Application Control:Open Application Reference node?

TCP Open Connection node won't work easily as VI Server uses its own private protocol and you can't really expect to handle that without detailed documentation. This would return error 66.

The only officially documented way to connect to a VI Server instance through TCP/IP is by using the Open Application node with the TCP/IP address/DNS name. This should not return error 66 as the TCP/IP functions are wrapped in a higher level function with its own LabVIEW error code range.

[RVallieu]

Sorry, should have been more specific.  When the brain gets locked on a topic I forget people may not understand from my words what I am attempting.

Of course I am using the Open Application Reference node as I am trying to utilize VI Server, which I configured under the "My Computer" Properties setting in the Project as that is what governs the settings for the EXE build when it is configured and built.

I am following the examples given by NI as I figured I might be making a mistake, since it has been a while and not ever on Linux Desktop before. I have done this in the past on other non-Linux systems without issue.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KuGSAU&l=en-US

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LbZSAU&l=en-US

I am using Port 3364 for the EXE as I don't want it to collide with LabVIEW Dev environment.

My EXE Main is also set up to let me know if the Server is listening by getting its own application reference and using the property node to check the properties:

Server Port

Server TCP Active

Server TCP Access List

I am attempting to use the Open Application Reference by feeding in 'localhost' which is shown in the examples, since I am on the same system.  Using the port configured, 3364, into the Open Application Reference. 

This is what is returning Error 66 - I've even tried changing the access list to just * to allow ALL and attempt to connect using 'localhost' - thinking maybe the 'localhost' is the issue.

Now my access list is set to 

localhost

*

127.0.0.1

10.3.0.4 (which is the IP of the controller)

Hmm. The controller does have two Ethernet ports, but the second is unused at this time.

[RVallieu]

OK - went in and deleted all on the Access List.

Only added localhost onto the list.

Rebuilt the app, now can connect. No error 66.  Strange.

Trying to be thorough - edit My Computer properties, add my local network connected dev computer running Windows to the list in the Access area using the Add button and putting in 10.3.0.2 for the Windows Dev Computer in addition to localhost on the list, build the app.  I can NO LONGER connect using localhost and get error 66 again.

This seems like a bug?

[RVallieu · Accepted solution]

I found the issue.

This must be a bug.

When I add anything to the Access List in the My Computer Properties, and then build, of course the Application.conf file is generated in the designated Build folder.

When I read the Application.conf file that is created by the LabVIEW Application Build function, it places a ; (semicolon) between the items on the address list.  In my experience this used to be a : (colon) on other machines.

In my Built EXE, I noticed the Application:Server TCP Access List is not returning multiple elements, but only a SINGLE string with all the items on the one element, showing the ; between items so it is showing:

Access List [1D Array]

(Array string element, index 0) localhost; 10.3.0.2

Rest of array is empty

With this configuration (multiple entries in the Access List, ; separated in the Application conf file) when I try to use Application:Open Application Reference using localhost, Port 3364, I get Error 66.

If I set only Access for localhost and rebuild the application:

With this configuration (only localhost on the Access List), when I try to use Application:Open Application Reference using localhost, Port 3364, I connect with no issue.

I manually went into the Application.conf file and replaced the ; (semicolon) with : (colon) and didn't even rebuild the application, just ran it again.

Now the return from the Application Property Node:Server Access List reads TWO elements

Access List [1D Array]

(index 0) localhost

(index 1) 10.3.0.2 <- which is my Windows Dev machine

With this configuration (multiple entries in the Access List, : separated in the conf file), when I try to use Application:Open Application Reference using localhost, Port 3364, I connect with no issue.

So - somehow the App Builder is using the WRONG separator - or the read function in the EXE side needs to look for ; instead of :

I guess I can fix this by creating a VI to go in and run after the build and replace the ; with : in the conf file - what a pain.

[rolfk]

Under Windows, my Ini file setting looks like:

server.tcp.access="+127.0.0.1;+localhost;+*"

so with semicolons. 

[RVallieu]

Are you able to run a simple Main EXE and connect to the VI Server of the EXE from the Dev environment?

Maybe the EXE side of the code on the Linux distribution is looking for : improperly and should be looking for ;.  All I know is that changing the file to : allows the code to actually work.

I filed a Bug report, so we will see what happens.

On my Windows Dev machine running 2019 SP1, 32-bit, my access list is in HEX in the config file.  

Odd.  But the EXE returns the proper access list with two elements.  Must be Linux distro specific.

[RVallieu]

NI AE responded to my Bug submission.  They asked me to check what happens with the Dev Env settings for VI Server.

When I go into Tools>Options>VI Server and add two addresses for the Development Environment VI Server and then check the labview.conf found in my home/usrname/natinst/.config/LabVIEW-2018/labview.conf file it wrote the

Server.tcp.access=”+localhost:+10.3.0.2”

So that version for the LabVIEW Dev Env setting did use the : to separate the values.  Seems like only the “My Computer” level inside the project is the source of the issue.

Again this is on CentOS 7.6

This is a reported bug.

The BUG ID is 1154710. Review the next Bug Fixes document release to know if this bug was fixed.