home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Power-Programmierung
/
CD1.mdf
/
lan
/
driver6s
/
novtcp.txt
< prev
next >
Wrap
Text File
|
1990-03-27
|
14KB
|
295 lines
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