Telnetting into a BBS
... and a "host" of other sockets too
Telnet is among the "older generation" of
network communication applications that grew up during the early days
of telecommunications R&D. Eventually encorporating the TCP/IP protocols,
it runs over networks and enables TTY sessions between two peers. In
simpler language, it can facilitate an interactive conversation between
two machines which may be using different hardware platforms. As long as
these two machines "speak" TCP/IP and have their own locally compiled
versions of telnet, a person from anywhere could talk to anyone else
anywhere on the net.
Typically,
telnet
(man page) just logs you into a machine on a specified account,
probably a public directory, but it could be your own private user account.
Then it is up to the system administrator to decide what other
communication programs, via well-known port numbers, will be available
such as talk, converse, or ttylink, software that actually manages chat
sessions. So when you telnet a host, you usually see a login; when you
telnet a specified socket, you see a program or service as supported by
that program.
And once logged in, you could also run any program that the
system will allow, not just chatting. Again, these permissions are set
by the network administration policy. For all intents and purposes, and
despite possible extensive geographic separation, after you have logged in,
it looks like you are a "local" user on that system turning your laptop
or desktop machine into an
NVT
(rfc2217), a network virtual terminal!
- telnet://somehost.somesubdomain.somedomain (or its equivalent IP number)
After the connection has been setup, you will be asked for login data, which will be your user name and password, and which you would have to obtain from the system's administrator just as any local user would. Once validated, you may find yourself in a network BBS application, such as JNOS an amateur radio BBS application, or in a user directory running an assigned shell, in your own account/directory.
Back in the 1980's, telnet was used extensively to login to libraries, databases, or information bulletin boards. The original mechanism for connections was over a landline, probably using a slip, or slip-like protocol, or even something more "primative." Since at that time, telnet was the only "game in town," elaborate negotiational options were built into the software to facilitate universal connectivity among a meriad of uniquely configured, hardware-independent terminals, similar to the way modems still negotiate now. Today, much of the full range of this terminal accomodation has become obsolete and is rarely used, but it is still there if needed, hence the .telnetrc (man page) file on UNIX/Linux systems.
Even now, you can still find dedicated sites and direct landline links that use only the telnet "protocol," but the internet and the growth of the World Wide Web are slowly forcing a gradual reduction of telnet connections. The remainder of this article will focus on the various re-incarnations of telnet and how it is being used over networks today...
The Many Guises of Telnet Sessions
Despite its "aging" appearance, telnet continues to show up and put on a new face (see PuTTY among others), and is included in various forms on almost all computers sold today! If you are a Linux or a UNIX person, you already know about the effectiveness of telnet since it is used extensively in many communication network operations, and at the very least, is instrumental in maintaining both remote and local server systems administratively over Lans and Wans. But telnet comes right out of the box on all Windows machines as well, and can even be acquired and run on Macs and iMacs (...goes without saying) too! The only requisite is the presence of the TCP/IP stack which the modern versions of telnet must have.
From the early days of DOS, in a B&W screen session, to even the latest rendition of Window's OS'es, in perhaps a fancy HyperTerminal window, telnet (rfc854) is there and runnable as it always has been for the past 35 years or so...
Let's look back to the early days to discover and run telnet peer-to-peer as found on the various platforms whether they be client or server, DOS or UNIX/Linux...
- From Windows XP, Desktop or Laptop
If you are running a fairly recent machine with an XP, or similiar, version of Windows, then there are several ways that you can access telnet. The easiest, and most primative, is to start the "Command" module from the "Run" option in "Start," which will display a popup Black and White panel, expandable to a larger window, but never taking up the entire screen. You can run telnet from just about anywhere in the DOS path by either entering the command "telnet," to open the client command screen, or "telnet some host" to attempt the link to the target host.
UNIX/DOS Style Text Window for Telnet Client
Note: The question mark dispays the command options...
The Black and White, B&W, panel that is invoked on a call to the DOS part of the modern OS looks nearly identical to the former DOS of years gone by, or like the current screen on a UNIX/Linux system in text mode today. If you still remember your DOS commands like mem, or dir, or date, you will feel right at home issuing a telnet command such as:
or
- telnet somehost.org
or
- telnet somehost.org 23
- open somehost.org [port]
... if you are attempting from inside an already opened telnet client session screen as illustrated above.
Notice the word separator is the space in contrast to invoking this command from a URL browser window where no spaces as such are allowed. Using this method, it is also very easy to denote the port number. You can include it or not, as mentioned above, but you could also use another number, one especially setup for an additional telnet entry point on a remote server as well.
As shown above, the question mark displays the options that have been bundled in this version of telnet. Remember, there are are many renditions or packagings of the telnet "client" so the question mark will reveal what is available in your version.
Now for the big connect! Remember no matter where you are, a cyber cafe on a wireless link, on an ethernet line, or even over a landline dialup, you must be connected to an ISP somewhere, unless you just want to connect to yourself (127.0.0.1) for a local test...
Once you have arrived at your destination, you will need to login and enter a password. Sometimes beginners get tripped up because they can't see what they are typing in. There is a configuration parameter called "Echo" which determines whether characters are echoed (displayed) locally on your screen. This is part of the negotiation process mentioned above. Some destinations may turn echo on for you in their parameter "handshake," but many today do not; it's up to you!
To break out of the current session and enter the telnet command screen, enter "Ctrl-]" (Control right-bracket) from your keyboard. This will open a control session where you may turn echo on or off. Enter:
- set localecho
...it will come back with the message "local echo on." Now, press the "enter" key and you will be back onto your original communication session screen.
It is possible that you might see everything you type as duplicated, all letters appearing twice. In this case, you need to turn the local echo off:
- unset localecho
The response message will be "local echo off." To see the status of the connection, you would enter "s" from the command screen. You return to the communication session with a carriage return, as above. To see all available parameter commands, enter "?" (a question mark).
Let's get a bit more adventurous and see from where else we might be able to initiate a telnet session. It turns out, in the new versions of Windows, you can call up the Black and White telnet panel from the URL in your browser with a line like this:
- telnet://somehost.org
...where there are no spaces in this line. If your browser is IE, you will jump right into the B&W DOS panel just as if you had started it from the start/run buttons. However, it will immediately make the connect if it can, and you will be at a login prompt. Again after the login, you may have to turn echo on, as described above, to see what you are typing. If you are using Netscape, you may be asked about using an external application. You would answer "yes," and the telnet program should kick in just as it does for Internet Explorer (IE)...
To leave or exit a telnet session, you should have two options. The first is to use the BBS prompts to either "quit" or "exit" or "bye." This exit command is written into the BBS software and will vary widely with each type of application. (For example, the exit command on a *NOS system is "bye." But for many others, it is "quit.") However, you may also return to the telnet control screen with the "Ctrl-]" keys, and from there you may enter a "quit" command. If you wish to remain in the control screen, you could "close" the current connection and then reopen a new one... (Again, a "?" mark entered from the control screen lists the commands available which can vary from just a bare-bones few to quite an elaborate listing of options, depending somewhat whether you are on a Windows or a UNIX/Linux machine!)
Suppose you like this idea of telnetting, but find the old style of the DOS presentation just a bit "depressing." :) Well, you are in luck! There is a program that usually comes standard with Windows machines called HyperTerminal . HyperTerminal is a commercially available program which has found a promotional presence on Windows platforms, and deservedly so. The software has kept pace, originally making landline and COMMs port connections only, to now encorporating the winsock TCP/IP stack, so that, despite the scaled-down version compared to the full-blown commerical version, it can do on-line telnetting quite nicely, and is probably the interface that you are going to prefer!
If you have never called upon HT before, you should be able to find it from the programs listing as displayed from the "Start" button. "Expand" the accessories listing and either look for the program directly or continue expanding under communications. (To expand a listing, just continue clicking on any topic panel which has a small arrow to its right.)
HyperTerminal always assumes that you want a classic dialup connection and displays a panel which can associate a desktop icon with a complete dialup session, including all the necessary landline parameters. However, if you want a tcp/ip internet type connection, you may skip over this process by exiting out of this panel. From "File" on the toolbar, click on "Properties" and a "New Connection Properties Panel" will open. From the item named "Connect using:" near the middle of the panel, drop the list by clicking on the arrow. Then select TCP/IP(Winsock) and the panel will change to accept this new data. Enter the name or IP number of your telnet destination. You may also see the telnet port number, 23, and the tcp/ip winsock options, all of which can be left as they are... If you will be telnetting to a radio node or to a UNIX type BBS, click on the "Settings" screen and in the lower right, click on "ASCII Setup." Click on the top two boxes since you will probably need to see those characters echoed and you may need a line feed at the end of each line typed in. Click "OK" as you back out of each panel. The final "OK" should make the connection attempt to your destination machine.
When you complete this form and enter it, you will be back at your HT screen waiting for the connection. No matter dialup or socket, you may encounter the same echo problem as on any telnet type session mentioned above: you can't see what you type in! Repair to the tool bar again under "Preferences," "Settings" and click on "ASCII Setup," the same as the above method. You can check (using the check box) echo on, and also check the carriage return line feed. Then apply or save, and return to your telnet session. You can now see what you type, which is what you would expect on normal BBS interactions.
The HyperTerminal Communications Properties Screen
Note: On exit, you may erase or leave blank the destination...
On closing your telnet session, you may choose to simply exit the HT screen, or save all your session data. (There is even an option to give your connection panel parameters a name; I called mine socHT.) This saves all the data you previously entered for that target machine. However, a neat trick is to re-open the "Preferences" panel and erase, yes erase, the internet address or ip number, and then save it (click OK) in this partial state. The next time you invoke this HT session, this panel will always come up first, asking you for the new address! (Your echo and linefeed data will also have been saved.) And, you now only need one "universal" HT invocation as opposed to one for each connection! Otherwise, you might end up with a desktop full of dedicated icons for all your telnet destinations, or numerous panel names in the "Start" drop down listings. (But, you have that choice, and maybe that option is what you want for convenience, especially if you consistently only telnet to one or two locations...)
Once saved by name, you will see another HyperTerminal entry in the menu drop down listings under "Communications." That name should be located near the end of the HyperTerminal group and points to your clickable item(s), displaying your TCP/IP connection parameters. (It will also appear as part of the title for the active communication panel.) And, since you cleared it before you closed out your session, it is awaiting input from you now, and will connect to any reachable machine that you request. (If you didn't, or you forgot, to clear it, the last entry is the one that will be attempted.)
If you run a LAN between a laptop or desktop machine and a dedicated radio node on a nearby or remote machine, HyperTerminal creates a very presentable session window for any BBS operation. In other words, it "looks good!" And, if you care to explore HyperTerminal a bit more, you may find it has some nice extra features that can come in very handy, such as being able to compose a letter in an external file, "Open" it, and then insert it right where the cursor is in a BBS message stream. It's a fun program and fits quite nicely into the Windows environment...- From Windows 95/98
In the middle years of Windows development, telnet retained its place among the network "protocols" included in the standard OS releases, and might still be considered, by some, to be easier to use, and perhaps a better piece of code, than the latest scaled-down compiles of recycled UNIX-like modules which many users have often labeled as "broken." (It's not really broken, just misunderstood. :)
This Windows 95-98 rendition of telnet is invoked, even from the DOS prompt, by entering the command "telnet" or "telnet some host." (It may also be started from a browser URL too in the same way as mentioned above that any telnet session can be invoked.) A special telnet session window is immediately displayed with its own tool bar area and supporting data entry and help panels, overlaying the main Windows desktop. DOS may be doing the dog work in the background, but it is a true Windows seesion that drives the front end of this utility, making it easy to use and fun to operate!
Again when you login to a machine using this version of telnet, you also may not see the characters that you are typing. However, if you are a regular Windows user, you probably already know the answer. Just click on the tool bar item "Terminal" and then again under "Preferences". A configuration panel will be displayed. It is from here that you may change the parameters that control the program. Check for echo on, if off, or check it off if you don't need it. As mentioned, sometimes you may see double characters when you initially login to a BBS or other Chat type program. (This happens to me when I login to a DXSpider server. I don't always bother to change it, since no input is required after my callsign...)
Another nice feature of this version is found under the tool bar item "Connection," which displays a short listing of previous IPs to which you have connected. This can be very handy for IPs that you use frequently, To open a new connection, you click on the "Remote System" and a data entry panel opens up to receive your new host or its associated IP. (This IP will also be added to the list for later reference probably displacing an older entry.)
As you can tell, I like this "older" Windows version of telnet. It is very easy to work with and quite intuitive if you have been around the Windows OS for any length of time...- From UNIX/Linux
Here is where you will find the classic telnet session and "protocol." This definitely comes standard with all UNIX or Linux based operating systems! You may find that you end up using telnet more as a testing device than as an actual communications device, even though it was designed for the latter purpose.
However, many users still find the telnetting protocol very useful, especially when checking into a BBS or simply logging in as a remote user, or telnetting into a chat server on port 87. So, let's look at a few cases where you might be telnetting...
As with all the basic telnet services, you may open a session without specifying a remote host, in other words, you are running a telnet "client" on the localhost as seen below:
- telnet
The return is the prompt line "telnet> " with the session waiting for your imput. You will see nearly a full screen of help information when you enter a "?" question mark at this point.
Telnet Client Session Screen for UNIX/Linux
Commands may be abbreviated. Commands are: close close current connection logout forcibly logout remote user and close the connection display display operating parameters mode try to enter line or character mode ('mode ?' for more) open connect to a site quit exit telnet send transmit special characters ('send ?' for more) set set operating parameters ('set ?' for more) unset unset operating parameters ('unset ?' for more) status print status information toggle toggle operating parameters ('toggle ?' for more) slc set treatment of special characters z suspend telnet environ change environment variables ('environ ?' for more) telnet>Note: Most commands may be expanded by following each with a "?" too
From this screen, you may set parameters as in the above DOS telnet examples, open a new connection, or even logout or close the current session. However, this UNIX/linux session presents more options than the DOS command session. And the echo parameter is set to "on" by default which is different from the DOS version. You might also check "mode." Characters may be sent one at a time, which is useful in a split screen chat session, but more commonly sent line-by-line for radio or on-the-air links, which means that the entire line is stored in an input buffer and is only flushed when the "Cr" or "enter" key is pressed. Sometimes, the character-at-a-time mode will not work properly on over-the-air links, so you might have to check this option and set it properly...
You return to your connected host session, and leave the telnet command console, by pressing the "enter" key which is the same in DOS versions too.
As mentioned above, telnet finds application beyond the boundries of person-to-person communications. Sometimes it can be person-to-machine or person-to-server. In other words, you just want to query some data from a process that is running somewhere and diagnose a fault or troubleshoot a failure, or just have a look around. Well, telnet can prove to be a very handy network tool. A good example is the case where you want to check on the status of a web server. You may telnet to port 80. Recall that the default for telnet is port 23, but you may attempt any valid, legal port from the telnet application, as in:
- telnet nearly.any.webServer.net 80
Followed by the "GET" command to receive the page you want... and then two (2) "Enters" or "Carriage Returns." (Note: The uppercase commands GET and HTTP; the path/filename, though, can be in lower.
- GET /ka1fsb/station.shtml HTTP/1.0 <cr> <cr>
The return should be a prologue of general information from the server, followed by the entire page in text format. (If you get this, you know the server is up and the page is good. :)
"GET" Data Returned from the Apache Server on ka1fsb-12
Trying 44.56.26.12... Connected to ka1fsb-12.ampr.org. Escape character is '^]'. HTTP/1.1 200 OK Date: Tue, 30 Jan 2007 14:10:33 GMT Server: Apache/1.3.12 (Unix) (SuSE/Linux) ApacheJServ/1.1 mod_fastcgi/2.2.2 DAV/0.9.14 mod_perl/1.21 PHP/3.0.15 Connection: close Content-Type: text/html <html> <!-- Page Log: 03-07-02 Copied from short.html This is the new entry page for the local site! 02-22-03 Moved to SuSE and cloned 01-02-04 Added link for station.html --> <head> <title> ka1fsb-12.ampr.org </title> . . . <br> <hr noshade class="thin"> <font size='-1'><address>(Courtesy KBNorton Computer Services)</address> </font> </blockquote> </body> </html>Note: This screen only displays a partial web page here...
While this example is not an overly complicated one, it serves to show how potentially useful telnet may be. Many of the ports in the UNIX/Linux services file may be telnetted, yielding interesting system or network information. Try a telnet! You never know what useful information you may come away with...- Extending Telnet's Capabilities for Advanced Users
As noted previously, telnet began life as a standalone application, even before TCP/IP came along, with no distinct differences between client and server as today. So the developers, thinking this would be the only communications "game in town," put everything into it but the kitchen sink! It was to some extent, even by today's standards, somewhat over-developed. However, this is not all bad.
This unexpected robustness firmly establishes the telnet application as a "plug 'n play" module for building (glueing together) larger scale network systems right on, and among, your local or remote machines. For example, did you know that you can pipe data into the telnet application? A typical shell command line might look something like this:
- myDriverCode | telnet localhost 2001 >> myFile &
You might not think that you can feed a telnet application in such a manner, but you can. Suppose the telnetted connection linked into the LinuxNode. The driver code could log you in automaticaly, issue some commands, and then capture the output data in a file, looping indefinitely and maintaining the pipe until the driver was retired. You could "tail" that file and make other data requests based on the results of the outputs. You could in theory design a network "robot" that looks something like the classic "Expect" program, well known as an automated program exerciser...
If you logged into a streaming data source, a weather text bulletins node, for example, you could also add a filter program that would trap just the information you are interested in.
- myDriverCode | telnet localhost 2001 >> myFile &
- MyFilterCode >> myOutputs & (Where this code reads the myFile and filters it ... )
(The final output data does not need to be directed into a file, it could be presented on screen as a TTY session.)
And as you know, I usually only present ideas that I have actually proven workable here. But, telnet is such a unique piece of code with the potential for so many applications, that I couldn't resist peaking your curiosity and imagination to explore these "experiments" a bit more on your own...
Have fun with telnet. Dare to imagine what you might want to try on your networked systems. Telnet is almost as "interesting" as email, except maybe just a bit more doable! :)
(Courtesy KBNorton Computer Services)