Using Anzio with Windows Telnet Servers

Introduction

Most Windows telnet servers, otherwise known as "daemons" in the UNIX world, while intended to work similar to UNIX daemons, have peculiarities not found elsewhere. One of the big ones is the handling, or interception of, certain terminal type specific escape codes and sequences.

Most of these daemons only work in a particular terminal type, i.e. ANSI, and hence your application should be generic enough to not need a specific type. Still other daemons allow any terminal type and simply are transparent (as they should be).

We focus below on two such servers, Windows Telnet Server (and its variations) and SLNet from Seattle Labs, as they tend to demonstrate the extremes of telnet servers available for Windows. Others will behave similarly and have their own quirks to watch out for.

Windows Telnet Server

With the release of Microsoft Windows XP Professional and Windows 2003 Server, a telnet server is shipped and installed by default, though NOT enabled. With Windows 2000 and Microsoft Services for UNIX, a telnet server is also available, though it does behave slightly differently than the original Windows telnet server.

Telnet licensing

With each installation of Windows 2000 Server, the license provides one installation of Telnet Server. With each running server, a maximum number of simultaneous connections are allowed. This table shows the maximum number of simultaneous connections that can be made to Telnet Server:

Windows Server 2003 Terminal Services

Telnet and Terminal Services are similar in that they are both used for remote sessions. However, Terminal Services extends the model of distributed computing by allowing client computers to operate in a server-based computing environment. Whereas Telnet only allows terminal emulation between a Telnet server and client, Terminal Services running on Windows Server 2003-based computers allows clients to run applications, while data processing, and data storage occur on the server.

Applications and user sessions are transmitted over the network and displayed via terminal emulation software. Similarly, print streams, keyboard input, and mouse clicks are also transmitted over the network between the server and the terminal emulation software. Each user logs on and sees only their individual session, which is managed transparently by the server operating system and is independent of any other client session. You might want to consider using Windows Server 2003 Terminal Services if you require more extensive distributed computing.

Windows Services for UNIX 3.5

Windows Services for UNIX 3.5 includes a Telnet character-mode client that provides functionality not included in Windows Server 2003. The Windows Services for UNIX character-mode client supports both stream mode and console mode. It also provides for logging and additional configuration settings.

Windows Services for UNIX 3.5 includes two Telnet servers:

• The default, Windows-based Telnet server, which is functionally similar to the one included with all versions of Microsoft Windows since Windows 2000
• The Interix telnetd

Only one of these Telnet servers can be enabled at a time. By default, neither Telnet server is enabled for security reasons.

The Windows Services for UNIX 3.5 Telnet server accepts logons from a variety of clients, including the Telnet clients from virtually any operating system. Additionally, it can be configured to meet specific site requirements to improve security, simplify logons, support stream or console mode, and so forth.

The Windows Services for UNIX 3.5 Telnet server should be familiar to users of Windows 2000, Windows XP, and Windows Server 2003. It is essentially the same as the server included in Windows XP Professional and Windows Server 2003, and it is very similar to the one included in Windows 2000 editions. It uses the Windows command shell (Cmd.exe) as the default shell. You can start and stop this server from either the Services MMC (Services.msc) or from the Windows Services for UNIX Administration MMC (Sfumgmt.msc). If you are using Windows and UNIX in a mixed networking environment, you might want to consider installing Windows Services for UNIX 3.5 to extend the capabilities of Telnet.

Windows terminal types

Likewise all of these services support a MIcrosoft emulation called "NVT". The NVT is responsible for translating operating system-specific instructions (keyboard codes or display codes) into a consistent set of codes that all Telnet clients and servers can transmit and receive. The NVT is what makes Telnet clients and servers capable of communicating with each other regardless of which operating system they are using. This is a limited vt100 terminal type with some added, non-standard features. By setting Anzio for vt100 to emulate you can get close to what the console emulation is.

For specific applications, you can set the terminal type in Anzio and Anzio will negotiate this terminal type with the telnet server. The telnet server will pass this on to the application as a default and all should behave OK. Of course there are exceptions and you may need to contact Microsoft if there are any problems.

Cannot connect to Server 2003 telnet server

By default, the Telnet server is enabled to use NTLM authentication on a Microsoft Windows Server 2003 computer. If no user profile exists for the user on the Telnet server, the user cannot connect to the server from a telnet client. This error occurs because a local user profile did not exist for you on the server. The problem will not occur if you enable NTLM authentication after your user profile is created on the Telnet server.

SeattleLab SLNet

SLNet from Seattle Labs is a telnet server for Windows NT, 2000 or 2003 Servers that allows for a true multi-user system. SLNet enables an unlimited number of users to work invisibly and simultaneously on any Windows server without interfering with one another or the server console user. Additionally, SLNet optimizes the telnet protocol between Radio Frequency (RF) devices and Microsoft Windows servers.

