Directing TCP Open

[Cat]

Is there some way to tell LabVIEW to open a TCP connection from a specific IP address (or NIC) on the client computer -- something like the "net address" field in "TCP Create Listener" on the server side?

 

Cat

[ned]

No. You'll need to tell the operating system what the preferred route is to the server. In Windows you can set network priority so that it will preferentially use a particular network card (for all connections), or use the command-line "route" command to set up a route specifically to your destination. You could do a system exec call to set that up before opening the TCP connection. I had to do something similar with a device that insisted that its MAC address be manually added to the arp table before it could communicate.

[dannyt]

As has been said you want to play around with the routing table on a windows machine.

 

Read up about the net route command  https://technet.microsoft.com/en-gb/library/bb490991.aspx and windows routing in general, you will need http://serverfault.com/questions/510487/windows-get-the-interface-number-of-a-nic to get the if interface for the route add. 

 

I have PC's fitted with two NIC I ping out of NIC 1 to an IP wireless device across to air into another IP wireless device and then back into NIC 2 on the same PC. I can also with this setup do Iperf across the air and telnet out the each NIC as desired. Without setting up the routing table correctly, I would in truth just ping and Iperf across the backplane of the PC from one NIC to the other, but the routing ensures I go out one NIC.

 

I do all this with LabVIEW and net route commands issued as system exec calls, it works well. I tend to delete all all routes and then set up my own. If you do this remember to alos add in a route to your network for the main PC LAN or you cannot get to internet or local server :-)  

 

Also note if any NICs are disabled or enabled, Windows will try and be clever and sort out the routing as it see's fit and break your rules, so to help overcome this I nearly always have a simple powered dumb Ethernet switch hanging on the NIC between my test device and PC, then if I power off my test device to NIC still sees a good active connection to something.

[Cat]

Thanks for the info and the links.  I ran into an oddball situation on one of my computers that has 5 NICs.  I wasn't using the "usual" NIC to talk to a bunch of other computers,  in fact the NIC I was using was the only one connected to anything, and it was taking forevvvvverrr to make connections.  I found two solutions, 1) attach "usual" NIC to another network, and 2) disable "usual" NIC.  But it sounds like I may have just gotten lucky with that last one.

 

This isn't a standard way I run my systems, but it made me wonder why there's not a client side "net address" in LabVIEW.

[Rolf Kalbermatter]

The reason there isn't is that it is usually not necessary. Binding a client socket to a specific network card address is basically a fix of a problem that should better be resolved in the routing configuration. For generic clients like a web browser you can't usually specifiy to bind to a particular network address either. It requires from the end user knowledge about the network configuration on his computers that you want to avoid whenever possible.

 

If the routing tables are correct and the subnet ranges for each network adapter configured properly the packets should be routed to the right network adapter based on the destination address. If you have overlapping subnet ranges and those network cards are not logically connected to the same network you will of course run into problems that the routing may choose the wrong adapter. Same about if there has been set up a to large subnet range for a network adpater. It may capture all the packets that should really go to the default adapter.

 

Depending on the network card driver Windows may have trouble to determine that a specific adapter is not connected at all to any network and may still use its configuration in the routing of packets making them land in the adapter queue but because of the disconnected state they will never leave the computer.

[dannyt]

Again to stress one thing I mentioned in my post.

 

I have really found it to help to have all NIC's always in an ACTIVE state, the nice green link on light lit and that is why for £10-£50 I stick a cheep powered switch on the NIC, something like a Netgear GS105UK 5 port.

 

It seemed to me that if you just hung something like a UUT straight off the that was not always power on, the powering on and making the NIC go from inactive to active made windows do "things" that sometimes meant thing did not work as expect or just take a damn long time, Windows XP seemed better than the newer version.

 

Install and play with Wireshark it can help tell you what is going where