Copyright/License/Warranty *

About ZanNet - What is it? *

Operating System and Software Requirements *

Installation, Setup and Removal *

Installing ZanNet for Multiple Users on Port 317 *

Unix Compiling and Compatibility *

Known Limitations, Problems and Other Notes *

Performance Considerations *

Using ZanNet with a Firewall *

Ordering Information *

Product Support *

Zan Software Contact Information *

ZanNet, Copyright 1996-1998 by Zan Software

All Rights Reserved.

Please read the following terms and conditions before using this software. Your use of this software indicates your acceptance of this license agreement and warranty.

This is not free software. You are hereby licensed to use this software for evaluation purposes without charge for a period of 30 days. If you use this software after the 30-day evaluation period a registration free is required. All pricing and order information is available from www.zannet.com.

Unregistered use of ZanNet after the 30-day evaluation period is in violation of U.S. and international copyright laws.

You are hereby licensed to make as many copies of the trial version of this software and documentation as you wish; give exact copies of the original trial version to anyone; and distribute the trial version of the software and documentation in its unmodified form via electronic means. There is no charge for any of the above.

You are specifically prohibited from charging, or requesting donations, for any such copies, however made; and from distributing the software and/or documentation with other products (commercial or otherwise) without prior written permission.

One registered copy of ZanNet may either be used by a single person who uses the software personally on one or more computers, or installed on a single workstation used non-simultaneously by multiple people, but not both.

This agreement shall be governed by the laws of the State of Washington.

THIS SOFTWARE AND THE ACCOMPANYING FILES ARE SOLD "AS IS" AND WITHOUT WARRANTIES AS TO PERFORMANCE OF MERCHANTABILITY OR ANY OTHER WARRANTIES WHETHER EXPRESSED OR IMPLIED.

Good data processing procedure dictates that any program be thoroughly tested with non-critical data before relying on it. The user must assume the entire risk of using the program. ANY LIABILITY OF THE SELLER WILL BE LIMITED EXCLUSIVELY TO PRODUCT REPLACEMENT OR REFUND OF PURCHASE PRICE.

ZanNet is a Windows 95 or 98 network client and Unix server that provide you with a Windows 95/98 network drive to access your server files. The product includes network provider and redirector for Windows 95/98 in addition to a Unix server. The server portion ships with both POSIX compliant source code and binary support for select Unix platforms. ZanNet is intended to replace both File Transfer Protocol (FTP) and Telnet programs currently used to access web page and other files through an Internet Service Provider (ISP).

Windows to Unix networking is not new. There are a number of solutions including the Network File System (NFS) and Samba. Unfortunately, with today’s fledgling Internet service market, very few service providers are willing or able to give their customers access to these servers. In most cases, Windows users that want to manage a web page must do so using both FTP and Telnet. With ZanNet you can get the functionality of a Windows network drive without requiring any configuration on the part of your service provider. Additionally, the ZanNet client is designed to handle slow or dead servers by allowing you to stop network I/O at any time through both hot-key sequences and control buttons. This feature is extremely important for applications that have the potential to lock-up Windows while waiting for network I/O (for example the Windows Explorer).

To use ZanNet you must have Windows 95/98, Microsoft’s TCP/IP Protocol, WinSock, and an Internet connection. The ZanNet client is installed in the same fashion as any other network client (see installation instructions later for details). Once the client is installed, and assuming ZanNet is not already installed on your Unix machine, you must install the server portion by uploading either the source or binary files depending on whether binaries for your version of Unix are included. When both client and server are ready, you need to add a new ZanNet server so the ZanNet client can login to the Unix machine and execute the ZanNet server. Once the server is started, it will open a connection back to your Windows machine through a TCP/IP port that you can define in the client configuration. The ZanNet client uses WinSock to establish a control connection through either Telnet or port 317 to the server while regular file system requests are handled at the Windows driver level directly through the Microsoft TCP/IP stack.

Telnet is no longer required for ZanNet user authentication. Now, you can install a single ZanNet server on your Unix machine that authenticated users on port 317. Read the section called Installing ZanNet for Multiple Users on Port 317 for further information.

