CONCURRENT NOVELL NETWARE AND TCP/IP USAGE: A CASE STUDY Wesleyan University is an active networking site, heavily using Bitnet, NSFnet, and local area Ethernets. Recently we started implementing local PC and Macintosh networks using Novell Netware. Since TCP/IP is our universal protocol, we wanted all PCs on the Novell network to have full concurrent access to Telnet and FTP. We did not want special hardware or TCP gateways, did not want commercial TCP/IP software, and did not want to spend much money. We did want all the PCs on these networks to boot up automatically via Boot ROMs in the Ethernet cards. Getting this all to work together was an amazingly complex task, requiring weeks of work, many pieces of public domain software, and help from many generous people. As we were gathering information, several people requested that we pass on the information we received if we could make it work. This document is written to make it easier for others to follow the same path we did, and also serves as documentation to record our sources of software for when we forget it all next week. In the steps which follow, most of the minor frustrating details of obtaining and translating software are left out. In general, having a unix machine around is very useful, because you may need the programs UUDECODE, UNCOMPRESS and TAR to unravel the file archives you obtain. In addition, having TAR and ARC on a IBM-compatible PC is important. The hosts mentioned as sources for software are merely the places where we picked things up. There are usually other alternative sources available. If someone reading this (and trying to follow the same steps) gets blocked because of the lack of a critical piece of software, send me mail and I'll try to help. We can make anything necessary available through anonymous FTP on Internet or through file or mail servers on Bitnet. The story begins! 1. We obtained copies of Novell Netware version 2.15, advanced and sft versions. 2. We subscribed to the Novell special interest group bulletin board, NOVELL@SUVM.BITNET. (This has proven absolutely essential! Many thanks to the generous and hardworking people who make this list possible.) 3. We formulated our goals and started asking for help. This is a very current topic, and we quickly encountered a long message on July 19th giving very complete instructions on obtaining and using a "packet driver" (as opposed to a specific LAN hardware driver) which would allow LAN hardware to be shared by different programs. Who: Kelly McDonald at Brigham Young University Email: kelly@dcsprod.byu.edu Host: sun.soe.clarkson.edu via anonymous ftp File: /pub/novell/novell.exe.uu The READ.ME file in this uuencoded, self-unpacking archive file gives instructions for creating a Netware shell for a client machine which would use the packet driver interface, thus allowing a properly configured TCP/IP based program to share access to the network hardware. This archive file provided the Netware-specific part of the software. 4. Next we picked up the packet driver code from Clarkson University, as instructed by the BYU documentation. This distribution contains packet drivers for a number of Ethernet network boards, including the WD8003E board that we favor. The distribution also includes some documentation on what packet drivers do and why you need them, so I won't go into that here. Host: sun.soe.clarkson.edu via anonymous ftp File: /pub/ka9q/drivers.arc 5. Having settled the Netware end, we now needed a Telnet and FTP which had a packet driver interface. We use and recommend NCSA Telnet, but their standard 2.2 version did not support a packet driver interface. (Their 2.3 version does -- it's in beta test as of 10/12/89) We obtained NCSA Telnet 2.2TN, which is NCSA version 2.2 with many enhancements from Clarkson University. In addition to packet driver support (the critical part) it also supports TN3270 accsss (unimportant to us) and IP address assignment via BOOTP protocol (very useful to us!) Who: Brad Clements at Clarkson EMail: bkc@omnigate.clarkson.edu Host: Omnigate.clarkson.edu File: /pub/ncsa2.2tn/ncsabin.tar.Z You can also pick up PDTAR.EXE there for a MS-DOS TAR program, and ncsasrc.tar.Z for the complete telnet sources. 6. We created Netware shells for our client machines using the packet driver interface. This requires that you load the packet driver before running IPX. In our case we used the program WD8003E.COM for the Western Digital Ethernet cards we use. There are similar names for many other card-specific drivers. There is a catch! The packet drivers talk the Ethernet version 2 protocol, which is slightly different from the IEEE 802.3 protocol that Novell uses on Ethernet. So you need to use a program called ECONFIG to modify the Ethernet drivers on your Novell servers in order to tell them to talk Ethernet V2. protocols to their clients rather than the standard 802.3. This is an either-or decision -- if you choose the packet driver interface for some clients, you must use it for *all* clients of a server unless you install two Ethernet interfaces. (But this isn't the last word -- more later.) 7. All was well, temporarily... we would run WD8003E in the login batch files of the client machines, then we could run IPX and NET4 to talk to the server just fine. We could also use NCSA/Clarkson Telnet successfully and concurrently, simply telling it to use "PACKET" as the Ethernet device type. However, after the first flush of victory faded we had other problems. Of course our boot proms no longer worked, because they use the same IEEE 802.3 protocols that we'd previously mentioned and we had ECONFIG'd the server so that it no longer understood that dialect. We diverted a lot of attention to using two cards in the server, one ECONFIG'd and one vanilla. Well, that kind of worked, but left us with a messy situation -- you could either boot up automatically via the ROM (using standard Novell drivers) and stick to Novell software only, OR you could boot up with a floppy disk (using packet drivers) and then have Telnet and FTP available. Yuck. 8. So we asked for help again, and got swarms of responses. Several people had experimented with modifications to the packet driver code to change it to convert between 802.3 and Ethernet V.2 packet types -- very important, because your clients can then remain within the standard Novell world and your servers need not be ECONFIG'd. Furthermore, the boot ROMs can (almost) work. But not quite. Stripped of the technical details, it turns out that there is a difficulty negotiating the transfer of control of the Ethernet card from the ROM to the packet driver. There were different approaches to this problem. The one we chose was courtesy of: Who: Andries Ruiter at the University of Groningan Email: Ruiter@HGRRUG5.Bitnet Andries provided a modified packet driver (with source) for the Western Digital board which had two important enhancements: - Ethernet V.2 and 802.3 conversions - Postponement of the control handoff mentioned above (between the ROM and the packet driver) until the first Novell IPX packet is sent, which comes after NET4 is started. 9. We were almost there, but not quite. We still had problems with the ROM to PD handoff. We could not complete the AUTOEXEC.BAT process within the remote reset file without aborting the login with some spurious "illegal switch" message during the NET4 process. (For those vague on the remote reset files, they're simply a network-loaded version of a Novell boot floppy. Stripped of frills, our AUTOEXEC.BAT file simply contained:) WD8003E 0X60 0X4 0X280 0XD000 IPX NET4 F: LOGIN GUEST However, the ROM-loaded version would not complete no matter what I tried. So I broke it into two pieces, with manually-chained batch files requiring user interaction. 10. Then we read about ROMREL, a program which was designed to address the ROM to PD handoff problem. Basically, ROMREL simply releases the special BIOS hooks created by boot ROMS, and supposedly works for all cards. It certainly works for WD cards. A boot ROM works by creating a funny psuedo disk "A" which contains the contents of the network-loaded floppy. So disk A is a memory disk until you run NET4, when it goes back to being a floppy. ROMREL is used in conjunction with a real RAMdisk which will stick around. You use it by creating a RAMdisk in your CONFIG.SYS file, then having the AUTOEXEC.BAT file load all important files from the psuedo-A drive into the new RAMdrive. Then you tranfer to that drive, run ROMREL to get rid of the special BIOS hooks, and proceed swiftly and easily to complete the entire network login process with no errors. Who: Glen Marianko EMail: glen@aecom.yu.edu Host: Purdue University BBS at 317/494-0807 File: ROMREL.COM and .DOC in Novell file area 11. One remaining problem. The Groningan modifications had postponed the initialization of the packet driver until after the first IPX packet had been processed. Unfortunately, what this meant was that IPX was required to "turn on" the network -- running Telnet would not work until after IPX had been run. This wasn't a problem with the boot ROM machines, which all run IPX on startup, but it was a restriction for the staff hard disk machines which frequently didn't use the Novell server on a daily basis. We addressed this one by modifying the Groningan packet driver source to remove the second of Andrie's modifications. Actually, their version was a notch or two behind the standard packet driver source so we just borrowed their Ethernet v.2 <=> 802.3 conversion code and moved it into the current Clarkson packet driver source. The only module affected is the actual device-specific driver code (ie not the generic HEAD.ASM or TAIL.ASM files) and thus I only did it for the WD8003. Who: Doug Bigelow at Wesleyan University EMail:DBigelow@Eagle.Wesleyan.EDU 12. Finally, everything works. Booting from the boot ROMS is quick and smooth, and all users can separately or simultaneously run IPX and Telnet regardless of the startup order. It was a long hard road! FUTURE PROBLEMS: Western Digital has released a new version of it's WD8003E card which is smaller and is software configured using non-volatile memory. No more jumpers to fiddle with. It's a nice card, but the driver has changed in some subtle way. The packet driver can still control the cards just fine, thank goodness. However, others can't. NCSA Telnet, for example, will crash the machine when told the device type is WD8003. This works fine with the old model Ethernet cards, and works with the new type if you use the PACKET device type. But the old driver with the new card crashes and burns. Similarly, we have observed an odd problem with the standard Western Digital boot ROMs for Novell Netware. The new style cards boot with the ROMS, but *v.e.r.y s.l.o.w.l.y* -- like two minutes instead of 15 seconds? This happens while the remote reset file is being downloaded to the machine, ie before any software driver gets loaded. So far we've been able to use only the old cards in our public ROM-booting machines, but we've now run out -- so we hope someone figures this one out quickly. APPENDIX -- REMOTE RESET FILES These are the batch files that we use for our network booting. First, the device drivers loaded via CONFIG.SYS: BREAK=ON BUFFERS=20 FILES=40 SHELL=COMMAND.COM /P /E:960 DEVICE=ANSI.SYS DEVICE=RAMDRIVE.SYS 120 /E We use the DOS 4.X standard RAMDRIVE program to load up a 120 KB drive. It assigns the drive to the first vacant letter, hence it will be drive C: in a two-floppy machine, or drive D: in a hard-disk machine. This covers the options for us on our networked machines. Others might have to use a more exhaustive test than the one below in AUTOEXEC.BAT, which figures out which drive is the RAMdisk. @echo off set configtel=x:config.tel prompt $p$g egasave 30 > nul dosedit > nul set rdisk=c: if exist c:\autoexec.bat set rdisk=d: copy *.com %rdisk% > nul copy go.bat %rdisk% > nul set comspec=%rdisk%command.com %rdisk% cls go Finally, we're on the RAMdisk and we proceed to release the ROM hooks then activate the network via the GO.BAT batch job: @echo off romrel 3 > nul wd8003e 0x60 0x3 0x280 0xd000 > nul pdipx > nul net4 > nul f: echo $[2J$[7m You are now logged in as user GUEST.$[0m login guest