This is an old revision of the document!
This is by no means an exhaustive intro to Telnet, but a few basic notions are needed. The reason we're going into Telnet at all is because at the time this is being written (March 2017) dial-up is not really a thing anymore, and of the remaining BBSs, the large majority is accessible via Telnet, with some featuring SSH as an option.
Now, a robust BBS package would be written in a way that decouples the transport interface from the rest of the system, so you can just add new transports and maintain functionality (you may want to add SSH and a Web transport in the future, for example) but since this is an entry-level tutorial, we'll focus on Telnet and not worry too much about architecture.
Telnet is these days an obsolete protocol, since it's insecure and bound to a set of archaic notions by today's standards. The initial purpose of Telnet was to allow “virtual terminal” access to remote systems, and it was wildly successful. First mentioned in RFC 97 all the way back in February 1971, it would be formalized in RFC 854 published in May 1983, along with some follow-up RFCs describing protocol extensions and negotiation options. Being a product of the 70s, security was not of huge importance to its design (same problem as SMTP and others). Bear this in mind - Telnet is *not* secure and quite vulnerable to so called “man-in-the-middle” attacks, and has no provision to safeguard against it.
So, the basic idea is that we get a character by character interface, just like a local Linux terminal emulator. Our inputs are sent to the server, and we get an update of the virtual terminal's layout sent back (or not, in case the keystroke does not change the state of the terminal).
Usually, network programming involves sending and receiving messages, but for purposes of manipulating this virtual terminal, we'll be sending and receiving more than just text - among the messages we will send (and receive) are things that are not shown in text, like sounding a bell or clearing the screen or moving the cursor to a specific line and column or even detecting the width and height (in columns and lines) of the client. These special messages are codified in the Telnet protocol in a specific way, and are essential to any successful BBS system. You can not use them, but your interaction will be quite reduced.
Negotiating these client capabilities with the server was necessary even back when Telnet was first created as many different terminals, with different features, were prominent in the 1970s and 80s. Examples are the VT100 and VT220 terminals by DEC.
You can see these messages for yourself when connecting to a Mystic BBS. Let's try this by connecting to the main fsxNet hub, Agency BBS. Instead of connecting directly to the BBS, start
telnet by itself:
$ telnet telnet>
telnet> prompt, type:
telnet> toggle options
You should now see
Will show option processing as a result. This means that the normally suppressed feature negotiation messages will be shown on screen. Oh, and by the way, whenever you want to exit a Telnet connection that is hung or somehow unusable, press
Ctrl-5 to get a telnet client prompt, and then you can just type
quit to exit. Now, on to the Agency BBS:
telnet> open agency.bbs.geek.nz
You should see:
Trying 188.8.131.52... Connected to agency.bbs.geek.nz. Escape character is '^]'. SENT DO SUPPRESS GO AHEAD SENT WILL TERMINAL TYPE SENT WILL NAWS SENT WILL TSPEED SENT WILL LFLOW SENT WILL LINEMODE SENT WILL NEW-ENVIRON SENT DO STATUS SENT WILL XDISPLOC RCVD WILL ECHO SENT DO ECHO RCVD WILL SUPPRESS GO AHEAD RCVD DO TERMINAL TYPE RCVD DO BINARY SENT WILL BINARY RCVD IAC SB TERMINAL-TYPE SEND SENT IAC SB TERMINAL-TYPE IS "XTERM-256COLOR" RCVD DONT NAWS RCVD DONT TSPEED RCVD DONT LFLOW RCVD DONT LINEMODE RCVD DONT NEW-ENVIRON RCVD WONT STATUS RCVD DONT XDISPLOC Mystic BBS v1.12 A31 for Windows Node 1 Copyright (C) 1997-2016 By James Coyle Detecting terminal emulation: ANSI detected.
and then the BBS's main login screen. So, that's a lot of feature negotiation going back and forth! We won't go into detail (more on them in Part One) but let's go into just one of the features being negotiated called
Go Ahead. You can see two debug messages related to it in the connection log:
SENT DO SUPPRESS GO AHEAD ... RCVD WILL SUPPRESS GO AHEAD