libssh2lv.so path issue in PXI RT Linux target- x64 quad core

[temin4u]

HI @volks73 ,

We needed a SSH client on the PXI Linux RT target, its a quad core PXIe 8840 controller.

The problem is after placing the libssh2lv.so file in /usr/lib Dir, and providing the path explicitly for the Initialize API it didn't take the path, it returned a file not found error.

After going through the https://github.com/fieldrndservices/libssh2-labview#dependencies-installation-crio session, I came to know that libssh2.so is a dependency for libssh2lv.so file. I installed the x64 version from the below link, I couldn't find a quad core version of the ipk file, I'm not sure if this could be the missing link.

https://github.com/fieldrndservices/libssh2-nilrt-ipk/releases

admin@NI-PXIe-8840Quad-Core-031C9C8F:/usr/local/lib# opkg install libssh2*.ipk Installing libssh2 (1.9.0-r0.4) on root Configuring libssh2. admin@NI-PXIe-8840Quad-Core-031C9C8F:/usr/local/lib#

I observed libssh2lv.so.1 file created after the installation is competed

Still the file not found error persist after installation of the above ipk file also, can you advice if there is any other dependency or if I'm missing something. Thanks in advance.

[volks73]

I may have messed up the install script for the IPK or I am missing something. The LIBSSH2 for LabVIEW toolkit implicitly looks for libssh2lv.so in the /usr/lib directory, not the libssh2lv.so.1 link/file. The libssh2lv.so.1 is a symbolic link, most likely to the libssh2lv.so file. The LIBSSH2 for LabVIEW toolkit does not look for the libssh2lv.so.1 file. Did a libssh2lv.so and libssh2.so files get installed in the /usr/lib directory?

Sometimes a "File Not Found" error in LabVIEW is also a "Permission Denied" error. Please check the permissions of the libssh2lv.so file that you copied to the /usr/lib folder, i.e. ls -l from the command line. What are the permissions? You might need to ensure the libssh2lv.so file has read and execute permissions for the user, group, and others, chmod go+rx /usr/lib/libssh2lv.so.

The core2-x64 would be the same for the quad core. It is the same family of processors. Basically, 64-bit Intel instead of an ARM-based processor. I do not believe there is a missing link.

[temin4u]

I may have messed up the install script for the IPK or I am missing something. The LIBSSH2 for LabVIEW toolkit implicitly looks for libssh2lv.so in the /usr/lib directory, not the libssh2lv.so.1 link/file. The libssh2lv.so.1 is a symbolic link, most likely to the libssh2lv.so file. The LIBSSH2 for LabVIEW toolkit does not look for the libssh2lv.so.1 file. Did a libssh2lv.so and libssh2.so files get installed in the /usr/lib directory?

During my first round of testing, I copied the libssh2lv.so file manually to /usr/lib dir. Didn't pay attention if libssh2.so existed by that time, What I see now is if I sort the name by libssh, I observe the below files

Looks like libssh2.so is a symbolic link to libssh2.so.1, libssh2.so.1 is a symbolic link to libssh2.so.1.0.1

Sometimes a "File Not Found" error in LabVIEW is also a "Permission Denied" error. Please check the permissions of the libssh2lv.so file that you copied to the /usr/lib folder, i.e. ls -l from the command line. What are the permissions? You might need to ensure the libssh2lv.so file has read and execute permissions for the user, group, and others, chmod go+rx /usr/lib/libssh2lv.so.

As you see from the screenshot, all the file permissions are given. I did chmod 777 * on the /usr/lib dir.

The core2-x64 would be the same for the quad core. It is the same family of processors. Basically, 64-bit Intel instead of an ARM-based processor. I do not believe there is a missing link.

Thanks for confirming this, I also thought cores doesn't matter, If it is x64 Intel it should be fine I believe from your feedback.

As you see in the above image, It still returns file not found error. Array index 6 confirms that the file path returned by build path function is correct. Let me know if any additional info is required @volks73

Thanks.

[volks73]

Thanks for the screenshots and updated information about the permissions. Yes, the Intel x64 is good for the libssh2lv.so file.

Try double-clicking on the Call Library Function node (orange color). A dialog will appear. Delete the path that might be in the Library name or path box. Then, try the VIs for the toolkit.

