Ping Ping Ping - Native Win2k/LV7 code

[rolfk]

---

Dreamer67 wrote:

Well, nice library.
 
I tried it on Vista32/LV82 and it does not work.
*SOCKET create.vi* make always *INVALID_SOCKET* Error.

If I know how to fix, I will report here.

---

All Versions of Windows since at least Windows 2000 do not allow creation of raw sockets unless you have administrator privileges. So you need to be logged in as administrator or your user name needs to be part of the local administrator group. That said Vista increased many security requirements, such that being administrator is not enough anymore (installing software or services and device drivers) but the application who wants to do that needs an explicit elevation when started (meaninig it needs to be started with the administrator credentials explicitedly eventhough you are already logged in as administrator).

Not sure if creating raw sockets also belongs to this category but there is a really big chance for that.

Message Edited by rolfk on 03-28-2010 01:16 PM

[Mark_Yedinak]

Shameless plug. Go vote for this idea (Native LabVIEW ping) in the Idea Exchange.

[rolfk]

---

Mark Yedinak wrote:
Shameless plug. Go vote for this idea (Native LabVIEW ping) in the Idea Exchange.

---

There is one problem with this suggestion. Ping requires ICMP packets and implementing them in user space requires raw socket access. On all modern OSes this requires special privileges for the process wanting to do that.

For Windows this is according to this that the current user needs to be member of the administrator group or the process needs to be invoked with credentials for a member of the administrator group. There is the earlier mentioned registry hack that should at least work for Windows 2000 and XP, and maybe also Vista and Win7, but for production floor setups this is probably just as unacceptable than having the software run as administrator. It opens a virus or trojan just about any access to the network and using private network protocols that can be very hard to track down.

For Linux the process trying to access raw sockets needs to either have an effective ID of 0 (created with the suid command) or have the capability CAP_SOCK_RAW.

So even if LabVIEW had a native ping function, it would not work for most production style setups at least on the desktop systems. I assume that the RT systems do not have that kind of security since they do not really have any type of user accounts either.

So by implementing ping support natively in LabVIEW, NI would have to educate people about the limitation and risk an extra support issue anyhow, since who in the world does read the documenation that came with a software program anyhow?

Message Edited by rolfk on 03-28-2010 10:31 PM

[Mark_Yedinak]

---

rolfk wrote:

---

Mark Yedinak wrote:
Shameless plug. Go vote for this idea (Native LabVIEW ping) in the Idea Exchange.

---

There is one problem with this suggestion. Ping requires ICMP packets and implementing them in user space requires raw socket access. On all modern OSes this requires special privileges for the process wanting to do that.

For Windows this is according to this that the current user needs to be member of the administrator group or the process needs to be invoked with credentials for a member of the administrator group. There is the earlier mentioned registry hack that should at least work for Windows 2000 and XP, and maybe also Vista and Win7, but for production floor setups this is probably just as unacceptable than having the software run as administrator. It opens a virus or trojan just about any access to the network and using private network protocols that can be very hard to track down.

For Linux the process trying to access raw sockets needs to either have an effective ID of 0 (created with the suid command) or have the capability CAP_SOCK_RAW.

So even if LabVIEW had a native ping function, it would not work for most production style setups at least on the desktop systems. I assume that the RT systems do not have that kind of security since they do not really have any type of user accounts either.

So by implementing ping support natively in LabVIEW, NI would have to educate people about the limitation and risk an extra support issue anyhow, since who in the world does read the documenation that came with a software program anyhow?

Message Edited by rolfk on 03-28-2010 10:31 PM

---

Thanks Rolf for the iodination information. Though I suspect that NI could develop the necessary framework around such a feature that would allow it to work in an environment where the specific user does not have administrator access yet can still send a ping packet. Linux systems have the concept of certain services being allowed to run as a different user with different permissions. From NI's perspective they would not have to expose the socket itself to the application. The ping library could wrap that into a very restrictive set of VIs with minimal to no user level access. I still believe that this would be a useful feature for LabVIEW programs. I would also like to see NI provide the ability for access to raw sockets so that it would be possible to implement protocols other than TCP (and UDP). In this arena I would expect all the necessary security checks to be in place to allow it to function but since I live in the networking domain of the world there are times when I would like to write LabVIEW code that implements other protocols. This level of functionality would make it much easier for me to automate some of the networking tests that develop.

[rolfk]

The only way to go around the windows limitation for raw sockets is to create a service or device driver that needs to get installed. This could be part of the LabVIEW or LabVIEW runtime installer which AFAIK needs admin privileges anyhow to do all its work. BUT: it would be one more NI device driver/service to get installed, and honestly I do not like the amount of services (last time I counted on my machine 18 services and some  a few more kernel device drivers) and device drivers that gets installed already. It's that I still have some trust into NI that I didn't start to clean them all out already.

[Mark_Yedinak]

I could envision this as a separate toolkit. This would only install and run the service for those who need it. I have long hoped that LabVIEW would become a fully functional general purpose programming language. While it is nearly there it is items such as this that will prevent it from fullfilling my dream. Some day though.

[rolfk]

Well just to let you know: I'm currently testing a self developed VI library (and DLL) that implements a very similar interface as the LabVIEW networking nodes. It has however a few additional features:

- support of IPv6 (can be disabled when creating a socket)

- access to raw sockets (with the OS security restrictions)

- ICMP echo request/echo reply VIs based on above mentioned raw sockets

- almost seemless support of SSL/TLS encryption for both client and server connections (with use of OpenSSL)

- same 4 mode operations for TCP Read as the LabVIEW function has

Currently I'm testing under Windows the basic operations for TCP/IP, UDP, and ICMP and it seems to mostly work already. I also have SSL/TSL over TCP/IP working to the extend that I can access HTTPS content as long as the HTTPS server does not require a SASL mechanisme as part of the SSL/TLS handshake. It also should support the STARTTLS command for SMTP,POP3 and IMAP protocols but I haven't tested that yet.

Other platforms like Linux and MacOS X (but also realtime targets) have been kept in mind while developing the shared library which supports this all, but I haven't started to do any tests with them yet.

Theoretically its raw socket access would allow to create VIs for just about any protocol although I have a feeling that building network packets for raw socket access in LabVIEW won't be necessarely as performant as you can get using more low level programming environments like C.

The library is mostly tested in LabVIEW 7.1 for Windows since that works for me better to do source level debugging, but it could most likely be backsaved to versions down to 6.0 or 6.1.

I'm considering to give this library to interested people for testing but do currently not feel it is stable enough for production quality systems. Also I'm not currently sure how the final product will be distributed but giving it away for free does not really feel right at the moment.

Message Edited by rolfk on 03-29-2010 04:07 PM

[Mark_Yedinak]

Rolf,

That sounds like a nice library. If you don't mind you can add me to the list of interested people. I have had the need to support IPv6. In addition, there are a few others protocols that I could use which would extend my automation capabilities. I wrote an SNMP library on top of the current UDP VIs so I am no stranger to building and decoding packets. If you are careful with the implementation you can get good performance.

[Ramachandraiah]

I ran "Raw Socket Ping.vi" and I got an Error saying that Failed to create raw socket.

Please tell me how to proceed further to use the library properly to solve my issue.

Thank you,

[rolfk]

Only elevated processes are allowed to create raw sockets since Windows XP or so.