home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Media Share 9
/
MEDIASHARE_09.ISO
/
network
/
telnetd.zip
/
DOC
next >
Wrap
Text File
|
1991-11-13
|
21KB
|
408 lines
The WATTCP TELNET Server
by Erick Engelke
This program effectively allows you to remotely control your pc. There
is always work in place to improve TELNETD, work which is based on the
large amount of positive feedback from users like you. I post to
comp.protocols.tcp-ip.ibmpc whenever I make significant changes
or improvements to this program.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
WARNING - TELNETD offers some simple password security provisions but remember:
1. TELNETD gets the password from an unencrypted disk file
2. TELNETD stores the password in memory as plain-text
3. All TELNET protocols send the password over the network in
plaintext - it's trivial to read a password on networks such
as Ethernet.
The password protection is merely one step above no protection.
Do not leave important information accessible through TELNETD.
Change your password frequently and use mixed case and numbers
interspersed. Avoid single words, use combinations of words.
Do not use the same password for TELNETD as you would for your
system priviledged account. The maximum password length is
16 letters.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Installation
TELNETD.EXE uses the Waterloo TCP kernal to do all the network i/o.
Installing the program can be performed by simply editing the ASCII
configuration file named WATTCP.CFG. Try creating such a file with
information like the following and place it in the *SAME* subdirectory
as TELNETD.EXE.
---I:\NETWORK\WATTCP.CFG----------------------------------------------
my_ip=129.97.128.254 # substitute the PC's ip number
netmask=255.255.254.0 # substitute your local net mask
gateway=129.97.128.1 # substitute your local gateway
# the next lines are optional
telnetd.password=Time2Go # telnetd session password
telnetd.message="Wizbang Computer Network" # openning message
----------------------------------------------------------------------
You need not include quotes except if you wish to include
non-alphanumeric characters like '#',';' or spaces.
Full installation instructions for installing any Waterloo TCP
based program is available from sunee.uwaterloo.ca [129.97.128.196]
in pub/wattcp/apps.zip. If you end up having difficulty running
TELNETD, download that zip file, it will prove very useful. Also
included in that file is information on how to use BOOTP, multiple
gateways, and many other features.
The above type of configuration is useful in all WATTCP based programs,
but you can also add some special parameters which will only be
interpretted by specific WATTCP programs. In this case all parameters
specific to TELNETD are prepended with 'telnetd.' to make them
easily identifiable and to avoid naming conflicts with other WATTCP
applications.
Load (and configure) an Ethernet packet driver, then run TELNETD.
A message will appear indicating TELNETD is waiting for a caller and
it should report the correct IP address. An indication of a password
should appear for every time it encounterred a password in the
configuration process. If no packet driver is installed TELNETD will
have crashed by now.
Installing TELNETD on a Network
Do everything the same as above, but append the following line to
the WATTCP.CFG file:
include=?c:\telnetd.pas
and have user's place their private password in that file. Eg.
---C:\TELNETD.PAS-----------------------------------------------------
# joe's private config parameters
telnetd.message="Joe's Private Computer - KEEP OUT ALL SURF NAZIS"
telnetd.password=Knuths4thBook
----------------------------------------------------------------------
In the above example I assumed the 'c' disk was the local hard disk.
You could select the network disk or both. Here the network disk n:
has the last say on the password. The telnetd.password directive can
appear several times and in several files, but the last occurance
is the password actually used.
include=?c:\telnetd.pas
include=?n:\telnetd.pas
The question mark tells TELNETD to use the file if it exists but not
complain if it doesn't. You may like to leave a default password in
the WATTCP.CFG file, just so intruders are less likely to break in.
There are some other parameters which are sometimes good to set.
One which can enhance security is the inactivity timeout. Setting
this value to a non-zero value tells WATTCP to hang up the connection
if no activity occurs for a certain period of time. A good value
would be something like twenty minutes. Smaller values can be
-- WATTCP.CFG --------------------------------------------------------
# assuming properly configured as described earlier
# print a message for local user
print="Press control-break to get out of this thing"
# set the inactivity timeout value
inactive=1200 # 20 minutes ( 20 min x 60 sec/min = 1200 seconds )
----------------------------------------------------------------------
Using TELNETD
Go to a second PC. Using Clarkson University (CUTCP) TELNET, telnet
to the first PC. You could use NOS (KA9Q), but I don't think NOS
handles VT100 cursor keys and you will definately want them!
Other tested telnets include MicroVaxen, RS/6000 using AIX and
Macintoshes using MACTCP
When you TELNET to TELNETD, you may have to hit return. It's one
of those things left to fix. Sorry, but it's getting too late
tonight. You will then be confronted with a login message (from the
wattcp.cfg file) and a password prompt (if you selected a password in
the configuration file - otherwise skip this paragraph). You must
enter the password correctly within a reasonable number of tries or
TELNETD will complain and close the session. You must also reply
within a reasonable time limit.
The passwords can be almost any printable ascii string up to 16
letters. If you use characters other than alpha-numerics, you
should surround the password with quotes in the WATTCP.CFG file.
WATTCP removes the quotes when it parses the file, so you don't
enter the quotes when you enter the password at the prompt.
Assuming you passed the password test, TELNETD becomes a TSR and almost
immediately you will be at the DOS prompt. You are now logged in.
Anything you type on the remote PC will appear to be typed on the
TELNETD PC. QEDIT, LIST.COM, BORLAND C++, and many other programs
are compatible (check out the character translation). There will be
slight periodic delays. Using a 386 to run TELNETD will improve
your performance. If the screen appears to be messed up or incomplete,
you can have TELNETD redraw it by typing ESC R on the keyboard.
This usually happens from either a lost packet or contention on
the network card if you are using the same card for network disk i/o.
For example, if I am compiling then TELNETD can find very few
cracks in the network i/o because my computer is diskless. But most
operations are not so incredibly disk intensive and it feels quite
reasonable.
Remember that the remote PC is running VT 100 emulation and some
keystrokes have to be remapped. I have written support for
VT100 and VT220 terminals, but not everything has been
tested yet.
a-z, A-Z, 0-9 function normally.
cursor arrows function normally
To enter CONTROL-CHARACTER, eg. ^A, press ESC C A
To enter ALT-CHARACTER, eg. ALT A, press ESC A A
To enter SHIFT-Something eg. SHFT <- press ESC S <-
To enter function keys eg. F9 press ESC F 9
To enter ESCape press ESC E
** To exit (logoff and reboot) press ESC X
** To redraw the screen (clean up mess) press ESC R
** To get online help press ESC H, the next keypress removes the
help screen.
There are some extra VT100 and VT220 keystrokes available. The
VT220 user can usually use both VT100 and VT220 keystrokes.
PC VT100 VT220
ESC H HELP get online help
ESC ESC E F11
BCKSPC BS F12 vt100 not confirmed
INS Insert
DEL Remove
END pf4
DOWN down arrow down arrow
PgDn Next Screen
LEFT left arrow left arrow
5 Select
RIGHT right arrow right arrow
HOME pf3
UP up arrow up arrow
PgUp Prev Screen
F1 ESC F 1 1 on numeric keypad
... ...
F9 ESC F 9 9 on numeric keypad
F10 ESC F 0 0 on numeric keypad
F11 pf1
F12 pf2
Notes on Using TELNETD
When you don't know how to do something, try the online help (ESC H).
Many other keystrokes are built out of combinations, for example,
Shift F7 is attained by typing 'ESC S ESC F 7'. Sorry, but that's
the way it is right now.
Kermit users may wish to write a kermit script to remap the keyboard
and provide really nice emulation. If you do it, please send me
a copy too.
Once connected, TELNETD does some neat things. It automatically
compensates for slow data lines. Here's how I call in from home:
PC <-- 10 Mbps <-- PCRoute <-- Ethernet <-- Telnet <-- Modem <-- phone <-- home
Token Ring Server PC
\______________________________________________/ \__________________/
high speed media 1200 baud
TELNETD attempts to use your network card during the timer tick.
The packet driver or network card may be in use and report a
transmission error. No problem, TELNETD will retry a little later
and eventually get through, but that explains the bumpiness you may
notice during network disk operations.
If you've had a high count of network errors, the tcp/ip portion of
TELNETD will take a couple of packets to recompute the correct
response time. Enterring a few keystrokes or using ESC R to redraw
the screen will generate the necessary traffic to restablize the
the round trip time.
Although very rare, you may notice a little garbage on the screen.
This is usually something to do with ANSI escape sequences. The
quick solution is to redraw the screen with ESC R. If you see these
with any frequency, please let me know.
When you wish to end your TELNETD session, either have your local
TELNET program close the session or use 'ESC X' which will tell TELNETD
to close the session. Simply rebooting the TELNETD machine or the
TELNET machine is bad since the other machine will keep trying to
communicate and will annoy your network manager.
Limitations:
I *DID* mention that this is not perfected. Here are the
current problems that come to mind:
1. screen updates are sporatic - hey, don't be picky - but they
are getting much better
2. You cannot run other TCP/IP programs. This is a limitation
of the packet driver combined with the fact that no other
programs use TELNETD as their TCP/IP kernel.
3. VT100's don't have a way to do *all* the cursor keys, well
I just haven't come up with keystrokes for all of them.
If you have some good ideas, send me a list.
4. TELNETD may show update delays because of network card contention.
Basically, if you are using your network card for something like
NOVELL file service, TELNETD won't know that and will attempt to
use the card at the same time which may cause delays. My computer
is diskless too, but it doesn't feel that bad.
5. Screen blankers may cause problems and should not be installed.
I find this to be a general truth though I know everyone
has found one which works with (almost) every other program.
Notes:
1. When you logoff or reset your connection or it timesout from
inactivity (if past the password prompt) I reboot the machine.
This way your autoexec can set it up for the next call and
sensitive network accounts can be managed more gracefull.
2. TELNETD automatically adjusts itself to work efficiently with
low performance and low bandwidth networks.
How Does It Work?
TELNETD passively watches the local screen and actively changes the
keyboard buffer. In essence, it performs whatever is necessary to
share the computer with a remote session, and attempts to consume
as little processor time as possible doing so.
TELNETD chains into the timer tick, meaning it gets a little bit
of processing time every time the computer's clock ticks. That
works out to about 18 times per second. It is pretty careful with
precious computer time, so it never sits in any form of idle loop.
You should not experience a significant processor slow down while
running TELNETD unless you are working on an 8088.
During that time slice TELNETD checks to see how much data the remote
computer has accepted from previous screen updates. If there is still
lots of unaccepted data, the remote computer is probably relatively
far away and TELNETD doesn't bother sending updates as often. This
results in jerkier screen updates, but it reduces the load on the
intermediate networks. If the last update is largely complete,
TELNET completes the following steps to do the next update.
The update process works by comparing the screen memory against a
local buffer. Differences are locallized to a particular screen
line and the first and last changed character on that line. Eg.
line 12, characters 23 to 36. The data is massaged, turning PC
graphic characters into ASCII characters and converting long
sequences of spaces into faster escape codes such as
clear-to-end-of-line.
Typically an escape sequence is sent saying, goto line 12,
character 23, and then 13 ASCII characters are then transmitted.
Special optimizations are made to try to reduce the number of
lines sent by checking for scrolled screens. If the screen appears
scrolled, TELNETD sends commands to scroll the remote screen.
TELNETD transmits chuncks of information until a certain number of
lines appear in transit, currently that value is 12 lines, or up to
approximately one kilobyte. Then the remote cursor is positioned at
the correct screen location.
In all its screen updates, TELNETD must constantly deal with the
fact that the remote computer can only display 24 lines as compared
to the 25 lines on the local screen. It attempts to handle this
by only looking at the 24 lines containing the cursor, ie. if the
cursor is on the upper-half of the screen, TELNETD shows the first
24 lines, otherwise the last 24 lines. Again, it uses the VT100
scrolling sequences to toggle between the two efficiently.
TELNETD relies on the fact users get confused by frequent screen
updates, thus most applications do not change a significant portion
of the screen very frequently. The common exception is editors
and word processors which tend to update the current line and
status lines with every key pressed.
TELNETD must also read characters from the network. It builds them
into a string in local memory and compares that string agains known
keystrokes. If a match could exist, ie. you typed ESC A but not the
third letter, TELNETD does not do anything with the data until the
next letter is received.
When a simple keystroke arrives, or a complex keystroke (eg. ALT A) is
completed, TELNETD must find the PC scan code equivalent. It does
this by searching a table. Finally, the ASCII/ScanCode value is placed
into the BIOS keystroke table in low memory and the BIOS thinks the
PC enterred the keystroke.
TELNETD must also deal with passwords and the possibility that the
remote person wishes to use its internal help or logoff facilities.
These are managed from the keyboard dispatch section just like other
keystrokes.
Future Enhancements
TELNETD and the underlying kernel were all written by me. You
can guess I've been pretty busy. I tried to design the kernel so
oddball applications like TELNETD could be written in 'C' and
without looking like some of the nastier UNIX or Bible sequences.
The number of TELNETD users is growing and I think the program has
become pretty reliable. I really appreciate mail from users, I've
put a good deal of rainy day time into this project and it feels good
to know that others can benefit from the effort.
There are some items which are still untidy, like the first password
attempt mess. That's the problem when a person has a real job and
only writes software like this on rainy weekends. I'll eventually get
around to it, just pray for bad weather. I live in Canada so you don't
have to pray that hard.
I post news to comp.protocols.tcp-ip.ibmpc when major improvements
are made to TELNETD or I am releasing other free software.
In case you are interested in TCP applications programming, you
may like to look at some of the other applications available.
FTP to sunee.uwaterloo.ca [129.97.128.196] and get
pub/wattcp/src.zip
Suggested Uses for TELNETD
Here are just some of the practical uses for TELNETD.
1. People who are away from their desks can quickly call in to check
files, mail, etc. Some prime candidates are when you are
in a meeting and you need something from your computer, any
terminal, mac or pc will allow you access if it is somehow connected
to the Internet.
2. If you have a Dial up TELNET server, you can allow people to call
in from home (much like PC Anywhere), but without requiring modems
in their office PCs.
3. Consulting can be simplified. Set up an easy to use batch file
which invokes TELNETD. When someone calls your consultant they will
be able to talk over the phone and use TELNET/TELNETD to solve the
problem. If you have MARK/RELEASE you can remove TELNETD from
memory without rebooting.
4. Some applications (such as databases) need to be accessible to
people at remote locations or on different computer systems.
TELNETD lets you to network existing applications on the PC
rather than programming on multiple platforms or trying to
get databases to work over wider area networks.
If you run into difficulty due to limitations of these brief notes, please
E-mail me with suggestions.
Good luck, and I hope TELNETD fulfils some of your needs in a remote
computing facility.
Erick Engelke
Waterloo TCP Architect
erick@development.watstar.uwaterloo.ca
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-