Jump to content

server.tcp.enabled


Recommended Posts

QUOTE (Variant @ Jan 12 2009, 10:07 AM)

Well there is not much to say.. Check out the http://wiki.lavag.org/LabVIEW_configuration_file/VI_Server#server.tcp.enabled' rel='nofollow' target="_blank">LabVIEW Wiki on LabVIEW configuration file.

This key will be present in the INI file beside your EXE when TCP/IP is checked in your LabVIEW options (Tools >> Options... >> VI Server: Configuration) ; I think you need this to be activated only if your EXE has to communicate with another application through TCP/IP.

[EDIT]

As Ton pointed : You need this to be activated if you want your VI Server to be accessible to other applications.

Hope this helps.

Link to comment

According to the LabVIEW wiki this refers to the VI server enabled/disabled setting.

See LabVIEW_configuration_file/VI_Server#server.tcp.enabled

Ton

QUOTE (Antoine Châlons @ Jan 12 2009, 10:20 AM)

... I think you need this to be activated only if your EXE has to communicate with another application through TCP/IP.

Hope this helps.

Well Antoine you are fast.

But, this only needs to be activated if you want to expose VI server, for normal TCP/IP connections you don't need it.

Ton

Link to comment

QUOTE (Variant @ Jan 13 2009, 06:38 AM)

I need to know the internal details like, whether we are making the exe as a server or VI server opens an option for the exe to be accessed by the other applications.

Can you be a bit more clear with your question? I for one still wonder what you meant by this sentence.

Rolf Kalbermatter

Link to comment

QUOTE (Variant @ Jan 13 2009, 03:38 AM)

I need to know the internal details like, whether we are making the exe as a server or VI server opens an option for the exe to be accessed by the other applications.

Rolf is right, it would be helpful to know more about what you are asking. If you are asking if this is a security vulnerability, then yes. If you enable the VI Server then LabVIEW will listen on port 3363. If your firewall lets that port through, then other machines can detect that your computer is listening. If another computer connects to VI Server, and that computer can speak the VI Server protocol, then it can run any VI on your system if it knows the name.

I don't think LV scripting will work through this connection. I don't think you could use this connection to build new VIs on the target system which could do very bad things like list or read or delete the contents of your hard drive without specific advance knowledge of VIs existing on the remote system. (That's an interesting discussion on its own, especially if I am wrong).

If you build a separate EXE, you would have to enable VI Server for that application in its own INI file in order for that to be exposed or vulnerable.

If that wasn't the thrust of your question, then you could try again.

Link to comment

QUOTE (jdunham @ Jan 14 2009, 05:21 PM)

If you build a separate EXE, you would have to enable VI Server for that application in its own INI file in order for that to be exposed or vulnerable.

If that wasn't the thrust of your question, then you could try again.

Ok this is what I wanted, When I build an LabVIEW exe. In that exe ini i enable the server.tcp.enabled = True and assign it with some other port 5346. (Please correct me if my understanding is wrong). Doing this will actually make my exe as server and listens for clients to connect.

Link to comment

QUOTE (jdunham @ Jan 14 2009, 05:21 PM)

If you build a separate EXE, you would have to enable VI Server for that application in its own INI file in order for that to be exposed or vulnerable.

If that wasn't the thrust of your question, then you could try again.

Ok this is what I wanted, When I build an LabVIEW exe. In that exe ini i enable the server.tcp.enabled = True and assign it with some other port 5346. (Please correct me if my understanding is wrong). Doing this will actually make my exe as server and listens for clients to connect.

Link to comment

QUOTE (Ton @ Jan 14 2009, 09:22 PM)

Well you can connect to it with Telnet (this is useful for testing your connectivity and checking your firewalls), but after you send it a few keystrokes and it realizes you don't speak VI Server, it will disconnect.

If you want a server like Ton is mentioning, you have to write code using the TCP routines in vi.lib, and it has nothing to do with the INI file. You can listen on any port you want, but you have to write all the code to receive data and send responses. The LabVIEW Examples are a good place to start.

Link to comment

QUOTE (Ton @ Jan 14 2009, 09:22 PM)

Well you can connect to it with Telnet (this is useful for testing your connectivity and checking your firewalls), but after you send it a few keystrokes and it realizes you don't speak VI Server, it will disconnect.

If you want a server like Ton is mentioning, you have to write code using the TCP routines in vi.lib, and it has nothing to do with the INI file. You can listen on any port you want, but you have to write all the code to receive data and send responses. The LabVIEW Examples are a good place to start.

Link to comment

QUOTE (jdunham @ Jan 14 2009, 11:21 AM)

Rolf is right, it would be helpful to know more about what you are asking. If you are asking if this is a security vulnerability, then yes. If you enable the VI Server then LabVIEW will listen on port 3363. If your firewall lets that port through, then other machines can detect that your computer is listening. If another computer connects to VI Server, and that computer can speak the VI Server protocol, then it can run any VI on your system if it knows the name.

Actually you can limit both the VIs that will be accessible over remote VI server connections as well as the IP addresses that can connect to the server. The syntax for the keys is not documented nor easily described in full, but configuring everything in the LabVIEW options and copying the keys over to a built applications ini file is best.

QUOTE

I don't think
LV
scripting will work through this connection. I don't think you could use this connection to build new VIs on the target system which could do very bad things like list or read or delete the contents of your hard drive without specific advance knowledge of VIs existing on the remote system. (That's an interesting discussion on its own, especially if I am wrong).

