Why can I use a vi with TCP/IP connection to connect to a Switch but I can't use to connect to a linux machine?

[Eduardo Ellery]

Using TCP/IP connection functions to comunicate with a Switch is perfect, but when I use it to comunicate with a Linux and Unix server, I got only this as answer:
yyyy yy#yy'

What is happening??

[LVite]

Hi Eduardo,

I know this message is fairly old, but it looks like nobody answered. Did you ever get this to work? I'm having the same problem. Thanks.

Justin
jflory@symmetricom.com

[altenbach]

Could you clarify what you are trying to do?

How do you connect? What port? What service? TCP or UDP?

A switch is a bridging device, do you mean you connect to the server via a switch or do you connect to a managed switch for configuration (e.g. via telnet)?

Can you give the exact server response in hexadecimal (or '\'-codes)representation? It could be anything, but almost looks like a telnet options negotiation offer by the server.

[LVite]

It turns out that I was establishing a good TCP connection with the Linux box but I was failing to properly negotiate the telnet parameters (terminal type, etc.) as was being requested by the Linux box. This is why I am not receiving the login banner. The characters I was seeing were ASCII representations of the data packets in the telnet negotiation. I'm diging through the telnet RFC right now so that I properly negotiate the session.

Do you know how to set any of the TCP flags in LabVIEW: Acknowledgement, Reset, Push, Syn, Fin. So far I can only send data with the TCP write vi. The TCP Open Connection and Disconnect vi's do all of the flag setting during the creating and termination of the session, and since I cant view the source for those vi's I'm at a loss...

Thanks.

Justin

[altenbach]

You don't need to worry about the details of the TCP connection (Threeway handshake, TCP flags, etc.) This is all taken care of by the OS. Don't think in terms of packets, but in terms of a connection. Don't worry about the transport layer, this is all handled automatically behind the surface.

You have only access to the packet payload, not the packet header.

Only once a TCP connection is established, data can flow, for example the telnet options negotiation. (Have a look at this old thread). If you get the negotiation information, the TCP connection has been successfully established.