V1.0 09/21/95 Original written for 2.01
V1.1 06/06/96 Added sections with information on UW 2.02,
2.03, and SCO UW 2.1 along with an introduction to TCP/IP.
Revised things throughout to reflect the changes in the
connectivity software that occured since UnixWare 2 was
released.
Sorry that these Table of Contents links don't work; I'll fix them when I get some time.
One of the major attractions of Novell/SCO's UnixWare (UW) product is its built-in support for NetWare (NW) connectivity. The potential for transparent access between these two types of systems had lured many people familiar with one type of system (either Unix or NetWare) to try out UnixWare and become familiar with the other. Some of the configuration and troubleshooting procedures for getting these connections working are very complicated, however, and the documentation is less then complete in parts. Having spent a considerable amount of time myself producing a working, integrated NW/UW system, I can tell you that knowing what a working system is supposed to do is quite useful in figuring out what is wrong with yours. This article attempts to mix information about how a working system acts with some troubleshooting advice for when one doesn't. Note that I only deal with running these systems with an IPX network, since that's what I'm using, and that's what the majority of NW sites have; if you have a TCP/IP network running, the configuration details are somewhat different (I get into that a bit at the appendix).
It's easy to tell if you have a correctly configured UW system connected to a Novell NW Network. Start up UW and (from the desktop) open the NW folder that appears in the main desktop window. It will show all the NW servers on your network. Double-click on one of them, and a login box will appear to attach you to that server. After logging in, a listing of all the disk volumes on that NW server will appear. Double-clicking on one of these will show all the files on that volume, and you'll be able to traverse the directory tree.
The UW documentation leads you to believe that loading the NW Unix Client (NUC) NLM on your NW server is the first thing you do after installing UW to fix all your problems. Loading NUC is actually close to the last thing to worry about; most of the functions involving NW do not require it. In fact, there is very little configuration that needs to be done to get the basic connections working; if things don't work as expected, it's probably not because you haven't loaded some of the high level software like NUC, it's probably something more mundane like a network card configuration problem. Let's take apart the previous paragraph step-by-step and see what's really involved in each one of them to get your system working.
UW recognizes the NW servers on the network it is connected to by looking for Service Advertising Protocol (SAP) packets from the NW server on that network. In order for this to happen, several things need to have happened:
There are several packages of UW software that need to be loaded to make NW connectivity work. First, you need to have installed the nics package that supports your network card. This is where you specify the IRQ, I/O address, and buffer address for your card for ISA cards (or EISA/PCI slot information), just as you would with NW.
It's possible that a configuration conflict will make your UW network card able to broadcast packets but not receive them. You can check if this is happening by watching the traffic on the NW system, which is covered later. If this is what you notice it is probably a conflict with the IRQ or the buffer address; it is possible to send packets even if all you got right is the I/O address, but you can't receive them unless all three are correct and don't conflict with other settings in your computer.
What I usually do if I'm not sure the network card is working right is drop back a step. Get out of UW, and see if you can connect the computer to the NW network as a regular old station. You'll get more informative error messages out of loading the plain old DOS workstation drivers then UW will tell you.
If you need to reconfigure the settings for your network card, the correct thing to do is to reinstall the nics package from the original installation media (probably a CD). With UW 2.1, there is an easy nics_setup program in the Networking folder that handles this. Dealing with nics is the way get back to the configuration screen where you enter all the parameters.
The other packages required to get connectivity working correctly are nwnet, nuc, nwsup, and nsu. Make sure all these packages are installed. Configuration for these is done with the NW Setup program on the UW desktop. Most of the parameters shown are correct for just about every installation with the default values. The only items you really need to check are under the Logical LAN Configuration section. The LAN Device gets automatically filled in with your network card information. To figure out what frame type to use, what the External LAN address for your NW network is, and get the UW system configured to match, you can LOAD MONITOR on the NW server. Choose LAN Information, select the appropriate network card, and a screen showing the frame type and network address will appear. Get the UW Logical LAN settings to match these (see the TCP/IP section below for more information if you have multiple frame types listed for the network card). Those should be the only items you need to configure for your initial connections, the rest are optional parameters you can leave alone for the moment. The system will reboot itself after this configuration change. With UW 2.1, the frame type and network number have always been detected automatically on my system, so that's one less thing to worry about (I didn't have to do anything to get the NW systems to show up).
Obviously, the NW sever needs to function properly with the network card installed in it. You can verify it is functioning correctly by logging on that network with an already configured workstation.
This is an obvious potential problem that usually can be verified by using that cable in another, known to be correctly configured application (i.e. using that piece of cable for a workstation connection elsewhere that you know to be good).
After these items are taken care of, you should see the NW servers on your network in the NW window on the UW machine. If you don't, the next thing to do is see if the problem is with the NW side or the UW side. The easiest way to do this is with the NW TRACK ON command. After executing this command on the system console, you can watch the network traffic that the NW server sees. After executing TRACK ON, reboot the UW computer. When it gets to the part where it loads the IPX drivers, some communication will occur between the UW server and the NW server over their common network, as SAP packets are sent and routes are traced. After this, the UW server will show up in the DISPLAY SERVERS listing on the NW server. Here's what typical traffic on the TRACK display looks like as a UW server connects and introduces itself to the NW network. In this example, 00000006 is the external network number for this segment of ethernet, while 00000009 is the internal network number. 0000C0E2CE12 is the MAC address of the UW computer. OLP1 and OLP2 are the names of the two NW servers on the network, while OLP4 is the UW server.
IN [00000006:0000C0E2CE12] 2:56:44pm Get Nearest Server OUT [00000006:0000C0E2CE12] 2:56:44pm Give Nearest Server OLP1 IN [00000006:0000C0E2CE12] 2:56:44pm Get Nearest Server IN [00000006:0000C0E2CE12] 2:56:47pm Route Request OUT [00000006:0000C0E2CE12] 2:56:47pm 00000001 1/2 00000009 1/2 IN [00000009:000000000001] 2:56:49pm OLP1 1 IN [00000006:0000C0E2CE12] 2:56:51pm Send All Server Info OUT [00000006:0000C0E2CE12] 2:56:51pm CORP 2 OLP1 1 OUT [00000006:0000C0E2CE12] 2:56:51pm OLP1 2 OLP2 2 OLP2 3 IN [00000006:0000C0E2CE12] 2:56:52pm OLP4 1 OUT [00000009:FFFFFFFFFFFF] 2:56:52pm OLP4 2 OUT [00000001:FFFFFFFFFFFF] 2:56:52pm OLP4 2 IN [00000006:0000C0E2CE12] 2:56:52pm OLP4 1 OUT [00000009:FFFFFFFFFFFF] 2:56:52pm OLP4 2 OUT [00000001:FFFFFFFFFFFF] 2:56:52pm OLP4 2The Send All Server Info request is what shows all the NW servers in the NW windows under UW, while the OLP4 related packets are what establish the UW server in NW's server list. The portions of this communication that are missing should point you toward where the problem lies. Note that if you have the newest version of the IPX software, the listing shown above will be split across the two tracking screens, and will require very fast fingers to catch before it scrolls away.
After you have the two computers talking and showing up on each other's server lists, the next thing to do is try to log in from the UW server. After double-clicking on the desktop picture of a NW server, a box prompting for a login name and password appears. Type them in, and you should see a list of the volumes on the server. If you don't, there's usually problem with one of the steps listed about; usually errors at this point for me have been because of configuration problems with the NW side, causing it not to properly receive packets.
Starting in UW 2.1, UW expects that your NW server can deal with packet signatures, and in fact seems to require this (even if you go into the NUC setup and disable the packet signature features). If yours doesn't, after typing the login name and password you get a cryptic error (#8861) saying that you could not login to the system. What you need to do is this case is load PBURST.NLM on your system, which lets the NW server support packet signatures. Instructions on getting NW updates are in that section below. Watch out for loading this one, though; if your clients aren't correctly configured to deal with signatures themselves, you won't be able to log any NW workstations in after loading PBURST.NLM (and it is not a good thing, as I can attest, to accidentally disable logins on all the stations). In order to solve this problem, you can either fix the clients or disable the security on the NW server (probably the far easier things to do). You do that like this (a snippet from an AUTOEXEC.NCF):
load pburst set ncp packet signature option = 0If the login goes well, you are now attached to that NW server and can now print on it. You can configure the UW printers so that something sent to one of them actually prints on the NW print queue. This is all without loading any additional software on the NW server above the network card driver; you do not need to load the NUC.NLM or any of its associated NLMs to get these functions.
Before proceeding any further, you probably should check to see if there is updated UW software you should load. For my installation, running with 2.01, to get everything working properly I needed to download a UW patch called tf2000.ptf to correct some problems with the UW NUC support. You might want to search for similar updates for whatever version you have.
UW comes with an application called TNVT that allows you to run a text based session on the UW system from your NW workstations. The System Owner Handbook documentation covers getting this program installed on your DOS or Windows based workstation in the section titled "Setting up UW Terminal Emulators for Dos/MS Windows" in the NetWare Connectivity chapter. Running this software, you should now be able to get a text login prompt from any of the NW workstations on your network to the UW system. Again, this should work with no problems without loading NUC.NLM or needing to work with TCP/IP.
Some history here. The original version of NVT included with UW 1 was actually called NVT1. The version that comes with UW2 is actually called NVT2. What this means is that just because an application you see claims to support NVT, it might not work; it may only work with NVT1.
NVT1 required that you load an NVT TSR you activitated with Control-T is a similar key. From there you selected which NVT host you wanted, then ran the application that communicated over NVT1. Fair enough. Some programs (like Century's TinyTerm) use the same TSR and are supposed to work over NVT1, which means they don't work with an NVT2-based UW 2 system. Esker's Tun replaces the NVT TSR, but it doesn't appear to work with NVT2 either. Neither of these two companies seem particularly concerned with the omission last time I talked with them.
Other then the TNVT220 application that comes with UW (which is actually just a part of Novell's overall LAN Workplace package), the only other program I've found that worked with NVT2 is JSB's Multiview Desktop.
Also included with the portion of LAN Workplace that comes with UW, in the same directory as TNVT220, is a program called TELAPI. What it does is install an interrupt 14 handler frequently used by terminal emulation programs for connections. You can then run any program that supports an Int 14 terminal interface and communicate over NVT with it (examples include Kermit and Tun). I have had nothing but problems with this approach and do not recommend it.
In my opinion, if the TNVT220 packages isn't good enough for you, you should either consider moving to a full TCP/IP package (some are discussed in the appendix) or go for one of the Windows Winsock based configurations.
If things have went well so far, double-clicking on the server icon in the NW window on your UW system produced a listing of the disk volumes on that server. But if you have a version of UW before 2.03, they probably have red circles with a slash through them. If you try to open one of these volumes, you'll get an error telling you to load NUC.NLM. If everything else mentioned so far works correctly, now is when you consider doing this.
First, a note on what NUC will do for you. Reading the System Owner Handbook will tell you that you should be able to access the volumes on your NW server in NW mode even without loading NUC.
This only became true starting with UW 2.03 (actually you can patch 2.02 but that isn't common).
For version 2.01 of UW, if you want files off the NW server accessible to the UW server, you need NUC loaded and to have the NFS name space loaded on your volume. If you've got 2.03 or 2.1, you don't really need NUC normally, but it is useful if you want a more permanent, configurable way to copy files between systems without resorting to the desktop or using nwlogin.
Many people have been thwarted by the NUC.NLM installation, because it doesn't work as expected unless you have a very new server. The installation instructions are in the NLM Installation and Administration Guide, which you need to print your own copy of to get. If you tried to install NUC and get errors telling you that certain functions were not available, it's because you need some newer driver software installed on your server before installing NUC.NLM.
When I contacted Novell, I was informed that my Novell 3.11 server would never work correctly with UW, because it was so out of date and its drivers were so old (SCO tells a similar tale nowadays for their recent NW release). This is not true; what follows are the steps I took to take a fairly old (five years) Novell 3.11 server and make it capable of running NUC without any problems. Any time someone tells you the only way to solve a NW 3.11 problem is to upgrade it to 3.12, be suspicious; most of the patches nowadays for new NLMs are exactly the same on 3.11 as 3.12, it's only more likely that a 3.12 server has a new enough version, I have never had a problem like this I couldn't solve by patching up the 3.11 server.
You may be able to skip some of these steps, especially if you have a 4.1 server, because you may already have the proper, new, drivers installed. All of the drivers mentioned are available either from NetWire on CompuServe, from ftp.novell.com, from gopher.novell.com, or http://netwire.novell.com. In any case, I highly recommend installing the mainstream collection of NW patches on your server. Novell Tech Support keeps a listing of recommended minimum OS patches, I have solved many NW difficulties before simply by loading everything from that list that seemed relevant onto the problem server, you should check this listing out.
One of the pieces of NUC.NLM requires that you have the NW PATCHMAN extensions manager loaded. Most NW servers already have this essential utility installed, but if yours doesn't, you need it.
The version of TCPIP.NLM required is at least 2.02M. If you have an earlier version, download the TCP188.EXE (or the newer TCP31A.EXE which seems to work equally well) from one of the sources mentioned above. Running this program produces a series of files; you need to copy these to a floppy, put it into the file server, and LOAD INSTALL to install the update (details are give in the documentation for the update, after you execute the main file). Down the server and reboot it after this update.
You need a version of CLIB that is at least 3.12h. If you have an earlier version, download LIBUP8.EXE. Running this program produces a series of files that run from your workstation; you need to be logged into the NW server as a supervisor in order to execute the installation program. One time I got this file (around LIBUP5), it was mildly corrupted--there are supposed to be directories created by the program named 3.X and 4.X, but the copy I got had them named 3X and 4X; accordingly, the installation program wouldn't run. Creating new 3.X and 4.X directories and moving the files from the incorrectly named ones solved the problem; by the time you read this the original file should be fixed and you won't have to worry about this bit of a problem. LIBUP8 installs a variety of updated system components, as its documentation will describe; again, you need to reboot the file server after installing this update.
Following the instructions in the UW documentation, you should have produced two disks that contain the NUC.NLM program. Before you try and load it, be sure to LOAD TCPIP on the NW console; the installation doesn't work correctly if you don't. Also, if you want full remote console features for UW, you need to have loaded REMOTE and RSPX on the NW server; otherwise, you'll get a variety of messages saying that functions whose names begin with RS can't be accessed. After loading TCPIP, you can LOAD INSTALL and install the product update. The NUC installation will ask you where you ran the SERVER.EXE file from when you booted NW; this is probably C:\NETWARE, but if you're not sure, you'll need to down the server and look at the computer's AUTOEXEC.BAT to see for sure. After NUC installs, you should check what it did to your AUTOEXEC.NCF file to see if you're happy with it before rebooting. One thing to watch out for is that when the NUC program is loaded, a bunch of other modules will auto-load themselves; I have had this process overflow the stack on a server because the modules to auto-load were nested so deep. My solution is to make sure to LOAD TCPIP before calling the UNISTART.NCF file.
For reference sake, here's the AUTOEXEC.NCF on my 3.11 server after installing TCP188, LIBUP8, and NUC; everything here works correctly:
file server name OLP1 ipx internal net 9 load patchman load ne2000 port=320 int=B name=unix1 bind ipx to unix1 net=6 load remote password load rspx # Command to start LAN WorkGroup, NFS, and other products. load remfilfx load tcpip UNISTART.NCFAfter making sure you AUTOEXEC.NCF looks all right, reboot the server yet again and all the NUC programs should load properly. If they don't, you'll probably have to comment out the UNISTART.NCF line and load the items contained in it manually to see what the problem is. Here's what a sample UNISTART.NCF file looks like:
load tsaproxy load netdb load unixlib load nuc load xconsole
After doing all this, you'll probably find that nothing has changed with UW 2.01 or 2.02; you still can't access your NW volumes. Newer copies of NUC have all the problem worked out, but for older versions you need to add the NFS name space to your NW volumes in order to mount them under UW. To do this, type
add name space nfs to volume sysReplacing sys with whatever volume you want to be able to access. Do this for each of the volumes (note that this takes a fair amount of time to execute and uses up a portion of the your disk in the process). After this, the NW volumes should have the red circle-slash symbol removed, and you can open them up and look at the files. The load nuc command in the UNISTART.NCF can be modified to mount a different set of volumes, but on my configuration as given above all the volumes mount fine without any additional parameters.
This isn't so easy. With UW 2.1, you can load the NetWare services module and turn your UW server into a limited NW server; that's one way. It's possible to use the NUM NLMs to backup your UW server over the network. But I don't know of any general use way to get NW clients easily accessing files; you'll probably have to use one of thTCP/IP client solutions.
The UnixWare System Owner Handbook implies that you need to do bunches of configuration with hosts, password, and nfs users and groups before these functions will work. This is not true; you probably don't need to touch these files at all to make things work just fine. They are only necessary if you really want seamless file connections where all the permissions match across the servers and you can change the attribute of the files from either server. These are not files you must configure just for file transfers across the systems.
If you have a clear picture of what order to do things, getting UnixWare and NetWare connectivity running involves little above the normal routine of getting cards configured and drivers loaded. Hopefully this ordered walkthrough will give you an idea what order to tackle things in, what the potential problems might be, and what available functions to expect at each point in the configuration process.
Like any piece of software, UW continues to be refined and (hopefully) improved. The baseline for this document is UW 2.01, as originally released by Novell in April '95 or so. Since then a number of revisions to the OS have appeared. This section comments what changed in each update (most of this information is interspersed throughout the main document as well).
Note that in addition to the main OS updates, there are also HBA and nics updates that are weakly associated with each of these updates. I say weakly because you can (by my experience) mix any of the 2.0x HBA and nics versions with any main release. I ran for quite some time with UW 2.01 and NICS 2.01, but upgraded to HBA 2.03 as soon as it was available because of support for a new SCSI card I wanted to switch to. The NW connectivity information is totally unrelated to the HBA used as far as I can tell, but I'm not certain if there are any dependancies between NICS and NUC versions.
The NUC stuff in 2.01 was a bit immature, but I found it very stable. There were things missing, but what was there worked pretty well. Make sure to patch your UW 2.01 system with tf2000.ptf before doing serious NUC work.
This release folded a number of the patches generated for 2.01 into a somewhat coherant whole, but I saw no compelling reason to upgrade (and heard nothing but problems from those who did). 2.02 is a revision best skipped over. There's a patch available for 2.02 that adds support for accessing NetWare volumes with the DOS name space instead of needing NFS.
This is overall a good upgrade. The NUC package finally got support for the DOS name space added to it. The TNVT220 program got a big improvement. Unfortunately, myself and many others I've dealt with had a number of nagging problems with the NW connectivity in 2.03 that we couldn't resolve. My system kept giving me weird I/O errors when I tried to copy files from the NW system; it was all very strange, and e-mail I've received tells I wasn't alone in this strangeness. It's possible to make 2.03 work, but understand that this was never really an official, supported release and never really got any of it's problems fixed in a usable form; you have to keep moving up to 2.1 to get those fixes.
From my experience so far, 2.1 looks like a solid release. The only problem I've had is that the NW server needs to deal with packet signatures (as mentioned in the Logging into NetWare section) in order for you to login to it; NVT and TCP/IP work just fine without them, however.
The world certainly doesn't need another introduction to TCP/IP. All I wanted to touch on were some of the things that have been rough to straighten out when I first encountered them. Make sure to read over the TCP/IP book that came with NetWare for background. I'll try and point out the important items here. I have yet to fool with all the crazy configuration files they talk about in that book (the stuff in the ETC directory like the groups file), or run the IP configuration NLM, and everything works fine for me; I suggest ignoring those sections.
First off, don't even think of using the TCPIP.NLM that came with your system unless it's brand new; follow the instructions in the Updating the NetWare server section above to get a new one.
If your NW system receives TCP/IP packets that aren't for it, you'd expect that it would send them somewhere else, right? Well, by default it doesn't. In order to get NW to route IP packets for you (which is will be quite glad to do), you have to load the NLM like this:
load tcpip forward=yesAfter that, NW will help sort out all the IP mess and will forward things across networks it knows about for you.
NW talks IP over top of some other frame type that it can send IPX packets over. Old style NW networks running Ethernet used 802.3 frames, newer ones use 802.2. If you're not sure what the frame type on your NW network is, use MONITOR to find out (as described in the UW has the NUC software loaded and configured section above). When you load a network card driver in the server's AUTOEXEC.NCF, it uses that default frame type unless you tell it otherwise.
For Ethernet cards, the common frame types are the regular one used for IPX (802.3 etc.) and Ethernet II frames. In order to run TCP/IP over Ethernet, you need to use the Ethernet_II frame type. The sample AUTOEXEC.NCF below shows how to load a network driver twice (the ubiquitous NE2000 is used as the sample Ethernet card) with two different frame types and bind them both.
For Arcnet, there is only one frame type, so you don't have to worry about it.
I don't know anything about Token Ring (wasn't that one of the circles of Hell in Dante's Inferno?). You can check Novell's TCP/IP documentation for details on it.
Every computer on an IP network has an IP address. What address you use depends on what class your IP network is. If you don't know, you should become a Class C network. It limits you to 254 stations on each network segment, but it's easier to deal with. If you really have no idea what address to pick, use something that starts with 192.168; that collection of networks is publically available and isn't used by anything on the Internet, so if you should happen to connect your computer to it you won't screw up anyone else's connection (you really should have your own, registered IP address if you're doing that, but using this number will keep you out of everyone's way). You can make up to 254 networks within your system by changing the third number in the IP address. Since you need one network for every network card in your system, you may run into this. Check the sample below if you're confused.
This is only a portion of the AUTOEXEC, only the relevant parts are shown. This system works as an IP router. lslenh and msm31x are 3.11 extensions that allow newer network drivers to be used; if your network drivers don't need them (or use a different msm name), don't worry about it. Note how the NE2000 Ethernet card gets loaded twice with the same parameters but different frame types. The second network card is an SMC Arcnet card. Note how they get different TCP/IP network numbers (the third number in a class C network) assigned to them. Each of the stations needs it's own number that has the same set of digits for the first three numbers and a unique fourth number.
load lslenh load msm31x load tcpip forward=yes load ne2000 port=300 int=3 name=unix1 bind ipx to unix1 net=6 load ne2000 port=300 int=3 name=enetii frame=ethernet_ii bind ip to enetii addr=192.168.1.1 load smcarc port=380 memory=D4000 int=5 name=arcnet bind ipx to arcnet net=1 bind ip to arcnet addr=192.168.2.1
All right, so you have all your servers talking with TCP/IP. How do you get your NW stations to join the party? There's a bunch of ways, and few of them are pleasant. This is certainly not an authoritative guide to this subject, I'm just saying what I've done and how it worked out.
It used to be that in order to speak TCP/IP, what you did was load a packet driver for your network card. Novell's whole movement away from WSGEN'd IPX toward the ODI specification has made this old approach problematic; nowadays, it's far easier to get a driver you can load IPXODI on top of then a packet driver for any given network card. There's a free utility called ODIPKT that turns your ODI driver back into a packet driver again, you can then run all kinds of utilities on top of that (James River Group's ICE/TCP uses this approach for running over NetWare). ODIPKT works great if you have networking cards and protocols it works with, but if it doesn't work for you, it's not supported by anyone (the author is involved with Harvard University somehow and distributes the program for free, so there's not a lot of incentive for him to fix your networking problems). My experience is that ODIPKT works fine with Ethernet and not-so-fine with Arcnet (only the old V1.3 would work at all on my Arcnet network, and even that was spotty). Watch out.
The new thing everybody likes to use is a Winsock connection, which as may have guessed by the name only runs under Windows. I'm not real familiar with this approach for hiding NetWare cards underneath so I won't say much about it other then to mention its existance. There are drivers (usually called shims) that turn other types of drivers into Winsock-compliant versions of themselves.
Novell's recommended solution for dealing with TCP/IP is their LAN Workplace product. Parts of LWP come with UnixWare, presented as NVT utilities. The other big piece that you don't get is the main TCP/IP driver, which loads as a TSR and appears to work with any ODI-compatible network card. The main drawback is that the TSR is huge and accordingly sucks lots of precious low memory up (there's a Winsock version as well that supposedly can alleviate this if you only want Windows). If you need DOS and Windows access and have heterogenous networked stations (not just Ethernet), LWP seems to be the solution. There are lots of programs that support running over LWP; I've used Century Software's TinyTerm quite successfully to telnet into my UW system from NW stations that have LWP drivers installed on them.
If you've got a new NW server, you might want to investigate Novell's free for the download NetWare/IP software. Supposedly it dispenses with IPX all together and runs IP all over.
Another avenue to check out are the new products that deal with the IPX to IP translation at the server, keeping you from needing to load TCP/IP stacks on the stations (and from having to get unique IP addresses for everybody as well). Many of these are strictly WinSock translators, but some deal with DOS as well. I've been quite happy with using FireFox's Novix for this application; if you get the Novix for Workgroups applications, they include a LWP driver for it that handles everything I've thrown at it (DOS, Windows, Winsock, you name it, it just works and configuration was minimal; I only had to install it twice to get all the settings right and I haven't touched it again since).
This document came about originally as internal documentation generated for a project at Old Line Plastics and accordingly funded by them, but the problems solved seemed common enough that this distributable version was created. Thanks go to the Internet residents (from comp.unix.unixware) who helped me piece much of this together. Over at Novell, Dave Wilbur gave me a bunch of information on how NVT worked and Ann Davis told me how to get around the problem with packet signatures on UW 2.1 (information thankfully relayed to me by Joe Hodge). Everything else was worked out either by myself or Chuck Masters at Old Line between April 1995 and the current date.