LabVIEW
Deprecation of Internet ToolKit .... so no more Telnet support
A slight correction, you don't use VISA Raw but rather VISA TCP for this. Personally I do not like VISA TCP much since it adds a quite complex extra runtime install to the application build while the native TCP nodes do a just as good job to talk to networked devices and come without extra runtime installer.
VISA TCP has however one big advantage if you try to talk to a measurement device that besides TCP also has RS-232, USB, and/or GPIB interfaces. That way you can usually very easily write a single driver that works for each of these interface options equally without having to do anything specific other than using the appropriate resource string when initializing the device connection.
To open a VISA TCP connection you would specify a resource string of the type "tcpip::192.168.0.100::6543::socket"
If the device is a measurement class device (often called VXI-11) you could also use "tcpip::192.168.0.100::6543::instr".
While Telnet is still a feasable solution for use on internal networks that have no exposure the the internet, use of telnet communication over a public network definitely should not be done anymore. Everything in the telnet protocol is out in the wild and anyone can take control of devices that have a telnet connection. There is really not much to protect such devices other than a login which is send in full clear text.
NI hasn't taken away the Internet Toolkit. They simply changed it from a paid and supported Toolkit into a free and unsupported Toolkit, since they do not feel that these protocol implementations have much of significance in an industrial environment of the 21st century. If you need to use Telnet you can still use the functions in the now free Toolkit.
Just don't blame NI if your device gets hijacked by some hacker 
@danny_t wrote:
Hi,
As Rolf said, to login I use the VISA open with a resource string of the type "tcpip::192.168.0.100::6543::socket" I can set my TermChar to match the system prompt from by telent server. My telent server needs a user and password simply write them in and away you go, PM me again and I can send you a login VI example.
As also said you do need to have the VISA drivers installed but as I use GPIB and Serial as well this is not an issue for me and the fact that I can now run parallel telnet sessions now is a big plus for me and to be honest it it seems more reliable that the Telent Toolkit.
Rolf while I agree with your comments about Telent security and the future, there are still a large amount of devices, routers, switchs etc that have telent control but no SSH nor webpage control and that is not going to change overnight. For ourselves we remove all telent support from shipped products and it is only available in our production environment.
I think you are being a little generious to NI over the Telnet Toolkit which even when a paid for Add0n was far from the best example of well written LabVIEW had a number of outstanding CAR on it, it felt abandoned even before it was officially anounced unsupported.
If the toolkit was being replaced by something to support these 21st Centry protocals I would feel a lot happier, like this for example.
Well support of SSH and SFTP is a little bit more complicated. Implementation of the SSL and other encryption technology in native LabVIEW is definitely not a solution since there is a way to small LabVIEW user community who also understands encryption technology to be able to do some useful peer review of such an implementation. And to expect NI to develop that on their own is simply not realistic, they are not in the business of developeing security software itself. Even bigger fish who are specifically working in the security industry have messed up numerous times in the past, so a solution developed by NI is simply not going to cut it. Besides encryption technology is heavy number crunching which is not something that you want to implement in LabVIEW native anyhow as it is very performance critical as well as error prone.
So that leaves the solution of incorporating OpenSSL or another similar product into a library that implements these protocols. NI has shown how to do that with the HTTP client VIs which do work but leave some things to desire for. I've worked on a library in the past which I put a proof of concept on LAVA which would have added SSL/TLS support to a new version of TCP (and even UDP) functions and would allow to implement SFTP and even SSH on top of it. The library was designed to be an almost one to one drop in replacement for the native LabVIEW network fucntions. Personally that approach would be what I would consider a good way of overhauling the LabVIEW network functions. Along with that they could also incorporate IPV6 support at the same time, which my library had too.
The Telnet protocol itself, just as FTP and others like it are not really that complicated. The development of them on top of VISA TCP or native TCP is fairly straightforward. While VISA supports some additional things like configurable termination characters, it has certain things that make implementation of arbitrary network protocols often more complex than using the native TCP functions. And there is no VISA UDP so in that case you end up using native functions anyhow.
I have considered reviving my library but the development of such a thing is very time consuming. And me being who I am would like to make it support more than just Windows (ideally every LabVIEW platform out there) which makes it a huge undertaking. 