Once ZanNet is set up, you can configure it so that Windows automatically maps a network drive to your Unix shell account whenever you establish a connection to the Internet. Then, manage your web files through whatever Windows utility or application you like. Be sure to read sections Known limitations and problems and Performance Considerations for notes on using ZanNet.

The ZanNet software package consists of a Windows 95/98 client and Unix server. Source code for the server portion is also included, allowing ports to various Unix platforms. Because that source code is POSIX compliant, other operating systems supporting the POSIX standard may be compatible with ZanNet source code.

• Windows 95 or 98.
• WinSock running on Microsoft’s TCP/IP Protocol.
• An established Internet connection or LAN.

In most cases, ZanNet will NOT work with other TCP/IP stacks from vendors other than Microsoft. The ZanNet client interfaces with both WinSock and Microsoft’s TCP/IP VxD Interface. Confused yet? As long as you are running the TCP/IP protocol that came with Windows 95/98, you should be fine.

• A Unix style shell account that uses Telnet, or the ability to login as root and install ZanNet with the Unix Internet Daemon.

• File Transfer Protocol (FTP) access to that account or other type of file transfer.

• A ZanNet server binary for your Unix operating system and hardware platform or C compiler access.

Before you begin installation of ZanNet, we assume you have Windows 95/98 with a working Internet or LAN connection. Additionally, you should be running Microsoft’s TCP/IP Protocol and Microsoft’s WinSock (both are shipped with Windows 95/98). You can verify the protocol by checking the Control Panel | Network dialog where you should see TCP/IP listed as an existing component.

To install the ZanNet client, click on the Add… button within that same dialog and select Client as the type of network component you want to install. Click on that dialog’s Add… button to get to the Select Network Client dialog. Here, you need to click on the Have Disk… button where you can click Browse… to get to where the ZanNet files are located. Once you are in the directory where the uncompressed ZanNet files are, you should see zannet.inf highlighted. Click on OK. Click on OK again in the following Install From Disk dialog. Two more OKs are required on the next two dialogs (Windows may require the installation disks after the final OK).

WARNING: Don’t unzip the ZanNet files to a directory location that contains long file names. The Windows INF file install has problems with long directory names. We suggest that you unzip the files to a root based directory such as \zannet.

After rebooting your computer, look on the lower right hand corner of your screen. If the ZanNet client was installed correctly, you should see a blue "Z". Seeing this tray icon indicates that both the ZanNet Network Provider and Network Redirector were installed correctly and have been loaded. This is also an indication that the redirector has found the proper version of TCP/IP. If you get a load error such as "Can't load redirector", you may not have the required version of TCP/IP.

If ZanNet is not already installed on your Unix machine, you can install the server once the client has been successfully installed. The first thing you should do is verify your Unix operating system brand (Linux, SunOS, etc.), version, and hardware platform (Intel, Sparkstation, etc). ZanNet Release I currently ships with the following Unix binaries:

zanserv.lnx -- Linux for Intel compiled with version 2.0.27

zanserv.sos -- SunOS for Sparkstation compiled with version 5.5.1

zanserv.bdi -- BSDI for Intel compiled with version 3.0

zanserv.aix -- AIX for IBM RISC System/6000 compiled with version 4.1.4

By the time you are reading this, there may be more binary support. Just check out our web page (www.zannet.com).

If you don’t know what type of Unix your provider runs, login to your shell account and type:

uname -a

Where you will get the Unix brand, machine name, operating system version, and machine type. Check the man page on that command for your Unix implementation to see how this information is ordered (man uname).

If ZanNet provides binary support for your Unix, simply upload the appropriate binary to your shell account using FTP or similar tool. Once the file is in your home directory, you will have to make it executable. Something like this:

chmod 755 zanserv.sos

Then, just type in the name of the binary to verify that it will load on that machine. You should get output similar to this:

Tip: Most of the preceding usage information is for running ZanNet as a permanently installed server through inetd. If you are using ZanNet through Telnet, just ignore this usage information. You will never run the ZanNet server by hand using the Telnet interface.

If the binary does not load, you will get output like this:

That output indicates that the binary is not compatible with your Unix platform. Make sure you have uploaded the correct binary. If you still can’t get it to load read the section on Unix compiling and compatibility.

