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

[Anthony_L]

Hello rolfk and altenbach:

Thanks for your useful advice

My customer is in India (Mumbai) and have days off on Friday. So I was not able to follow-up to verify things. At this point we have decided to move the LabVIEW desktop App from the old rack PC to a newer laptop and we will see how things turn-out.

But here is what is known for sure:

1. I already did ipconfig and it pulls both IP addresses namely:  192.168.1.188 and 192.168.1.111  the latter is the GHOST IP address. I had yet to check which adapter is assigned  to the ghost address 192.168.1.111. So windows OS does see that address.

2. LabVIEW TCPIP VI that lists multiple configured IP addresses only sees the 192.168.1.111 (Ghost IP) and it does NOT see the 192.168.1.188 (Proper IP). It is simply not in the array list.

3. Again: IP Address 192.168.1.188 is the one that needs to be used because it is assigned as static IP address to an actual physical adapter,  Bute, Yes, LabVIEW FAILS to see it!

4. A third party communication tool called HERCULES has a TCPIP client that works perfectly and is able to read and write to cRIO from that same OLD rack PC

here is a link to Hercules tool: https://www.hw-group.com/software/hercules-setup-utility

5. My LabVIEW app that seems to insist on using the GHOST IP address is only able to connect to cRIO TCPIP TELENET server, but the LabVIEW TCPIP read VI sees NOTHING coming back.

Now: Just the fact that LabVIEW TCPIP VIs are unable to pull BOTH IP Addresses and worse LabVIEW TCPIP VIs insist on defaulting to use the GHOST IP address has me very, very, concerned on the integrity of the LabVIEW TCP/IP VIs. 

At this point we have a simple case where: A 3rd Party utility with a client TCPIP module has beaten LabVIEW in connecting and reading data from a PC with a Virtual IP address anomaly.

So I am indeed contemplating on changing out the LabVIEW TCPIP client and using a third party professional .NET TCPIP component to program my desktop app; because here it seems LabVIEW TCPIP VIs are not that reliable when it comes to handling a HOST with multiple IP addresses with some of those being Virtual IP Addresses.

I will let you know further what transpires from here.

Anthony

[billko]

---

@Anthony_L wrote:

<snip>

At this point we have a simple case where: A 3rd Party utility with a client TCPIP module has beaten LabVIEW in connecting and reading data from a PC with a Virtual IP address anomaly.

So I am indeed contemplating on changing out the LabVIEW TCPIP client and using a third party professional .NET TCPIP component to program my desktop app; because here it seems LabVIEW TCPIP VIs are not that reliable when it comes to handling a HOST with multiple IP addresses with some of those being Virtual IP Addresses.

I will let you know further what transpires from here.

Anthony

---

Don't you think a LaBVIEW deficiency of this magnitude would have been noticed by more people than just yourself?

[altenbach]

• It would still be nice if you could show the actual output if "ipconfig /all" and "route print". Maybe there is a subtle conflict. (We once had a network interface where the MAC address cleared (all zeroes) due to some corruption).
• Are there possibly any duplicate IPs or MAC addresses on the subnet?
• How are all things connected?
• Did you try a different cable of known good quality?
• Does it make a difference if you run the program as admin?

[Anthony_L]

Hello billko:

I have used LabVIEW TCPIP TELNET client for years since 2010 and I just found out about this anomaly. And it happened 10,000 km away in Mumbai after everything was QC'd OK here. So there is always a first time when things are caught, isn/t there?

It could also be related to the use of an older PC with other issues going on. So a rare combination of things may have caused this.

Bottom line though the facts that cast doubt on LabVIEW TCPIP Vis are clear and upfront:

-- LabVIEW sees only the GHOST IP address and can connect but can't read/receive any data, while a third party tool works just fine. 

    Both are fed with just TELNET server IPAddress to connect-to and Port#. And they perform differently.

-- Also OS ipconfig sees all IP Addresses, including the Ghost one, while LabVIEW sees only the Ghost IP address.

billko: What conclusion would you draw here? 

Anthony L.

[Anthony_L]

Altenbach:

Thank you for further suggestions: Here are some answers:

1. I will do that once I get permission to access the PC from my India client. I will run and submit DOS window results for: "ipconfig /all" and  "route print".

2. Are there possibly any duplicate IPs or MAC addresses on the subnet? I do not know how to detect this, but probably those other commands above will give info on this?

3. The PC was connected via a hard ethernet cable to the cRIO. But as stated earlier. a third party tool: HERCULES run from same setup worked OK.

4. Different cable? See Answer to question 3. If cable was the issue that 3rd party tool would behave the same. But that tool just worked!

5. The LabVIEW exe is certainly set to run as admin. Else, it cannot write to its own files.

6. BTW: Windows Firewall was disabled. Fully disabled.

Anthony L.

[altenbach]

I assume you use "string to IP" somewhere in the code. Can you make sure that string is clean and does not contain any stray hidden characters. (Switch to \-code to inspect) For example if there is a hidden linefeed at the end, the IP will translate to zero (U32) and things will not work.

[billko]

---

@Anthony_L wrote:

Hello billko:

I have used LabVIEW TCPIP TELNET client for years since 2010 and I just found out about this anomaly. And it happened 10,000 km away in Mumbai after everything was QC'd OK here. So there is always a first time when things are caught, isn/t there?

It could also be related to the use of an older PC with other issues going on. So a rare combination of things may have caused this.

Bottom line though the facts that cast doubt on LabVIEW TCPIP Vis are clear and upfront:

-- LabVIEW sees only the GHOST IP address and can connect but can't read/receive any data, while a third party tool works just fine. 

    Both are fed with just TELNET server IPAddress to connect-to and Port#. And they perform differently.

-- Also OS ipconfig sees all IP Addresses, including the Ghost one, while LabVIEW sees only the Ghost IP address.

billko: What conclusion would you draw here? 

Anthony L.

---

The conclusion I would draw is that something was wrong with my code, or something was wrong with the PC that it was installed on, in that order, then LV.

I guess I didn't take into account that you already did the first two.