TCP Open Connection Times Out - How else to TCP/IP?

[Wiredup]

I'm trying to open a connection to a specific port and IP address. However, the device at this address will only respond if it is given a very specific command. The TCP Open Connection VI just times out (as it probably should!).

Is their a way I can get a specific message to this IP and port number without going through TCP Open Connection?

Thanks in advance!

[Johnner]

You should verify that everything is as you believe on the server side. I think the only reason you'd get a timeout when using TCP Open Connection is if there is no listener (i.e. no active server process) at the address and port that you specify. The connection has to be made before any discussion of commands is relevant.

Try using the telnet tool that your OS provides in an interactive manner. If, for instance, you type "telnet www.ni.com 80" in Windows, you'll see that the screen blanks out, indicating that you've made a connection to NI's Web server. If you try port 81 instead, you'll get a timeout, as you are getting in LabVIEW, because there's no server at that port.

--John

[Wiredup]

Thank you for the quick reply.

Unfortunately, I know this box on the other end will remain absolutely silent unless I hit it with just the right bytes on my first attempt to connect. I also know it does respond when I hit this box with the right information - just not with MY application! The problem is, I don't know how to get these specific bytes to the machine at this IP/port without a RefNum from the TCP Open Connection vi!

[tbob]

Correct me if I'm wrong. It sounds like you cannot just open a TCP/IP connection to this server the regular way. You have to send it some specific information before it will respond. Right? If so, then using the Labview TCP Open Connection vi times out because it doesn't see a reply to the open command. If this is the case, you will either have to have the server changed so that it does respond to the open command. If this is not an option, maybe you could write, or have someone write, a low level application to send the correct information to the server while opening the connection. If such an app is written, it could be transformed into a DLL which you could call with labview. Good luck with this one.

[Wiredup]

Thanks for the suggestion. I'm currently wading my way around the .NET TcpClient class to get this working - not used to working down at this level!

[altenbach]

Do you have the exact specifications on what the server expects?

Typically, the threeway handshake for TCP connections (SYN, SYN/ACK, ACK) must be complete before data can be sent. The server MUST respond with a SYN/ACK packet no matter what.

Could it be that the server expects certain IP or TCP options in the initial SYN packet???

Are you sure this is TCP? Could it be UDP? Since UDP is a stateless protocol, it would be more natural to be used to send one-sided data since no connection needs to be established.

Could you hook up a packet sniffer and record a communication exchange using a working client and post it here? I would be very curious to see what is happening on the packet level.

[Wiredup]

My packet sniffer does not report Header comm - sorry 'bout that!

I have concluded, though, that this box is UDP only and does not respond to any connection attempts unless they are formatted in a very specific way (4 specific bytes - no more and no less with exactly the right values). Then, if these are all correct, it will repy back with message - but in a proprietary format to the box mfr. If these are not just right, the box remains completely silent.

Without your message about TCP comm handshaking I'd probably still be trying to TCP to this box! Thanks for your help.