04-29-2016 06:08 AM
Hi,
I need to get the TCP/IP connection through SSL on the MyRIO (and further on cRIO also). Is it possible to install Open SSL on MyRIO and then use it through call library function node?
Or maybe there is posibility to somehow compile Open SSL on MyRIO and use only shared libraries without installed Open SSL?
Please have in mind that I'm Linux rookie
Thanks in advance.
04-29-2016 09:50 AM
Openssl is already installed on your myRIO (and cRIOs). On the target sitting on my desk, it is located at /usr/lib/libssl.so.1.0.0.
I don't know how conducive the library is to use with a CLFN, I think you're going to need to write a wrapper that makes it more friendly to LabVIEW.
04-29-2016 10:20 AM
Oh! That's good information
Could you expand the topic of wrapper? What kind of wrapper I will need?
04-29-2016 10:59 AM
A quick reading of some tutorials on using OpenSSL's library show that the interfaces tend to work with a BIO pointer, a means to encapsulate the specifics of the I/O, which is problematic for LabVIEW. You will need to write a library wrapper to handle these sorts of things (either converting to/from datatypes that LabVIEW can accept, and making sure to leave the data alone) or, preferably, keep the details in the wrapper library, passing data to/from LabVIEW only as needed.
04-29-2016 11:12 AM
What is BIO pointer?
04-29-2016 03:40 PM
bienieck wrote:
What is BIO pointer?
That's what LabVIEW said *laughs*
In all seriousness, it's something that's returned from and needed by OpenSSL calls. LabVIEW knows nothing of this datatype. You'd need to write a wrapper that links to the OpenSSL libraries that does know about this datatype (by including the headers for OpenSSL) to contend with that on LabVIEW's behalf.
05-05-2016 06:12 AM
I currently trying to use Encryption Compendium For LabVIEW (it contains SSL connection VIs) but it uses nilibeay32.dll which is missing...
Do you have any suggestion how to deal with it?
libeay32.dll contains encryption functions which allow for coded communications over networks. I assue it is a part of OpenSSL but the Encryption Compendium For LabVIEW uses some kind of NI wrapper of that lib.
Error:
"Deploying ECL.lvlib:Rand.lvlib:Rand Add.viECL.lvlib:Rand.lvlib:Rand Add.vi loaded with errors on the target and was closed.
LabVIEW: Failed to load shared library nilibeay32.dll:RAND_add:C. Ensure that the library is present on the RT target. Use either MAX to install NI software or FTP to transfer custom libraries to the RT target."
05-05-2016 10:37 AM
I would contact lvs-tools to check to make sure that they support NI Linux RT targets. I can tell you that libeay is the older name for openssl, and while there is a libeay32.so.* on the NI Linux RT targets, I don't know what the nilibeay32.* library does (likely will do precisely what I mention: wrap some of the datatypes that are not native to LabVIEW).
05-05-2016 11:18 AM
bienieck wrote:
I currently trying to use Encryption Compendium For LabVIEW (it contains SSL connection VIs) but it uses nilibeay32.dll which is missing...
Do you have any suggestion how to deal with it?
NIlibeay32.dll/NIssleay32.dll are LabVIEW's buiild of the OpenSSL libeay on Windows. On NI Linux RT targets, LabVIEW uses libeay32.so and libssleay32.so, both of which are installed to /usr/local/natinst/lib/ by the "SSL Support for LabVIEW RT" package in MAX.
05-05-2016 03:08 PM
So libeay32.dll and nilibeay32.dll are funcionally the same? If so, lets assume that Encryption Compendium For LabVIEW will need libeay32.dll instead of nilibeay32.dll. If on MyRIO is libeay32.so and the lib calls libeay32.dll, does the extentions (.so/.dll) make difference during code deployment on MyRIO?