labview TCP to replace telnet

[jackson_thom]

Hi,  i face strange issue with using labview TCP function.

im trying to communicate with my DUT, in manual way we will use telnet or putty to just telnet 192.168.1.1 

then type user name, hit ENTER

type password, hit ENTER

then we can send command and see the feedback to configure the DUT.

i had tried 3 different telnet client, command prompt, putty and Procomm, it work perfect as expected, only labview TCP have problem, i attached the screen shot of command prompt,

i truely dont understand why labview TCP READ will return ÿýÿý ÿý#ÿý'  instead of login: or Password:

the TCP write does not give error, however i have no way to verify whether it is ok if i cannot TCP READ anything.

i did some google search, many people say TCP is direct replacement for telnet, local national instrument staff also said TCP VISA can replace telnet. i may had missed out very simple settings or something, but i could not figure it out.

do you guys seen such situation before? please help

Thank you

[550nm]

Hi Mr_Chin,

I think the characters you are reading are Telnet command characters sent by the DUT which is expecting a partner who will implement the Telnet protocol.  I recommend using Hyperterminal to connect to the DUT; use the "Microsoft Message Analyzer" (W/provider="Microsoft-PEF-NDIS-PacketCapture") to watch the messages passed back and forth.  It's possible to open a "raw" TCP socket and emulate a Telnet device (I've done it); the Telnet protocol is well documented!

Cheers.

[550nm]

FYI:

In this thread you'll find a link to an LLB called LV_COMM.llb.

The "Dvr.MCD.vi" lets you open a connection, send strings and receive responses from a telnet host.

Dvr.MCD.vi spawns a process (Dmn.NVT.d.r.vi) to manage the connection.

I'm not recommending that you use this code!  I only mention it because it does demonstrate how Telnet is built on a "raw" TCP socket.

Cheers!

[crossrulz]

If you read through the RFCs for Telnet, there are a bunch of option codes.  It is likely the server is expecting a confirmation of the options before allowing for the login process.  If you set your string indicator to Hex format and post that information, I can give better explanation.

[jackson_thom]

Dear Crossrulz,

i set to HEX and it show this

FFFD 18FF FD20 FFFD 23FF FD27 

and this output only appear when i try to TCP write the "login name" after TCP open connection;

if i directly TCP read after TCP open connection, it will display nothing.

[crossrulz]

Just for fun, try sending 0xFFF1.  This will send a NOP command.  But it might be enough to have the server start to look at your data.

0xFFFD18 = DO Terminal Type (refer to RFC1091)

0xFFFD20 = DO Terminal Speed (refer to RFC1079)

0xFFFD23 = DO X Display Location (refer to RFC1096)

0xFFFD27 = DO New Environment Option (refer to RFC 1572)

I have not read up on those RFCs yet, but my guess is that they won't matter unless the server is actually looking for a response.  If that is the case, then you need to send 0xFFFBYY where YY is the last byte from the DO commands.

[jackson_thom]

i wrote HEX constant to TCP write, and it return error 60.

[crossrulz]

---

@jackson_thom wrote:

i wrote HEX constant to TCP write, and it return error 60.

---

That error is a connection issue.  It should not be coming from sending a message on an established connection.  Did you fail to close your connection or have it open by another application?

[CRM12]

I'm experiencing the same issue, with the exception of the write error.  Was a solution found?

This issue started when my company switched over to a Linux OS.  Is there something different for Linux?

I attached images of the code.

[CRM12]

Let me be a little more clear.  The device that I'm trying to connect to has changed to a Linux OS, the host remains the same. 

There is a direct connection via Ethernet from the host to the device.  I'm able to connect using the command prompt and PUTTY via telnet. 

I appreciate the help in advance. 

CRM