LabVIEW TCPIP VI sees Different (GHOST) Static IP Address for a Network Card

[Anthony_L]

Hello:

A  PC hosts a network card connected to cRIO 9063 via an ethernet cable. The card address is configured as static IP address 192.168.1.188. However, when reading back the Static IP addresses on that same PC,  LabVIEW sees a Ghost Static IP address of: 192.168.111.

Looking at all the cards from Control Panel Adapter Settings there is no card that has the 192.168.111 IPv4 address. I even checked to see if that same card has multiple IP addresses assigned and the IP address 192.168.1.111 is no where to be found!

Both IP addresses 192.168.1.188 and 192.168.1.111 can be pinged. But the 192.168.1.111 remains as a GHOST IP address.

If I go to the card that was configured as: 192.168.1.188 and change that card IP address to be 192.168.1.111 so that LabVIEW sees just one static IP address, that card becomes non functional. e.g: the card cannot be pinged and the card can no longer ping any other device.

QUESTION IS:

So where is the IP address 192.168.1.111 coming from? At present when I try to connect to cRIO, I get connected OK but data is not transferred to the LabVIEW APP. However, if I use Hercules HWD, which is a third party TCPIP Client tool to connect to the same cRIO 9063, I get all the data transferred just fine.

 https://www.hw-group.com/software/hercules-setup-utility

So why is LabVIEW able to connect to cRIO 9063 and yet receive no data but the third party tool can connect and receive data OK? I am assuming here that LabVIEW connects using IP address 192.168.1.111 but data is sent back by cRIO to 192.168.1.188 and hence LabVIEW does NOT see that data --although the TCPIP connect VI says connection was successful.

Attached is the LabVIEW VI block diagram that reads the PCs IP addresses and which sees IP Address 192.168.1.111 but fails to find the configured Static IP address of 192.168.1.188.

This issue has caused my LabVIEW App and cRIO APPs to fail to work together. TCPIP connection is established but data is not transferred back.

Regards

Anthony L.

[altenbach]

Open a command prompt and type "ipconfig -all". Anything interesting?

Have you tried searching the registry for "192.168.1.111" (I assume your use of 192.168.111 is a typo).

I also don't quite understand your LabVIEW code. Is there a possibility that you ever get an empty string in dot notation?

I typically just do as follows:

[Anthony_L]

Hello Altenbach:

Thank you for replying. Here are some notes:

1. Yes, I do sometimes get an empty string from calling mutiple IPaddresses using those TCPIP VIs. My code was just like yours and at some point I started getting empty strings!

2. When I do ipconfig I do see the GHOST IPAddress: 192.168.1.111, along with the configured static IP address: 192.168.1.188

3. No. 192.168.1.111 is not a typo at all. As you can see it comes under IPConfig and yet there is no card device listed in control panel configured for 192.168.1.111

4. As noted earlier 192.168.1.111 can infact be self  pinged and so can 192.168.1.188. The ping reply string contains no packet losses.

*** I spent hours troubleshooting with customer and later decided to change to another PC and voila! Everything worked OK. And indeed, for that other PC, the IP address seen by those TCPIP Vis was the same as the one configured for static IP Address.

This product was shipped from here after testing on two separate QC laptops and connection to cRIO 9063 was no issue at all. 

One big let down, is that Hercules HWD works OK despite the IP address confusion. 

---Hercules TCPIP client tool connects to a TCPIP listening Server OK, and reads OK.

---While LabVIEW TCPIP connects OK,  but the subsequent LabVIEW TCPIP Read VIs get nothing!

I can only assume that while LabVIEW connects via  GHOST IP address 192.168.1.111, the return data stream comes via the Static IP Address 192.168.1.188 which LabVIEW does not recognize. And hence LabVIEW APP sees no return data.

Anthony L.

[altenbach]

---

@Anthony_L wrote:

3. No. 192.168.1.111 is not a typo at all. .

---

(In two places you typed 192.168.111 instead of 192.168.1.111. That was a typo, I assume.)

Does the adapter use some old third party driver? Have you tried uninstalling all network adapters from the device manager followed by a "menu...action..scan for hardware changes" to restore them? Maybe something got corrupted in the driver. Is this a network adapter on the motherboard? 

Does the computer have an unusual security software installed ( e.g. something that inserts itself to monitor web traffic?)

[Anthony_L]

Hello Altenbach:

Ooops! 192.168.111 was a TYPO sorry! It was supposed to read: 192.168.1.111

Good suggestions. The security software is a good proposal because the 192.168.1.111 seems to be a virtual IP address. Windows 10 OS sees it too under ipconfig.

The customer says the PC is an OLD 'Rack PC' with multiple network cards. I can see 4 of them in control panel but only two from pic attached here. And I could never find IP address 192.168.1.111 configured for any of them. I am assuming that those cards are plugged-in NIC cards in motherboard interface slots. 

I even looked under advanced properties. See screen shot. Just to be sure and nothing was found for additional IP addresses on each card listed in control panel.

Thus 192.168.1.111 remains as a complete GHOST address.

Anthony 

[billko]

Can you look at Device Manager to see if you have any virtual interfaces defined?

[altenbach]

This PC really looks quite old so they probably upgraded it to Windows 10 at one point. Maybe some of the hardware is not fully compatible?

[LLindenbauer]

Try checking "msinfo32" or "ipconfig /all" to see more information on installed adapters (see e.g. https://www.maketecheasier.com/view-network-adapter-details-in-windows/ )

This really seems more like a sysadmin question than a LabVIEW question. Since You seem to be looking for information on the Network Adapter identified by your ...111 IP, searching with these terms may get You further along. Note that virtual adapters are a thing - maybe it's a virtual machine they installed? You can have many IP addresses on a computer without having any physical adapter at all.

[altenbach]

Even with virtual adapters present, the routing should work just fine unless there are misconfigured or overlapping subnets.

I assume the two physical adapters are on separate networks and there is no fancy driver that combines the two, e.g. for traffic shaping.

Can you do a "route print" at the command prompt and show us the result?

Are there any errors in the system logs related to this?

[rolfk]

You can go and do all kind of guessing and let us know things piece mail, but one definitely helpful thing mentioned here already you did not seem to do yet, or at least failed to post the result for.

Do in a command line window "ipconfig /all" and show the result of that. This will tell you what kind of adapter has this IP address configured. Most likely it is a virtual network card. My VMWare installation creates two of them. Windows might create also one or more depending on the network/firewall configuration, for instance if you configure multiple network ports to be bridged.

It's most likely a particular network configuration from your client and has nothing to do with LabVIEW. LabVIEW simply uses the Winsock library and anything beyond that is Windows network management related.