There are a lot of VI server operations (including almost all scripting) that is not even present in a built application. Many other methods and properties are also not accessible at all. And with above settings you can tighten it up so much that there is really not much an attacker can do other then sending it malformed packages to try to make it crash.

Rolf Kalbermatter

Link to comment

QUOTE (jdunham @ Jan 14 2009, 11:21 AM)

Rolf is right, it would be helpful to know more about what you are asking. If you are asking if this is a security vulnerability, then yes. If you enable the VI Server then LabVIEW will listen on port 3363. If your firewall lets that port through, then other machines can detect that your computer is listening. If another computer connects to VI Server, and that computer can speak the VI Server protocol, then it can run any VI on your system if it knows the name.

Actually you can limit both the VIs that will be accessible over remote VI server connections as well as the IP addresses that can connect to the server. The syntax for the keys is not documented nor easily described in full, but configuring everything in the LabVIEW options and copying the keys over to a built applications ini file is best.

QUOTE

I don't think
LV
scripting will work through this connection. I don't think you could use this connection to build new VIs on the target system which could do very bad things like list or read or delete the contents of your hard drive without specific advance knowledge of VIs existing on the remote system. (That's an interesting discussion on its own, especially if I am wrong).

There are a lot of VI server operations (including almost all scripting) that is not even present in a built application. Many other methods and properties are also not accessible at all. And with above settings you can tighten it up so much that there is really not much an attacker can do other then sending it malformed packages to try to make it crash.

Rolf Kalbermatter

Link to comment

QUOTE (Ton @ Jan 15 2009, 06:22 AM)

I have the following questions:

1 Which means using open application reference I will be able to communicate with my exe and this communication is done through VI server. So VI server manges different application with TCP server enabled.

2 "Only VI server connections" Will I not be able to communicate with any other application other than labVIEW. if this is wrong what do you mean by only VI server connections.

3 Lets say i have two exes running with different ports TCP server enabled. How does it work?

Can you give me the levels of hierarchy of this communication. like How this whole flow works( Machine name--> ..-->Port--> Application). please explain this I want to understand clearly and 100%

Link to comment

QUOTE (Ton @ Jan 15 2009, 06:22 AM)

I have the following questions:

1 Which means using open application reference I will be able to communicate with my exe and this communication is done through VI server. So VI server manges different application with TCP server enabled.

2 "Only VI server connections" Will I not be able to communicate with any other application other than labVIEW. if this is wrong what do you mean by only VI server connections.

3 Lets say i have two exes running with different ports TCP server enabled. How does it work?

Can you give me the levels of hierarchy of this communication. like How this whole flow works( Machine name--> ..-->Port--> Application). please explain this I want to understand clearly and 100%

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.