[temin4u]

HI @volks73 , Tried clearing the existing path in Call library function node but didn't get lucky.

Also observed a strange behaviour, In the below image you can observe that I got the same Error 7when tried to give the path explicitly. The file definitely is there as confirmed by the file or folder exists? indicator.

But when I configured the path implicitly in the call library function node, the deployment failed with error.

Quick update; When I googled for the below error, I found some NI resources, In general they are pointing to missing dependencies, Let me know your thoughts on the same please

LabVIEW: (Hex 0x436) Failed to load shared library libssh2lv.so:lv_libssh2_initialize:C . Ensure that the library is present on the RT target.

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

Regards. Temin

[volks73]

@temin4u It appears that the libssh2lv.so cannot find the libssh2.so shared library. The libssh2lv.so is on disk. The libssh2.so also appears to be on-disk, but the libssh2.so is not being loaded as part of the load path. The "File Not Found" is for the libssh2.so from libssh2lv.so trying to the loaded shared library.

Have you rebooted the controller since installing the libssh2.so shared library?

This is all very strange because both shared libraries are in the load path by being in the /usr/lib folder.

I checked on a CompactRIO that I know has worked in the past, and the permissions for the shared libraries, not the symbolic links, are -rwxr-xr-x with the owner being admin. Maybe your permissions are too permissive (-rwxrwxrwx) and NI Linux RT thinks this is a security issue? Can you try changing the permissions to remove write access on the group and others? Also, what are the permissions for the /usr/lib folder on your system? It should be drwxr-xr-x.

[volks73]

It might be that the core2-x64 IPK of the libssh2 shared library is, in fact, not appropriate for the Quad Core. You may have to setup a build environment on the controller and compile/build the IPK.

The wrong shared library architecture will appears as a "File not found" error.

[volks73]

Maybe also try ldconfig to reload and cache the shared libraries.

[temin4u]

@volks73 thanks for the update, I will try setting the permissions as per your recommendation and give it a try. natively compiling on the target and trying the new IPK is also worth exploring. I will try this on ween-end and keep you posted.

