Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
running networked labview apps without root permissions
mikelachaine
Member
02-09-2004 03:13 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I noticed that it is not possible to use the tcp vi's, i.e. tcp create listener or tcp open (I even tried the supplied examples dataserver.vi and dataclient.vi in tcp.llb) without running them as root, any body has an idea, no one would like to let the end user use root to run the application!. Is it a labview configuration or a unix one?.
Thanks,
mike_lachaine
Thanks,
mike_lachaine
David Duffey
Member
02-09-2004 03:29 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
You should be able to use the TCP vis without being root. This is most likely a security / firewall(on your localhost) setting that is hosing your networking.
You can use "telnet" and "netcat" (nc) programs to help debug what is going on. Make sure you are using ports over 1024, as traditionally, only root can bind (listen) on ports below that.
Are you running solaris or linux? This sounds like something SE linux might keep from happening.
Do you get any useful error messages from using the TCP VIs?.
You can use "telnet" and "netcat" (nc) programs to help debug what is going on. Make sure you are using ports over 1024, as traditionally, only root can bind (listen) on ports below that.
Are you running solaris or linux? This sounds like something SE linux might keep from happening.
Do you get any useful error messages from using the TCP VIs?.
02-09-2004 03:42 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hello,
I did flush iptables, (running on Fedora Core 1), I also used ports over 1024 (8000, 10001, 50000), telnet and nc are not of any help since the app won't run at all. The app stop with "Error 42 at tcp create listener - Generic Labview Error".
I did flush iptables, (running on Fedora Core 1), I also used ports over 1024 (8000, 10001, 50000), telnet and nc are not of any help since the app won't run at all. The app stop with "Error 42 at tcp create listener - Generic Labview Error".
David Duffey
Member
02-09-2004 04:30 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I found a defora core 1 release and verified your problem (on LabVIEW 7.0). It's because the fedora kernel uses native posix threads instead of pthreads. This changes the behavior of signals.
If you recompile your kernel and use pthreads the problem should go away. (Although I have not done this myself).
We have fixed this for the next release of LabVIEW (I did verify this). It required a change in the architecture, and therefore there is no patch available for it.
What I meant by usinc nc and telnet for testing (without LabVIEW) is to "echo hi | nc -l -p 2000" in one window, and "telnet localhost 2000" in another. If your networking is working, you should see "hi" in the telnet window. But, telnet and nc are not affected by
the npt kernel as LabVIEW currently is.
For now, use a non NPT kernel.
If you recompile your kernel and use pthreads the problem should go away. (Although I have not done this myself).
We have fixed this for the next release of LabVIEW (I did verify this). It required a change in the architecture, and therefore there is no patch available for it.
What I meant by usinc nc and telnet for testing (without LabVIEW) is to "echo hi | nc -l -p 2000" in one window, and "telnet localhost 2000" in another. If your networking is working, you should see "hi" in the telnet window. But, telnet and nc are not affected by
the npt kernel as LabVIEW currently is.
For now, use a non NPT kernel.