Tip: Some Unix implementations—most notably Linux—don’t have the current directory in the path and require you to preface the ZanNet server executable with ./, or ./zanserv.lnx. Also, make sure of the case of your binary once it is on Unix. Unix is always case sensitive, so you must type in the same case as you see with a listing command (such as ls).

Once you have the server installed correctly, you are ready to add a new ZanNet server with the Add Server Wizard. First, double click on the blue Z tray icon. That will bring up an agreement dialog for the trial version. Read the agreement and click on I Agree… The ZanNet property page will be followed with the ZanNet add server wizard. Follow the instructions for each page and click on Finish at the end. Your new server, named with a combination of Unix host name and user name, will be added to the server list box.

If, at any time, you wish to change the above server setup information, simply highlight the server, and click on Properties…, or just double click on the server name itself. You can add and remove servers with the appropriate Add… And Remove buttons.

The ZanNet property page also contains tabs to configure global properties. Be sure the flip through these pages and read the documentation on each property page.

After you have configured a new ZanNet server, initiate a login by mapping a new Windows Network Drive. You can map a drive by right clicking on the My Computer desktop icon and selecting Map Network Drive. Or, simply right click on the blue Z tray icon and select the server that you would like to map.

If you mapped the hard way (without the tray icon), Windows will bring up its Map Network Drive dialog with the next available drive letter selected. In the Path edit field, you need to enter the Universal Naming Convention (UNC) path that corresponds to your server’s Telnet host name and the user name for your shell account. The Unix host name should correspond to whatever you specified for your Hostname or IP Address in the server properties. For example, if your Unix host name is:

You would specify the following in the server properties:

And then map the new network drive to the following UNC path:

Where, myusername is the user name for your shell account and login.whatever.com is the Telnet hostname. Make sure you put double back slashes before the host name and a single back slash before the user name. The ZanNet client network provider will parse the UNC path and connect to the host using WinSock. If you did not previously enter a password, you will have an opportunity to enter a password and may elect to cache that password. Once the connection has been established, the tray icon will turn yellow. If the server successfully connects back to your Windows machine, the tray icon will turn green.

The best way to remove ZanNet is to bring up the Windows | Control Panel | Network configuration, select Zan Software, ZanNet Client, and click on remove. You can also remove ZanNet from the opening agreement screen by clicking on the Remove ZanNet button, or in the Registration property page with the same button.

You can install ZanNet on Unix port 317 instead of using Telnet for user athentication. Port 317 has been assigned by the Internet Assigned Numbers Authority (IANA) for the sole use of ZanNet servers. The server binary is the same for Telnet—the difference is that you must install it with the Unix Internet Daemon (inetd). You’ll notice that ZanNet connections are faster without using Telnet. Basic instructions are also included in the usage instructions for the server—just execute the ZanNet binary with no options.

A ZanNet server running in daemon mode on port 317 uses the same user security rules as the FTP server on that Unix system. There is a file called /etc/ftpusers on your system that specifies users that may not use FTP (usually root). The ZanNet server will abide by this same file when validating users. In addition, the special guest logins ftp and anonymous are allowed just like FTP (unless specified in /etc/ftpusers).

On some platforms a ZanNet server may be even more secure than it’s FTP counterpart. The FTP server daemon allows users to "shell out" to run system commands such as ls for directory listings. ZanNet does not allow any user interactivity other than normal file system commands.

You must have root access to your Unix machine and login as root to install ZanNet with inetd for multi-user access. The first thing that you’ll need to do is specify ZanNet in the /etc/services file as a service that uses port 317. Again, port 317 is reserved for ZanNet by IANA. However, you may change that port with the /etc/services file. The following line should be added:

Once that is done, add your ZanNet server to the Unix Internet Daemon configuration file. This file is called /etc/inetd.conf. Add a line similar to this:

In the above example, we have added a ZanNet server binary that is located in /usr/sbin and is called zanservd. We have specified this server as type stream, using tcp, and running as root (for the initial login). (If you don’t run the server as root, it will not be able to change user ids.) At the end of the line you’ll notice the use of the –m option. This option instructs ZanNet to act as a muli-user server, and validate each user as they login. You can’t use the –m option in Telnet mode.

