Telnet is pretty cool.

Now processing most of the Telnet protocol!
Now processing most of the Telnet protocol!

A few evenings ago, I noticed a bunch of garbage coming on from an Ethernet connection on the Arduino when a new connection was made to the example server code. This garbage turns out to be part of the Telnet protocol. There are various escape sequences (some of which are quite large) that flow across the connection, and must be handled else they pollute the data stream.

I began writing some code to do this, and like many tangents I get on, it has led me down quite the rabbit hole of discovery. My first stop was this very helpful web page that explained a bit about how Telnet works:

http://www.softpanorama.net/Net/Application_layer/telnet.shtml

I then proceeded to read the RFC documents about Telnet, and learn more details:

http://www.faqs.org/rfcs/rfc854.html

RFC 854 covers the Telnet protocol. This document is from 1983, which is the year I was writing my *ALL RAM* BBS system which I recently ported to the Arduino. There are other RFCs that cover specific aspects of Telnet, such as all the various Options that can be set.

Initially, I created something very simple that just “ate” all the Telnet escape codes. This is small code, and should be used on any Arduino sketch that expects someone to be able to Telnet in to the device. I will finish it and post it here, or as a sample on the Arduino webpage in the Playground area.

I soon learned there were even more codes than what I first learned, so I went and found more complete references:

http://www.tcpipguide.com/free/t_TelnetOptionsandOptionNegotiation-2.htm

Even after that, I still have a few others I can generate (from the PuTTY terminal program) and see but I haven’t found good documentation on them yet. (I just know it has an option in PuTTY to send special sequences, and I went through all of them to make sure I was handling them correctly.) I have learned quite a bit about Telnet in the past few days. It’s pretty neat.

So, I am now working on two things. One is a simple EthernetServer filter that will take care of the most simple bits of Telnet. I will make it so that can be compiled out, so it’s just a “eat all the Telnet escape sequences” thing, for sketches that are very tight on space.

The bigger project is the seTelnetServer. It’s a klunky name, but it follows that naming conventions I used back when I was coding 6809 assembly language utilities for the OS-9 operating system. seTelnetServer is going to be a more complete Telnet implementation, with (conditionally compiled out) the ability to emit all the protocol debug information on the console (for those curious). I am planning on supporting some of the basic features I see various Telnet clients try to set — line versus character mode, echo and things like that. It will have hooks in the code where you can modify it and handle more if you need to. For instance, do you want to do something with the BRK sequence? Or Suspend?

I am packaging this together in to a very simple-to-use server sketch that might be as easy to use as this:

void setup()
{
telnetInit(23); // Initialize, listening on port 23
}

void loop()
{
Serial.print("Waiting for connection:");
while(!done)
{
telnetInput(buffer, 80); // Read up to 80 characters.
// do stuff...
telnetPrint("Hello, user!");
}
}

The “telnetInput()” routine would take care of listening for a new connection, if there wasn’t one, and then read input from the user (handling Telnet protocol). If they disconnect, it would return a code that could be used to detect that and reset.

I have a rough version of this working. I even added the ability (with my Ethernet library fixes) for it to receive other connections while it is handling the first one and inform them that “The system is in use. Please try back later.” And, there is even an “offline” mode, so if the operator decides to log in via serial console, it will disable the Ethernet (again, giving those who connect a “System is offline” message) while the operator is using it.

Sounds like fun. And when I am done, I plan to end up writing some Telnet software for the CoCo as well (though that has already been done for the DriveWire project).

More to come…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.