On a quick note, In the screenshot I shared earlier, I hope you noticed that the libssh2.sois a symbolic link to libssh2.so.1 and `libssh2.so file size is 1KB, any inference from this screenshot?

https://user-images.githubusercontent.com/76934802/115751950-4496ac80-a3b7-11eb-84dc-e5a60177f095.png

[volks73]

@temin4u From the screenshot, why are the dates for each of the links and files so different? I would think all of them would have a similar date, especially the symbolic links relative to the file. However, I am not sure about the relevance of the date field in the screenshot to the issue.

I am curious why a symbolic link is 1K of size.

From my understanding, LabVIEW and Linux should follow the symbolic links so the fact that libssh2.so is a link pointing to libssh2.so.1.0.1 should not matter. However, given the strangeness of this issue, what happens if you delete the libssh2.so symbolic link and rename the libssh2.so.1.0.1 file to libssh2.so? Basically, avoid using the symbolic links.

[temin4u]

@volks73

1. Deleted all the symbolic links and the so files.
2. Removed and reinstalled the IPK

   admin@NI-PXIe-8840Quad-Core-031C9C8F:/usr/lib# opkg remove  libssh2
   Removing libssh2 (1.9.0-r0.4) from root...
   admin@NI-PXIe-8840Quad-Core-031C9C8F:/usr/lib# opkg install libssh2*.ipk
   Installing libssh2 (1.9.0-r0.4) on root
   Configuring libssh2.

3. Rebooted the PXI.
4. Noticed the same files created again as per the previous screenshot.(still showing older dates, not sure why)
5. gave the permissions as recommended.
6. Still the same error observed while deploying., File not found if the path is passed to call lib fn node.

phew, I believe I should try building the new IPK and give it a shot. will keep you updated.

[temin4u]

login as: admin Pre-authentication banner message from server:	NI Linux Real-Time (run mode)
Log in with your NI-Auth credentials.

End of banner message from server admin@192.168.2.149's password: admin@NI-PXIe-8840Quad-Core-031C9C8F:~# ^C admin@NI-PXIe-8840Quad-Core-031C9C8F:~# cd /tmp admin@NI-PXIe-8840Quad-Core-031C9C8F:/tmp# tar -xzf libssh2-1.9.0.tar.gz admin@NI-PXIe-8840Quad-Core-031C9C8F:/tmp# cd libssh2-1.9.0 admin@NI-PXIe-8840Quad-Core-031C9C8F:/tmp/libssh2-1.9.0# mkdir build admin@NI-PXIe-8840Quad-Core-031C9C8F:/tmp/libssh2-1.9.0# cd build admin@NI-PXIe-8840Quad-Core-031C9C8F:/tmp/libssh2-1.9.0/build# cmake .. -- The C compiler identification is GNU 7.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Found OpenSSL: /usr/lib/libcrypto.so (found version "1.0.2u") -- Looking for EVP_aes_128_ctr -- Looking for EVP_aes_128_ctr - found -- Looking for include file unistd.h -- Looking for include file unistd.h - found -- Looking for include file inttypes.h -- Looking for include file inttypes.h - found -- Looking for include file stdlib.h -- Looking for include file stdlib.h - found -- Looking for include file sys/select.h -- Looking for include file sys/select.h - found -- Looking for include file sys/uio.h -- Looking for include file sys/uio.h - found -- Looking for include file sys/socket.h -- Looking for include file sys/socket.h - found -- Looking for include file sys/ioctl.h -- Looking for include file sys/ioctl.h - found -- Looking for include file sys/time.h -- Looking for include file sys/time.h - found -- Looking for include file sys/un.h -- Looking for include file sys/un.h - found -- Looking for include file windows.h -- Looking for include file windows.h - not found -- Looking for include file ws2tcpip.h -- Looking for include file ws2tcpip.h - not found -- Looking for include file winsock2.h -- Looking for include file winsock2.h - not found -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of long long -- Check size of long long - done -- Looking for gettimeofday -- Looking for gettimeofday - found -- Looking for strtoll -- Looking for strtoll - found -- Looking for snprintf -- Looking for snprintf - found -- Looking for memset_s -- Looking for memset_s - not found -- Looking for poll -- Looking for poll - found -- Looking for socket -- Looking for socket - found -- Looking for select -- Looking for select - found -- Looking for inet_addr -- Looking for inet_addr - found -- Performing Test HAVE_O_NONBLOCK -- Performing Test HAVE_O_NONBLOCK - Success -- Looking for include file arpa/inet.h -- Looking for include file arpa/inet.h - found -- Looking for include file netinet/in.h -- Looking for include file netinet/in.h - found -- Looking for strcasecmp -- Looking for strcasecmp - found -- Looking for _stricmp -- Looking for _stricmp - not found -- Looking for _snprintf -- Looking for _snprintf - not found -- Looking for func -- Looking for func - found -- Looking for FUNCTION -- Looking for FUNCTION - found -- Looking for include file sys/param.h -- Looking for include file sys/param.h - found -- The following features have been enabled:

• diffie-hellman-group-exchange-sha1, "new" diffie-hellman-group-exchange-sha1 method

-- The following OPTIONAL packages have been found:

• OpenSSL

-- The following features have been disabled:

• Shared library, creating libssh2 as a shared library (.so/.dll)
• Compression, using zlib for compression
• "none" cipher
• "none" MAC
• Logging, Logging of execution with debug trace

-- Configuring done -- Generating done -- Build files have been written to: /tmp/libssh2-1.9.0/build

admin@NI-PXIe-8840Quad-Core-031C9C8F:/tmp/libssh2-1.9.0/build# cmake --build . --target ipk
make: *** No rule to make target 'ipk'.  Stop.

admin@NI-PXIe-8840Quad-Core-031C9C8F:/tmp/libssh2-1.9.0/build#

@volks73 Can you help me with the last step in building the IPK file, Thanks.

[temin4u]

@volks73 Please ignore my previous post, I got the issue, I took the wrong .gz file to start with,

As per the build guidelines , https://github.com/fieldrndservices/libssh2-nilrt-ipk#build It was requested to download the tar file from https://github.com/fieldrndservices/libssh2-nilrt-ipk/releases

Since I saw only source code (tar.gz) file, I mistook it as a wrong link and took the tar from here, https://github.com/fieldrndservices/libssh2-nilrt-ipk/find/main

After observing the above failure, I thought of downloading the source code (tar.gz) any way but only to find that the link is correct. May be you can consider renaming source code (tar.gz) to libssh2-nilrt-ipk-0.4.tar.gz in the page https://github.com/fieldrndservices/libssh2-nilrt-ipk/releases

Anyway coming to the actual issue, Still the error persist after reinstalling with the generated build also.

PXI is on RT Linux 20.5 image, I'm wondering if that has anything to do with the issue. Do you recommend reinstalling RT Linux in the PXI? Can I try getting some help from NI.

libssh2lv.so Build.txt

Regards, Temin

[volks73]

@temin4u Did you also build the libssh2lv-nilrt-ipk/libssh2lv.so shared library? I think the builds need to match for the libssh2.so and libssh2lv.so shared libraries.

If the problem persists after trying the full custom build, or confirmed the libssh2lv.so shared library was also custom built, then yes, I agree that a ticket with NI should be submitted, assuming you have a SSP/support contract with them.

Out of curiosity, what is the contents of the /usr/local/lib folder? I am wondering if there are any differences with the 20.5 image in how NI organized shared libraries. Maybe in 20.5, user provided shared libraries need to be placed in a different folder?

[volks73]

There is also this KnowledgeBase article about problems with LabVIEW and the "failed to load shared library" error. It seems to suggest the issue could be with the VI and not the shared library. I think you created a separate VI outside of the toolkit to test the Call Library Function node, but if not, that is also something to try.

We may need to isolate the problem to either the Linux system or LabVIEW. Since you have created a build environment on the PXI controller, you could create a relatively simple C program that uses the libssh2.so and libssh2lv.so libraries. The C program just needs to initialize and shutdown. I do not know your level familiarity and comfort with C, but you could use any of the LIBSSH2 examples as a "test program", too. This would at least tell us (you) if the issue is with loading these specific shared libraries (and possibly which one) or is the problem with LabVIEW.

What version of LabVIEW are you using?

[temin4u]

@temin4u Did you also build the libssh2lv-nilrt-ipk/libssh2lv.so shared library? I think the builds need to match for the libssh2.so and libssh2lv.so shared libraries.

If the problem persists after trying the full custom build, or confirmed the libssh2lv.so shared library was also custom built, then yes, I agree that a ticket with NI should be submitted, assuming you have a SSP/support contract with them.

Out of curiosity, what is the contents of the /usr/local/lib folder? I am wondering if there are any differences with the 20.5 image in how NI organized shared libraries. Maybe in 20.5, user provided shared libraries need to be placed in a different folder?

I believe you read the below putty log, libssh2_1.9.0-r0.4_core2-64.ipk is the output file generated. When I installed the ipk using the OPKG install command, I got to see the same set of files created in /usr/lib Dir like earlier (screenshots attached for earlier comments).

Do we have to build two ipk files? For libssh2.so and libssh2lv.so shared libraries?

libssh2lv.so Build.txt

contents of /usr/lib as below for your feedback. usr_lib.txt

---

update: Observed If I try to load the libssh2.so instead of libssh2lv.so I'm getting Resource not found error only. So I believe LabVIEW is able to load the libssh2.so fine and has returned the below error stating the function lv_libssh2_initialize is not found.

libssh2lv.so seems to be the issue here.

[volks73]

I believe you read the below putty log...

Yes, and I did not see anything about building the libssh2lv.so shared library, so I wanted to confirm. Everything in the log appears normal and correct.

Do we have to build two ipk files? For libssh2.so and libssh2lv.so shared libraries?

Yes, both the libssh2-ipk and libssh2lv-ipk need to be installed or built. You appear to have built and installed the libssh2 shared library, but a similar process of building the libssh2lv-ipk and installing the built IPK needs to be completed. I would make sure to uninstall the existing libssh2lv shared library before installing the custom built one.

Briefly, LabVIEW needs to the libssh2lv shared library and the libssh2lv shared library needs the libssh2 shared library. On most UNIX-like systems, the libssh2 shared library can be installed via the system's package manager, for example sudo apt install libssh2, but NI Linux RT does not have a LIBSSH2 package available (which would make this all a whole lot easier). So, a LIBSSH2 package needs to be built based on the target system (PXI quad core). This is also true for the libssh2lv shared library.

contents of /usr/lib as below for your feedback.

Thanks for the output, but what is the content of the /usr/local/lib folder (note the local)? For historical reasons and depending on the Linux distribution, the /usr/local/lib folder can also contain shared libraries. It is possible that NI Linux RT 20.5 has decided that LabVIEW will not load shared libraries from /usr/lib and the shared libraries will only be loaded from /usr/local/lib. It is also possible that there is already a /usr/local/lib/libssh2.so available as NI finally decided to provide SSH client support in RT Linux. If this is true, then LabVIEW maybe loading the /usr/local/lib/libssh2.so first and the libssh2lv.so is trying to use the wrong one.

update: Observed If I try to load the libssh2.so instead of libssh2lv.so I'm getting Resource not found error only. So I believe LabVIEW is able to load the libssh2.so fine and has returned the below error stating the function lv_libssh2_initialize is not found.

libssh2lv.so seems to be the issue here.

The "Resource not found error" seems to indicate that the /usr/lib/libssh2.so is not working. I don't think this is conclusive evidence that it is a libssh2lv.so problem. I would still custom build and install the libssh2lv IPK. What if you move the shared library to your home directory ~/ and used an explicit path to the shared library there? This would tell us if there is anything special about the /usr/lib folder.

I am sorry this is becoming much more of a project to get working.

[temin4u]

Yes, both the libssh2-ipk and libssh2lv-ipk need to be installed or built. You appear to have built and installed the libssh2 shared library, but a similar process of building the libssh2lv-ipk and installing the built IPK needs to be completed. I would make sure to uninstall the existing libssh2lv shared library before installing the custom built one.

Finally, this has been the missing link, It seems I had previously installed only libssh2_1.9.0-r0.4_core2-64.ipk . Since libssh2lv.so showed up in the /usr/lib Dir, I have overlooked the issue.

https://user-images.githubusercontent.com/76934802/115914428-8bf06c00-a48f-11eb-950d-f6b4166c1370.png

Now, after Installing libssh2lv_0.2.1-r0.5_core2-64.ipk, /usr/lib Dir is as below,

@volks73 Everything is working fine now. Thankyou so much for the support. I'm indebted to you for the time you took off your schedule to write back to me.

I noticed this below idea requesting for a SSH client still open on NI website for almost 10 years now. I believe the libssh2 implementation from you will be more than enough for many user requirements, would you mind If I (or you) share details of this tool over there? https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Native-SSH-and-SFTP-Support/idi-p/1141529/page/4?profile.language=en#comments

Regards, Temin

[volks73]

Everything is working fine now. Thankyou so much for the support. I'm indebted to you for the time you took off your schedule to write back to me.

You are welcome and it is great news to hear that everything is working. I just wanted to make a note in case anyone else has a similar problem and to clarify:

update: Observed If I try to load the libssh2.so instead of libssh2lv.so I'm getting Resource not found error only. So I believe LabVIEW is able to load the libssh2.so fine and has returned the below error stating the function lv_libssh2_initialize is not found.

The "Resource not found" error was because the lv_libssh2_initialize function is not part of the libssh2.so shared library. It is part of the libssh2lv.so shared library. The prefix "lv_" is used as a namespace to indicate this function is from/for the libssh2lv.so shared library since the C programming language does not have language-level support for namespaces. The C programming language only has conventions. The "Resource not found" error was correct and everything was working correctly, just the libssh2lv.so file needed to be installed.

I noticed this below idea requesting for a SSH client still open on NI website for almost 10 years now. I believe the libssh2 implementation from you will be more than enough for many user requirements, would you mind If I (or you) share details of this tool over there?

@temin4u Please go ahead and share details of this toolkit in the Idea Exchange. You can use any or all of the following links:

• https://www.vipm.io/package/field_rnd_services_libssh2/
• https://github.com/fieldrndservices/libssh2-labview
• http://help.fieldrndservices.com/libssh2-labview/index.html

It appears this issue has been resolved. I am going to close it.