ZanNet has a few options that you can use in multiuser mode. In Telnet mode, you may have noticed the –I and –P options in the debug window. These two options are considered hidden, and would never be used in multi-user mode. The following options are used in multi-user mode:

For a large number of ZanNet users, it’s usually best not to use the –r option. By not allowing home directory changes, you can prevent people from further loading the Unix system by floating around in rather large directory trees. ZanNet must map each path to Windows format on your server which does require some server processing time. In addition, it’s best not to allow your users out of their home directories for increased security.

Once you have added the ZanNet server to both the /etc/services and /etc/inetd.conf files, you must instruct the Unix system to re-read the inetd.conf and start any new servers. One way to do this is by rebooting your Unix system. An easy way is to send a special kill message to the Internet Daemon. First, you must get the process ID of inetd. Do that with the following command:

The far-left number is the process id. (Make sure you use the one for inetd, not for the grep inetd command.) Once you have the process id, execuate the kill command for that id with the following syntax:

The above example is for a inetd process id of 147. The –HUP kill option will send a hang-up signal to inetd, causing it to re-read its configuration file and start any new servers.

There are a few things on the ZanNet client setup that are different while using inetd and port 317 rather than Telnet. Here are the changes:

Server Properties | Unix | Server Binary Name – This will be ignored.

Server Properties | User | ZanNet Server or Telnet Port – This should contain the port number 317 or whatever port you specified for ZanNet in the /etc/services.

Server Properties | Login – You must select "My Unix server has ZanNet pre-installed."

If all is well, you’ll see the login prompt ZanNet login: in the debug window, followed by the ZanNet client logging in. If the login does not work, but you see the special login prompt, you may have forgotten to specify My Unix server has ZanNet pre-installed.

Can’t get a ZanNet server binary for your Unix implementation? Don’t worry, it’s a snap to compile the server. First thing to do is upload the files: zanserv.c and zanserv.h to your shell account. This is extremely vanilla C code written under the POSIX.1 standard. Once those files are uploaded type in the following:

cc -o zanserv zanserv.c

Tip: Make sure that you list your Unix directory and check to see what case zanserv.c and zanserv.h are. Some FTP programs may change the cases.

The command prompt should return to you with not errors. If you got something like this:

cc: Command not found.

That is bad news. Your service provider does not provide you with C compiler access. In this case you must either beg your provider to compile it for you, or get a ZanNet server binary from somewhere on the net. Some compilers (most notably the gcc compiler) allow you to specify multiple target machines. Perhaps you can find someone that will compile the source for your target operating system and architecture.

Note: SunOS and Solaris users may need to type the following:

Note: If you have a compile error (such as a crypt() link error on BSDI). Try compiling without ZanNet's multi-user mode. Binaries compiled without this mode will not work under inetd:

Verify that your binary has compiled successfully by typing zanserv at the command prompt. (See the previous section for the output you should get.)

Don’t forget to modify your login script to match the name of the server binary!

Note: In order to keep the compilation simple and clean we chose to keep all server code within a single C source file. Also, there is no makefile either. Though some may consider this poor project management, our design requires server simplicity both in source management and object code.

Once you have compiled your new Unix binary it’s a good idea to test it with the included test program: zanapi.exe. Run this program from any MS-DOS prompt against a mapped ZanNet drive like this:

Where f: is the ZanNet drive letter. The test program will exercise all of the Windows File System APIs against your newly compiled binary.

Once your new binary can successfully pass the zanapi.exe test program, we ask that you check www.zannet.com, and see if your binary is in the ZanNet binary list. If not, we ask that you upload your new binary using the binary upload page so that people without compiler access can take advantage of your compiled ZanNet server.

If your Unix implementation requires that you make a change to the ZanNet server source code, we ask that you send us the change(s) so that we can include those changes in future releases. Please include any required #ifdefs so the code will compile with all current Unix versions.

• The file system request: FS_LockFile is not supported. This request handles the Win32 functions: LockFile() and UnLockFile() and the DOS INT 21h function: 5Ch. All file region lock requests currently return successfully. This may break some applications (notably: Microsoft Access).

