
                        The WATTCP TELNET Server

                            by Erick Engelke


This program allows you to remotely control your pc.  It is a pretty simple
implementation, but usable enough for many people.

For a much nicer but commercial TELNETD implementation (colour, kermit file
transfer, remote printing, multinational characters, 24 or 25 lines, etc.)
contact info@snsi.com about Everywhere Access or check out 
http://www.msen.com/~snsi.

We have a large Everywhere Access installation at the University of Waterloo
which we use to allow students home access to our LAN.  Pretty cool!



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.

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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
