Archived Forum Post

Index of archived forum posts

Question:

Interpreting Telnet Bytes as Ascii?

Oct 30 '13 at 11:06

I am connecting to a device with the Socket ActiveX component.
The Device is the DataProbe IBoot-G2
http://dataprobe.co/support/iboot/iboot-g2.pdf

When I connect via telnet, immediately on connection the device returns “User>” for login.
When I connect with the ActiveX component I receive non-ascii characters ÿû

With Session Logging enabled, the response is listed as:
ReceiveString1: xFFxFBx01

Do you know if there is something I need to do with the ActiveX config to interpret that response as ascii?


Answer

The first part of the answer is to understand that us-ascii is character encoding where a single byte represents a particular character. Therefore, there cannot be more than 256 possible characters represented by us-ascii. Interpreting a byte as ascii is nothing more than looking at a us-ascii code chart (such as here: http://www.ascii-code.com/ ) and then seeing what character corresponds to the byte value.

The distinction between binary bytes and ascii bytes is whether or not the bytes actually represent characters. The byte value alone cannot tell you this -- you have to know this based on the context in which the bytes are found. In this case, 0xFF, 0xFB, and 0x01 are not even intended to be interpreted as printable char.

Given that it is telnet, the answer involves taking a quick look at the telnet protocol to get a layman's understanding of what we have. Wikipedia is a great source for this. If you Google "telnet", it's likely to be the 1st search result. Given that I'm not intimately familiar with Telnet, I did this myself. I quickly found this: "it used an 8-bit channel to exchange 7-bit ASCII data. Any byte with the high bit set was a special Telnet character." So now the answer involves delving into the telnet protocol, and this is where Chilkat's help must end. Chilkat can't be a resource in all technical knowledge for the entire field of computing..

But I can say how I might go about researching the problem. I obviously wouldn't want to digest the entirety of the Telnet protocol specifications -- I'd only be interested in what I'm experiencing with this particular device. Therefore, I would Google "telnet special code 0xFF 0xFB". I did it and you find various results, such as this: http://cboard.cprogramming.com/networking-device-communication/47239-telnet-echo-nagotiations.html Now you can begin to understand what you're seeing...


Answer

That is a great explanation. - thanks. My next question is: What can be done with the Chilkat socket control to communicate with this device? or is it just not possible?

I have never encountered this before. I have the Chilkat socket control communicating to many different types of devices and this is the first time ever, that I can't get it to work.


Answer

Thanks Shane. The Chilkat Socket API provides the ability to send bytes back and forth over a TCP connection. It also provides the same for over an SSL/TLS connection. The only functionality provided in interpreting bytes has to do with sending and receiving strings. For example, if you pass "A" to SendString and tell it to send "utf-16" it will send 0x41 0x00, but if you tell it to send "A" as us-ascii, then only 1 byte is sent: 0x41.

The Socket API is not aware of higher level protocols, such as HTTP, Telnet, SSH, POP3, etc. In this case, you would have to write code to handle whatever part of Telnet needs to be handled. Hopefully it's not much and fairly simple.


Answer

Reading the forum posting a few times, I tested sending a response 0xff 0xfd 0x01 "do echo" to the device, after receiving the xFF xFB x01 from the device.

This was successful. Once the device received that response "do echo" it would communicate normally.

I think this problem is solved.