• Overlapped I/O, used by the Win32 functions: WriteFileEx() and ReadFileEx(), is not supported by the ZanNet file system requests: FS_ReadFile and FS_WriteFile. Not many applications are using overlapped I/O, and none should be dependent on it.

• The Windows attributes: Archive, Hidden, and System are not supported. While these attributes can be set without error, they will never be reported. This could possibly break some applications—most notably backup programs.

• The FindFirst must match attributes are not yet supported. This may break some applications. Also, case sensitive file searches are not supported.

• All files are opened fully read/write sharable (OF_SHARE_DENY_NONE). Sharing flags will be ignored, but will return successfully. The user must manually guard against problems with file sharing. I.E. don’t open the same file twice over ZanNet.

• If you elect to disable read and write streaming through the property page Performance, some applications will run poorly. Most notably are file compression software packages which tend to make extremely small file system reads. Read section 7 Performance Considerations for more on this.

• File size is limited to 4 gigabytes.

• The disk usage report is approximate and may not exactly match statistics reported from the Unix command du. Disk space remaining is calculated by recursively traversing down the file tree starting from your home directory. If your tree is very large you should disable this feature by setting Max. Server readdirs for Diskspace to 0.

• You cannot browse a ZanNet network through the Windows Network Neighborhood. ZanNet does not really fit into this method of browsing. This feature may be added in the future.

• Command line NET commands such as NET USE are not supported and may cause unpredictable results.

• You cannot map multiple drive letters to a single shell account. You can, however, map multiple drive letters to multiple, different shell accounts.

• Some service providers do not allow multiple logins to a single shell account through Telnet. With a provider such as this, a mapped ZanNet drive will make it impossible for you to login with a regular Telnet program. Simply disconnect the ZanNet drive to resolve this contention.

• If you use a Unix host name, the ZanNet server must be running on the same IP address that you Telnet in to. In some rare cases, a provider may route your Telnet login to another machine that does not match what the name server returned to the ZanNet client. You can avoid this problem by specifying a Unix Server Final Address in the Unix property page.

• Right mouse button click on .exe files results in many file system calls and will respond very slowly on slow connections.

• Basing your server to the Unix system root is very slow because all server paths must be mapped to Windows paths. We suggest that you use the default for best performance.

When you are using the ZanNet, there are a number of things to kind in mind. First of all, if you have never have experienced a network drive over a slow connection such as a with a modem, you may find it very frustrating to use this product. There is just no comparison between hard drive speeds and modem speeds. Additionally, many applications are developed on, and designed for hard drives, and or, high speed local area networks. Some such applications use a ridiculous number of file system requests. For example, we have seen a few that make sure the file is present (FindFirstFile()) for every mouse click! Even though there is very little data transferred in this scenario, just the ping time can cause a one second delay for that mouse click. We leave it up to you to weed out any such applications. For example, Windows Notepad works great for a quick update of HTML, while some HTML specific editors get a little carried away with backup files, etc.

If you are operating without ZanNet streaming enabled keep your buffer sizes in mind. Try right mouse clicking on the ZanNet tray icon. Select Status. That will bring up the ZanNet Status dialog. Our network redirector posts status for file open, close, read, and write to this dialog for all volumes. Here is a rundown on the fields of the status dialog:

Server: The server name in UNC format (ex. \\login.whatever.com\myusername).

File: The name of the file (ex. index.html).

Operation: What kind of operation just completed (ex. Write).

Bytes Moved: The number of bytes moved since the last report (ex. 16384)

File Position: The current file position after that operation. (ex. 97792)

Speed: How much time in kilobytes per second that operation took (ex. 2.6k/sec).

Last Update: When the status was last updated (ex. 16:1:21)

For example, suppose you are extracting a file from a .ZIP archive and you notice it is taking an incredibly long time. After pulling up the status dialog, you see that the application is performing many tiny reads of less than 20 bytes. The application is depending on file caching for good performance. Those little buffers are adding a HUGE overhead because a read request must be sent to the server to fill each buffer.

