beedrill, since you are talking about the Console class, I assume you want to have your sketch talk over a Telnet session instead of the hardware Serial port of the Console class - you want to be able to connect directly to that connection without having to SSH into the Yun and then start a local Telnet session. Is that correct?
It can be done, but note that this ONLY talks to the sketch, it cannot be used as a replacement for SSH in order to get to the Linux command line. And, as Jesse points out, there is no security, so it’s up to you to figure out a solution to that if you need it. (If you’re just displaying debug output on your local network, you probably don’t.)
I’ve posted this a few times. The solution is to use a YunServer/YunClient in the sketch. This implements a TCP socket, and if you use port 23, you can connect to it with any Telnet client. Just be aware that this is actually a raw TCP socket, and not a Telnet server. Telnet is a protocol that runs on top of a TCP stream, and adds a lot of terminal session control features. One of the things it does is an initial negotiation sequence where it figures out things like full/half duplex, terminal capabilities, etc. When a standard Telnet client makes a connection, it goes through this negotiation process. The YunClient will receive these and pass them on to the sketch as some initial garbage, and will not reply to the negotiation. This is not normally a problem, but just be aware that the sketch is likely to get a dozen or so garbage characters at the start of the connection.
A simple example sketch:
#define PORT 255
Bridge.begin(); // Bridge startup
Serial.println("Server listening on port 255");
client = server.accept();
// There are two interesting flags in the client:
// opened - read by converting the client object to a bool.
// connected - read by calling the connected() method
// This gives four combinations:
// closed and no connection - Try to accept a new connection.
// closed and connected - Not possible.
// open and no connection - Connection just closed, stop the client to clean up.
// open and connected - Ready to go, process the connection
// There is a valid connection open.
// Read and echo any input to the serial port
Serial.print("From client: \"");
// Send something to the client
// The client is not connected. Is it open (previously connected?)
// The client is currently open, but is not connected.
// That means that there was a valid connection the last time around the loop.
// There was a connection on the client, but it has just closed.
// It's necessary to stop a closed connection, otherwise resoruces are not freed
// and the server will stop accepting new connections after about 256 sessions.
// At this point the client is not connected, and has been gracefully closed.
// Try to accept a new connection.
client = server.accept();
// Is the client now connected? If so, we have a new connection.
Serial.print("New client connection: ");
This code uses port 255 (an arbitrary choice on my part.) If you want to use a standard Telnet client, you may want to use port 23 (although most Telnet clients let you specify the port.)
The sketch starts out by enabling the Bridge, then waiting for a USB serial connection - the LED flashes rapidly while waiting. It then starts a YunServer listening on port 255.
loop() actually manages the connection. It prints out messages to the serial port when connections are made and broken: you might want to do something special when that happens, but at a minimum make sure you keep the code that stops the client when the connection is closed.
While a connection is established, it reads all incoming data and echos it to the serial port, and sends a constant string to the other end of the connection. You will no doubt want to do something more intelligent there.