Wrong response to AT command via socket c++/cli - visual-studio

Question

I want to create simple socket that will communicate with another device via AT commands.
I'm using C++/CLI on Visual 2017.
This is my code
#include "stdafx.h"
#include <conio.h>
using namespace System;
using namespace System::Net;
using namespace System::Net::Sockets;
using namespace System::IO;
int main(array<System::String ^> ^args)
{
int bufferSize = 1024;
array<Byte>^ sendBuffer = gcnew array<Byte>(bufferSize);
array<Byte>^ recvBuffer = gcnew array<Byte>(bufferSize);
try {
// Establish the remote endpoint for the socket.
IPHostEntry^ ipHostInfo = Dns::Resolve("192.168.1.1");
IPAddress^ ipAddress = ipHostInfo->AddressList[0];
IPEndPoint^ remoteEP = gcnew IPEndPoint(ipAddress, 1234);
// Create a TCP/IP socket.
Socket^ socket = gcnew Socket(AddressFamily::InterNetwork,SocketType::Stream, ProtocolType::Tcp);
// Connect the socket to the remote endpoint. Catch any errors.
try {
socket->Connect(remoteEP);
// Encode the data string into a byte array.
array<Byte>^ msg = Text::Encoding::ASCII->GetBytes("AT");
// Send the data through the socket.
int bytesSent = socket->Send(msg);
// Receive the response from the remote device.
int bytesRec = socket->Receive(recvBuffer);
Console::WriteLine("Echoed test = {0}", Text::Encoding::ASCII->GetString(recvBuffer, 0, bytesRec));
// Release the socket.
socket->Shutdown(SocketShutdown::Both);
socket->Close();
}
catch (ArgumentNullException^ ane) {
Console::WriteLine("ArgumentNullException : {0}", ane->ToString());
}
catch (SocketException^ se) {
Console::WriteLine("SocketException : {0}", se->ToString());
}
catch (Exception^ e) {
Console::WriteLine("Unexpected exception : {0}", e->ToString());
}
}
catch (Exception^ e) {
Console::WriteLine(e->ToString());
}
_getch();
return 0;
}
For command there, the response is:
Echoed test = ????????
In ASCII there are weird values: 255,251,3,255,251,1,255,254,1,255,253
The answer should be OK or ERROR
I tested it via Telnet on 192.168.1.1 1234 and it was working fine.

Answer 1

Standard warning: While it's certainly possible to write the main body of your application in C++/CLI, it is not recommended. C++/CLI is intended for interop scenarios: where C# or other .Net code needs to interface with unmanaged C++, C++/CLI can provide the translation between the two. For primary development, it is recommended to use C# if you want managed code, or C++ if you want unmanaged.
That said...
The telnet protocol is not, contrary to popular belief, a raw TCP socket. There is a protocol for communicating options between telnet clients.
What you're seeing there are telnet commands sent from the server. These would be received from by your telnet client, and used to modify how it behaves. This is why everything works when you use a real telnet client: It takes those bytes and interprets the commands properly.
I read the Telnet spec for a few minutes, here's what I was able to decode from the data you posted:
255: IAC, "Interpret as command". This is the escape character for all Telnet commands.
251: WILL: Indicates that the server wants to/is performing an option.
3: SUPPRESS-GO-AHEAD: Apparently Telnet is a half-duplex protocol by default, and the "Go Ahead" is the marker for one side to tell the other, "OK, your turn". This option turns it into a full-duplex connection.
255: IAC
251: WILL
1: ECHO: Indicates that the server will echo back the characters that it receives.
255: IAC
254: DON'T: Indicates that the server is requesting that the client not do something.
1: ECHO: Indicates that the server wants the client to not echo back received characters.
255: IAC
253: DO: Indicates that the server wants the client to turn on some option.
OK, so now that we know what's going on, how do we fix this? I see a few options:
You said you wanted to use "AT Commands" to talk to a device. AT commands are what you use to talk to modems. I'm assuming that you have some serial device, possibly a modem, that you have connected to a little converter device that exposes a serial port as a TCP connection. If so, then there may be some option for that converter device to disable the Telnet protocol, and expose it as "raw", or something similar. If this is true, then that's probably the best option.
You can add code to your program to look for the IAC byte, and handle the bytes that follow it. If it's just a few commands at the beginning of the connection, then you can just expect those fixed bytes; if the commands are sent during the connection, you'll need to handle them everywhere. It's up to you how much you want to handle them. (E.g., if the server says DON'T SUPPRESS-GO-AHEAD, will you send the Go ahead command? Ideally you would, but if your particular connection never says that, then perhaps not.)
There may be a telnet library that will handle the protocol stuff for you. I have not searched for this.
Telnet references:
The main RFC, where the IAC byte and the command bytes are defined: https://www.rfc-editor.org/rfc/rfc854
The ECHO option: https://www.rfc-editor.org/rfc/rfc857
The SUPPRESS-GO-AHEAD option: https://www.rfc-editor.org/rfc/rfc858
Not an official reference, but does list the options that can be specified with WILL, WON'T, DO, and DON'T, and the RFCs they're defined in: http://mars.netanya.ac.il/~unesco/cdrom/booklet/HTML/NETWORKING/node300.html