Another Windows caveat to keep in mind has to do with the Windows Explorer. For whatever reason, the Explorer seems to be single-threaded, and tunes its buffer sizes to match the speed of your connection! That way, a very poor connection may have 512 byte file copy buffers, while a better connection may use 4096 byte buffers. Why do you care? When you operate ZanNet without streaming enabled, each read (or write) must be requested by the client adding somewhere around the ping time for each read. For example, if it takes ¼ of a second to reach a given server, that time is added as overhead for each read buffer. Take a 100,000 byte file with Explorer using 4096 byte buffers. 100,000 divided by 4096 is around 24. Multiply that by ¼ seconds gives you an overhead of about 6 seconds. Not bad, but if you do the math for a 10MB file using 512 bytes buffers, you’ll see why we think this is a concern.

Also, know that the Explorer does a connection speed calculation before it copies a file. Could be a problem if your connection is flaky during this time.

Our recommendation is to enable both read and write streaming whenever possible.

We all are painfully aware by now that the Internet if far from perfect. Most popular WinSock applications have some kind of stop button or other mechanism to abort a file transfer. The ZanNet design required the same functionality, but, because the ZanNet client is a network redirector running as a VxD, a simple button would not suffice. Though you may not be aware of it, there are many cases where Windows locks the user front-end waiting for I/O (Explorer does this). Makes it kind of hard to click on a button!

We solved the I/O killing problem with a variety of techniques. The first, and probably most powerful, is a hot-key sequence. This hot-key goes directly to the ZanNet redirector VxD. The actual hot-key can be configured in the ZanNet Properties | I/O Control. On that page, you’ll notice something called: Time, in seconds, that ZanNet considers an I/O request "dead". When you hit the hot-key, the redirector goes through it entire list of I/O requests for all ZanNet volumes. Each request that has been waiting for a response for more than the dead I/O seconds value is flagged as an "Unexpected Network Error" and the application thread is released with that error code set. You can set this value to 0 to make the redirector abort everything.

When the thread that requested ZanNet I/O returns, the application sees the error and hopefully aborts I/O. Many times the application will request a file close after the returned error in which case you’ll have to hit the hot-key again. You may have to kill the application if it does not behave properly. Of course, it’s always best to disconnect the network drive for problem servers if you can get to Windows.

The ZanNet status dialog contains two stop I/O buttons. The first called Stop This File’s I/O will stop I/O (in the same way as the hot-key) for the file listed in the status dialog only. This method is much less destructive than the hot-key because it will only abort a given fill, not the every pending request. Please note that you should always try to use whatever the application provides for stopping a request first. For example, the explorer has a Cancel button for file copies.

The other button in the status dialog is Stop All ZanNet I/O Now! This one produces the same effect as a hot-key sequence with a 0 second dead I/O value (see above). There is also a menu item on the tray icon called Abort All Dead I/O which has the same effect as the hot-key sequence.

You can use ZanNet with any firewall that supports SOCKS version 5. Read more about SOCKS from www.socks.nec.com. SOCKS is a generic protocol that provides a method to traverse a firewall for TCP applications located behind that firewall. ZanNet will not work with WinSock replacements that handle firewall traversal—one such example is called SocksCap. Though ZanNet does use WinSock for user authentication and debug messages, the actual file system data is transferred at the driver level, bypassing the WinSock layer, and communicating directly with TCP with the Transport Device Interface (TDI).

If you do have a SOCKS v5 compliant firewall, configure ZanNet for SOCKS from the Server Properties | Firewall property page. You will need to add the SOCKS server name and port. Most SOCKS servers use port 1080. Consult the property page for further information.

ZanNet SOCKS v5 firewall support was developed and tested using the WinGate SOCKS Proxy Server version 2.1. You can find out more about WinGate from www.wingate.net. If your firewall does support SOCKS v5, but ZanNet will not traverse it, please let us know.

All ZanNet ordering information is available from the following web page:

http://www.zannet.com

Once your order is processed, you will receive a registration key. That key should be entered in the Registration page of the ZanNet properties. When your registration key is entered, your ZanNet software will change to the registered version as opposed to the trial version.

All ZanNet product support information is available from the following web page:

http://www.zannet.com

All Zan Software contact information is available from the following web page:

http://www.zannet.com