Labview 2015 NI Instrument Driver Finder complains about not being connected to the Internet


Whenever trying to use the “IDFinder” Labview 2015 facility on an old Windows XP computer, after a couple of seconds trying an error dialog message pops up saying: “NI Instrument Driver Finder has encountered problems connecting to the instrument driver network. Please verify that your computer is connected to the internet and try again.” The computer is connected to the Internet and it can browse the NI website by using a regular Internet browser.

Capturing some traffic

We re-route all the traffic from that client computer to a GNU/Linux laptop running Wireshark, capturing all the traffic generated when the user clicks on the Driver Finder menu option to show the IDFinder window until LabView shows the error:

1 0.000000000 SSLv2 Client Hello
2 0.167900000 TLSv1.2 Alert (Level: Fatal, Description: Protocol Version)
3 0.168016000 TCP https→argis-te [RST, ACK] Seq=8 Ack=82 Win=9811 Len=0

 So according to the previous capture, Labview tries to connect to the NI server ( through an HTTPs connection using the SSLv2 protocol (frame: 1). Next, the NI server sends an ALERT message because it does not allow the connection to be established due to this vulnerable protocol version (frame: 2). Finally, the NI server ReSeTs the connection and LabView throws the “connection error” message (frame: 3).

Supported Windows XP HTTPs protocols

According to this:, Windows XP does have support for TLS v1.0, but not for TLS v1.1 or TLS v1.2. Of course TLS v1.0 is vulnerable, and no server should be using it. But still. So we enumerate which TLS protocols the NI server supports:

~$ nmap –script=ssl-enum-ciphers.nse -p443
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| TLSv1.1:
| TLSv1.2:

Perfect; it does have support for TLS v1.0. So the problem here is that LabView is using SSLv2 instead of TLS v1.0 on the Windows XP computer. LabView uses IE API behind the scenes in order to connect to the NI website, so it seemed obvious that the issue could be solved by ensuring that IE had the “Use TLS v1.0” option enabled. We went to “Control Panel / Internet Options” and the “Use TLS v1.0” was unchecked. We enabled it and tried again; this time the IDFinder worked perfeclty fine. So far, because at some point we expect NI to remove TLS v1.0 and TLS v1.1 protocols altogheter.

My suggestions have been clear: time to retire that old Windows XP computer and use a newer one, with at least an OS that has yet to reach its EOL.

Some comments on TLS/XP

Now the worrying thing about it all. We do know Windows XP is like a gruyere cheese, full of holes. We do know neither TLS v1.0 nor TLS v1.1 should be used. But hey! They still are. There are hundreds of Windows XP computers out there, because they cannot be replaced with modern hardware. And there are thousands of websites still running on TLS v1.0 and TLS v1.1. NI server should NOT be using TLS v1.0 or TLS v1.1, and our laboratory should NOT be using a Windows XP computer. Suffice is to say that shit happens. Full stop.