SLNet supports ANSI emulation with some exceptions talked about below. Anzio should be set to use the SCO-ANSI terminal emulation for best results.

SLNet Screen Display and Anzio's Review Buffer

SLNet keeps full screen images in  memory on the NT and does not use any scrolling method. In this manner, SLNet knows exactly what goes where on the screen. Because of this, no screen scrolling takes place and any screen refreshing is done by the host always as a full screen image. Within Anzio this means that nothing gets scrolled in to the Review buffer except the current screen.

SLNet Keymapping

Because of the lack of ANSI special keys handling, SLNet has its own sequence of characters that can be sent to the NT to handle the special keys commonly found on a PC keyboard and in use by applications. These keys are defined below. In order to further enhance the use of Anzio with SLNet, we have set up a new keys file with the majority of these mappings. Download the file slnet.kys into the current Anzio directory and do a File : Read Keys to load. This keys file contains the standard ANSI keys as well as many of those listed below. Some of those key sequences listed below are not included, i.e. Alt-Z, because Windows and Anzio may use them for other reasons. In this case use the Ctrl-A sequence described below.

SLNet Piping

Another limitation in SLNet and NT is that standard escape and control sequences are stripped by the telnet daemon in order to not interfere with emulation and the standard connection. However, NT and SLNet provide a means of getting around this with "Named Pipes". Within SLNet the named pipe is an environment variable assigned more or less at random, that allows you to send raw data to the net connection.

There are several areas where this must be used. An example would be if your particular application is handling terminal emulation-specific escape sequences for other than ANSI, i.e. Wyse50. Then screen output would need to be piped to allow the terminal emulator, such as Anzio, to respond correctly to the Wyse50 codes.

Likewise, in order to do passthrough printing, to send the proper escape sequences to turn it on and off, you need to pipe this output to the named pipe. An example is found below. 

Setting Up SLNet Passthrough Printing

SLNet does not allow escape and control sequences to go directly to the host. These types of screen output must be "piped" to the proper "named pipe". In order to do this for passthrough printing, you would need to do the following sequence.

cat nt-printon anyfile nt-printoff > \\.\pipe\%PIPENAME%

where nt-printon is a file containing the sequence to begin passthrough and nt-printoff is the sequence to end passthrough printing. "anyfile" would be any file on the NT that you want to direct to the printer. An example script file can be downloaded. Passprtnt.bat is an NT shell script file that the user can run to print a file. The scripting is below. The two needed files may also be downloaded from our web site. nt-printon and nt-printoff, and should be loaded into your NT working directory and used to initiate a passthrough print.

@echo OFF
@if not "%ECHO%"=="" echo %ECHO%
cls
rem Passthrough Printing Example for Windows NT and vt emulation.
rem   Version 1.0 (uses NT4.0 shell scripting)
rem    
rem
rem This is written for the Seattle Labs telnet daemon (SLNet).
rem The general procedure will differ by daemon, but in brief
rem since you cannot echo escape sequences on NT with
rem every telnetd, you may need to find an alternate method, such
rem as the PIPE method of SLNet.
rem
rem In this example you will need two additional files,
rem nt-printon and nt-printoff, available at our web site
rem   http://www.anzio.com.
rem These files include the escape sequences for the vt terminal type.
rem

if "%1"=="" (
   cls
   echo Passthrough Print for NT, version 1.0
   echo     Format is passprtnt [filename]
   goto :ENDIT
)

if not exist nt-printon (
   cls
   echo Passthrough Print for NT, version 1.0
   echo     Requires both nt-printon and nt-printoff
   goto :ENDIT
)

if not exist nt-printoff (
   cls
   echo Passthrough Print for NT, version 1.0
   echo     Requires both nt-printon and nt-printoff
   goto :ENDIT
)

echo Windows NT Passthrough Printing With Anzio
echo Printing %1
cat nt-printon %1 nt-printoff > \\.\pipe\%PIPENAME%
cls

:ENDIT
echo NT Passthrough Print Done.
@echo ON

Other NT Telnet Servers

There are, at last count, about 200 vendors doing commercial quality telnet servers for Windows NT. Also, you will find a number of free telnet servers available on the market, including one from Microsoft.

Caution should be taken when purchasing a telnet server. Features and capabilities vary quite a bit, and some of the freeware/shareware ones do as well as the commercial ones, but provide no tech support. Microsoft's basic telnet server for NT is about as simple as you can find. You really should talk with the vendor of the host (NT) application you are running to find out what telnet server they have developed around or recommend.

A little more on Microsoft's products. There are actually two different telnet servers for Windows NT and two for Windows 2000. Each product ships with a basic telnet server. But then just to confuse things a little, a more robust telnet server ships with the Windows Services For UNIX package which can be downloaded from Microsoft's web site. The SFU telnet server behaves similar to the basic one, but does handle more options and is a good alternative to most commercial products.

Again, check with your application vendor.