LabVIEW Network Library to support SSL, Ping and IPv6

[Rolf Kalbermatter]

I have in the past few months steadily worked on a network library for LabVIEW with following features:

- Be as close as possible to the functionality, operation and semantics of the built in LabVIEW library

- Support IPv6 operation

- Support SSL encryption

- Support ping operation right in LabVIEW (through use of raw sockets)

- and of course be better than the built in functions

The included library does most of these things already but will need some more work over the next few months to fully have all these features. As such it is clearly in a preliminary state and not yet ready for released software. Please be adviced that this library will cease to operate after end of June because I expect to have new releases out there before that time.

In spite of the preliminary state it does work and does do already quite a few things and it even implements the LabVIEW TCP read modes exactly as the native functions.

I have included an OpenG package of the library. To install it you best use the VIPM application from JKI Software as it will take care to place everything where it should be.

Due to some features I'm using it will be necessary to restart LabVIEW after installation of this library in order for the library to work properly.

When installed you should see a new ESI-CIT logo in the main function palette and in there a network icon. In that network palette are all the new and exciting functions. The functions have for a large part already some online help information inside, which you can see by opening the floating help and hovering over the icons or front panel control elements.

I'm working on an online help file to install along with the library but it is not yet finished. This help will also outline some of the more low level operations which at the moment may appear a bit obscure.

This release is only for Windows 32 Bit systems. Sorry to the Linux and Macintosh users but porting such a library is a true pain in the a** and especially for the Macintosh I'm not yet sure how to go about it, as there are several ways to skin that cat

The library will work in LabVIEW 7.1 and newer versions.

readme.txt

citlib_lvNetCon-0.9-1.ogp

[mpmurphy00]

I'm trying to make an application with SSL. This library looks great. Unfortunately when I open this in Labview 2010 I get some VIs that aren't executable; SSL Start Session.vi is one such example. For any inputs to the call library function node which are 'Adapt to Type', Labview is rejecting that wiring with "Polymorphic terminal cannot accept this data type". In this case these are where "security context" and "socket refnum" are wired in.

Does anyone know what the problem might be here? Has something changed in call library nodes or in the refnum types somewhere between 7.1 and 2010 that would create an incompatibility? I have no versions available beween 7.0 and 2010.

The call library function is using lvNetCon.dll, which I assume is a wrapper around OpenSSL. Is there a .h file for lvNetCon.dll around that I can refer to?

[asbo]

It's probably related to:

Please be adviced that this library will cease to operate after end of June because I expect to have new releases out there before that time.

[mpmurphy00]

Hrmmm, OK thanks for your input. Is there a newer version around? & How does this code simply 'cease to operate'?

Well the problem has cleared up, apparently due to closing and opening labview as instructed, which I thought I did previously but I must have been mistaken. Have a nice day.

[Rolf Kalbermatter]

It's probably related to:

Actually it's not! You are right that the shared library will refuse to work if your clock is set after June 2010 or so, by simply posting a dialog at runtime. But the reason of the original refnum problem is that this library makes use of so called user refnums. These are defined by resource files that get installed by the package and in order for those refnums to be valid the according resource files have to get loaded by LabVIEW, which it only does at startup (at least I'm not aware of any VI server method to do that at runtime too, like the refresh Palette method the VIPM uses after installation of a new package).

I'l be having a look at the library soon and see if I can do anything to resurrect it, but feedback has been very limited, so I was simply assuming that nobody was using it.

Please note that the SSL support of that library is really minimal. It allows to get an https: connection up and running but lacks any and all support to modify properties and access methods of the SSL context to change its behavior or for instance add private certificates to it.

[ShaunR]

Actually it's not! You are right that the shared library will refuse to work if your clock is set after June 2010 or so, by simply posting a dialog at runtime. But the reason of the original refnum problem is that this library makes use of so called user refnums. These are defined by resource files that get installed by the package and in order for those refnums to be valid the according resource files have to get loaded by LabVIEW, which it only does at startup (at least I'm not aware of any VI server method to do that at runtime too, like the refresh Palette method the VIPM uses after installation of a new package).

I'l be having a look at the library soon and see if I can do anything to resurrect it, but feedback has been very limited, so I was simply assuming that nobody was using it.

Please note that the SSL support of that library is really minimal. It allows to get an https: connection up and running but lacks any and all support to mo0dify properties and access methods of the SSL context to change its behavior of for instance add private certificates to it.

I think its extremely useful and well worth maintaining.

I noticed that in the readme you have a list of things TODO that I might be able to help with (would need the source and a bit of guidance though). The later versions of LabVIEW have SSL DLLs that might make things easier (from multi-platform point of view) although they seem very inflexible.

What is the licencing?

[jlaudie]

Rolf...I'm interested in using this for some ping testing I need to do on some switches and think this might do the trick. Has your development on this gone anywhere? I am using LV 2010 and am getting a fatal LabVIEW error when running the ping.vi example.

 

Fatal Internal Error: "CloseOperation.cpp", line 1479

LabVIEW version 10.0

You will lose any unsaved work. For assistance in resolving this problem, please relaunch LabVIEW, or contact National Instruments.

 

FYI...I installed with the JKI package manager.

 

Thanks,

Jim

[Rolf Kalbermatter]

Unfortunately I haven't found much time to work on this in the meantime. However while the ping functionality of this library was a geeky idea that I persuaded for the sake of seeing how hard it would be (and turned out to be pretty easy given the universal low level API of this library), I don't think it has much merit in the context of this library. In order to implement ping directly on the socket library interface one is required to use raw sockets which are a privileged resource that only processes with elevated rights can create.

 

I'm not seeing how it would be useful to start a process as admin just to be able to ping a device. And someone probably will argument that the ping utility in Windows or Linux doesn't need admin privileges. That is right, because that is solved under Linux by giving the ping utility special rights during installation for accessing raw sockets and under Windows through a special ping DLL that interfaces to a privileged kernel driver that implements the ping functionality. At least under Windows this library could theoretically interface to that same DLL, but its API doesn't really fit in easily in this library and I didn't feel like creating a special purpose LabVIEW API that breaks the rest of the library concept and only is possible under Windows anyhow.

[CosminRadu]

Hello Rolfk,

 

I installed the CIT library that you developed, because I wanted to use the TCP/IPv6 in Labview. When I tried to use the TCP Listener function Labview crashes with the error 0xA967C488.

I am using Labiew 2011 sp1 32bit and Windows 7 Professional on 64 bit.

 

Can you help me solve this problem?

 

Thank you.

Cosmin. 

[Rolf Kalbermatter]

Hello Rolfk,

 

I installed the CIT library that you developed, because I wanted to use the TCP/IPv6 in Labview. When I tried to use the TCP Listener function Labview crashes with the error 0xA967C488.

I am using Labiew 2011 sp1 32bit and Windows 7 Professional on 64 bit.

 

I'm sorry to inform you that the library as posted in the first post has several issues in the compiled DLL. Some are caused by newer LabVIEW versions, some by newer Windows systems and some are simply bugs that initially didn't cause issues for some reason. I'm at the moment busy with other work and can't immediately make this work. I do plan to revise the library to work on newer systems and fix some of the bugs but since this is a hobby project that I do in my spare time, this will not be a high priority.