I wanted to be able to access files on an NT 4 Workstation system
(now ubiquitous with the infiltration of SAP here at MIT) from my Warp 4 system.
The documentation that comes with Warp 4 said that I could do this, using the
peer-to-peer networking services. When, as a networking novice, I decided to get
something for my $5.00/month network fee and MIT's prodigious overhead rates by
asking for some assistance, the MIT network HelpDesk couldn't have been less
helpful if they'd tried. So, I figured it out by myself, using a combination of
published and WWW resources.
As a Senior Research Associate, the time it took me to develop
this information was was pretty expensive, so I thought I'd try to make the
expense a little more justifiable by publishing what I learned on the web. I
can't guarantee that what I did will work for everyone, but I believe that, at
minimum, it will give you hope that it can be done and will give
you a few pointers on taking care of it yourself.
In OS/2 Warp, peer to peer networking goes by the name of
"File and Printer Sharing," a good, normative description of what it does --
allow users on a network to share files and use each other's hardware (like
printers and modems) without a central server and the associated administrative
& maintenance requirements. This capability was added to Warp 3 and it was
then repackaged as Warp Connect; peer services come with all versions of Warp
4.
For a variety of reasons, it's probably worth installing File and
Print Services when you install the operating system; there are problems adding
it after the initial OS installation, at least in Warp 4. I have seen newsgroup
messages that suggest that the File and Print Sharing installation routines have
bugs that can keep the installation from taking place, apparently caused by long
lines in the CONFIG.SYS file -- and we all know how long a LIBPATH statement can
get over time! All I know is that there are difficulties that I'm still trying
to resolve on a friend's machine just getting his peer services installed.
Warp 4 achieves peer to peer through the use of NetBIOS, a
protocol for networking developed jointly between IBM and Sytek, Inc. (now known
as Hughes LAN Systems, Inc., Mountain View, CA). The basic NetBIOS is a local
area networking protocol (see RFC 1001
and RFC 1002); it is not "routable," meaning that its use across (rather
than within) local networks is difficult. MIT networking services will tell you
(or, at least, they told me) that NT uses Windows networking, and anything that
does NetBIOS is not supported -- and there was a strong implication that such
systems were passé.
This response was particularly troubling to me, since IBM
describes Warp as the universal client. As a networking novice, I was in no
position to refute IBM or the MIT Helpdesk. It took me a couple of days to find
out that network operating system designers, recognizing this limitation of
NetBIOS long ago, developed what is known as NetBIOS over TCP/IP, meaning
that they decided to use a routable protocol (TCP/IP) as the underpinnings for a
application programming interface that looked just like NetBIOS (in the jargon
of the OSI network standard, NetBIOS operates at the Session Layer, while TCP is
used at the Transport Layer).
Oh, and by the way, NetBIOS over TCP/IP basically became the
default networking protocol used by Windows NT. Thus, the MIT Helpdesk was
technically correct -- Windows NT doesn't use NetBIOS for networking on the
MITNet -- TCP/IP serves that function, while TCPBEUI provides a NetBIOS-like
programming interface to the network - the so-called transport-layer protocol.
Of course, this hair splitting response is the kind of non-help that computer
support desks are famous throughout the world for -- and, IMHO, the real reason
that centralized computer systems will never return until helpdesks actually
start helping instead of merely parading their superior knowledge. (I think of
the joke about the helicopter lost in the Pacific Northwest).
The whole purpose of peer-to-peer networking is to share
resources on different computers connected to the network. The concept of
resources is a little vague, but basically a resource is a file, a file
directory, or a device (like a printer) on one machine that a user on another
machine wants to be able to access. Depending upon the file system, that access
can be defined many ways, but the primary ones are (1) read only; (2) read and
change (i.e, existing files can be written, but new files cannot be created); or
(3) read, change, and write (i.e., new files can be created). There are other
kinds of access, but these are really only of interest to network
administrators.
Resources are made available by NetBIOS name, and names are
defined according to a fairly easy standard: two backslashes, then the name of
the machine on the network, then a backslash, and finally the name of the
resource itself. For example \\FURDBOX\FILEDIR is the way NetBIOS wants to hear
you name the resource FILEDIR on the computer known as FURDBOX on the network.
Note that FURDBOX is not the name of your machine in the mit.edu domain; it can
be, but there is no requirement that it match. Similarly, FILEDIR need not be
the name of any file or file directory on the FURDBOX machine.
However, there seems to be one key limitation -- NT seems
to be able to give resources names that are more than 8 characters in length.
Warp's NetBIOS is able to signal that such resources exist, but it cannot handle
names of more than 8 characters in length. The operating system gives you the
relatively useless message "More data available" when you connect to machine
with a longer name. It may be that you can connect to such resources (I don't
know - I haven't tried). What I can say is that any machine that has a resource
with such a lengthy name will confuse the Warp network services enough that the
GUI tools in the WPS will not work correctly for any of the resources available.
Thus, if it is at all possible, you should ask those with whom you are sharing
resources to try to limit the names that they assign (printer names seem to be
the most egregious sources of this problem). I would like to think that this
limitation will be overcome eventually (maybe it already has), but I have found
it to be a problem as of Warp 4, Fixpak 5.
OK, you got this far, so you must really want to get this to
work.
A word of advance warning: I learned a lot of this from some web
sites, and I took those writers' word for a lot of things, so I can't promise to
be able explain why I made certain "incantations." Check out the sites yourself,
and maybe you'll understand them better than I. The main sites that I will refer
to are:
(The IBM Redbooks home page is
http://www.almaden.ibm.com/redbooks/)
Other useful sources are:
Step One: Install File and Printer
Sharing. (top)
Don't get ahead of yourself -- you will see some dialogs in the
course of getting it installed that will look just like those in later steps;
ignore them. Just get the darn thing installed. If you are successful, you will
find, following the reboot, that the Desktop Connections object will include a
new folder that is labeled Network. There may also be some new things on the
screen during boot -- the key thing will be the addition of a line in your
config.sys file that installs a new file system - NETWKSTA.200.
There are fixpacks for peer services. The most current as of
February 1998 is ip08406,
but you can always go to
IBM (or the
Cincinnati Team OS/2 www site) to get the latest word.
Step Two: Configure MPTS (top)
The default transport installed for File and Printer Sharing is
NetBIOS. We need to add another; NetBIOS over TCP/IP. To do this, open the
System Setup folder in your OS/2 System object on the desktop. In that folder,
run the MPTS configuration program - double click on the Adapters and Protocol
Services icon:
You'll get the following dialog box - click on the Configure
button:
Doing so will get you this dialog:
Select the "LAN adapters and protocols" radio button and click on
the Configure button, getting you to the Adapter and Protocol Configuration
dialog:
When you first see this dialog, there will only be two Protocols
listed in the bottom window: IBM TCP/IP and IBM OS/2 NETBIOS. They will both be
listed with a leading "0 -" as the IBM TCP/IP is shown above. This leading
number is the logical adapter number. The fact that a single physical adapter
can be treated as multiple logical adapters is the reason for the "M" in MPTS.
It is necessary because you can't have two approaches to NetBIOS on the same
logical adapter; thus, you must use the "Change number" button after adding the
IBM NetBIOS over TCP/IP protocol to the Current Configuration list.
According to the documentation, you shouldn't actually need to
have the IBM OS/2 NetBIOS in the current configuration if you are not going to
access devices on your local net. However, I found that I needed both protocols
in the configuration -- although that may have been a consequence of other
glitches that were eventually resolved. Unless you're trying to support 1000
connections (and you're running Warp Server), there's little lost by putting
both in your configuration.
The configuration program won't let you close this dialog box
until the two NetBIOS protocols are assigned to different logical adapters, so
you can't get out of here without changing one of them. According to the
documentation, it doesn't matter which is assigned to adapter 1 or 0; this is my
configuration.
Once you have made these changes, you can select the OK, Close,
and Exit buttons, respectively, to back out.
NOTE: The install/configuration program will tell you to reboot at
this point - DO NOT REBOOT. There are a couple more steps to be taken before you
reboot.
Step Three: Edit IBMLAN.INI (top)
The MPTS Configure program should do this, but doesn't. Open the
file \IBMCOM\PROTOCOL.INI, which can be found on your OS/2 boot drive. You
should look for the ADAPTERn records (i.e., ADAPTER1= , ADAPTER2 =):
The key thing is to verify which adapter is associated with plain
NetBIOS (ADAPTER1 = netbeui$) and which is associated with NetBIOS over TCP/IP
(ADAPTER0 = tcpbeui$). These values should correspond with your choices made in
the MPTS configuration program, but it pays to check.
What you need this for is the editing of the \IBMLAN\IBMLAN.INI
file, again on your OS/2 boot drive. For whatever reason, the MTPS configuration
program will NOT update this file correctly.
When you open the IBMLAN.INI file, look at the beginning of the
file for records like:
net1=NETBEUI$,0,LM10,100,150,14
The odds are VERY good that you will only find only one of these
records. But you must have two lines and one must refer to TCPBEUI$ and the
other must refer to NETBEUI$, and the number immediately following must
correspond with the logical adapter numbers selected in the MPTS configuration
program (i.e., the net1= record must correspond with logical adapter 0, the
net2= record must correspond with logical adapter 2, etc.). It's easy to add the
second record; copy the existing record, and change the NETBEUI (or TCPBEUI) to
the other, and get the adapter and net numbers right. Don't worry about the rest
of the numbers in the record; just make sure you copy them exactly.
Next, search for a "wrknets =" record. You should find a record
like "wrknets = NET1." You should change it so that it reads "wrknets =
NET1,NET2" (like the following image). Again, don't worry about the other
records; you just want to make sure to add the NET2 to the wrknets= record:
Finally, you need to search also for "srvnets =" -- and you'll do
exactly the same thing: make sure that the "srvnets =" record refers to both
NET1 and NET2 (i.e., srvnets = NET1,NET2).
Save this file.
Step Four: Now You Can Reboot (top)
You should get some startup messages describing the installation
of TCPBEUI. If you get an error saying that the "NETWKSTA.200" is not a device
driver, then you need to start this all over again. Keep slogging and make sure
that you got all the NETn and protocol adapter numbers right. Eventually, you
should get it all to boot correctly. And, when you do, you'll be able to get
started on setting up your Peer work.
Step Five: Identifying Your Peer
Machines (top)
Now that you have a NetBIOS over TCP/IP setup, how to get your
machine to talk to machines not on your local network. Basically, you have to
tell your machine how to map an 8-character NetBIOS name to an Internet machine
name. This is accomplished with two files stored in your \IBMCOM directory:
RFCNAMES.LST and RFCBCST.LST. They can be edited via the MPTS configuration
program (see step two) or they can be edited from any text editor.
Editing via MPTS requires you to restart the MPTS configuration
utility and get back to the Adapter and Protocol Configuration dialog. Select
the NetBIOS over TCP/IP protocol in the bottom window and click on the Edit
button.
Clicking on Edit yields a choice of editing Driver parameters,
Names list, and Broadcast list:
Selecting the Names List radio button and clicking on Configure
yields a listbox:
Note that the Add... button in this image is greyed out - this is
a known bug in many incarnations of the MPTS configuration program. You will
always be able to add at least one NetBios name/hostname pair to this list;
however, if your version of MPTS greys out the Add... button after adding the
first name, you will have to edit the RFCNAMES.LST file by hand. The default
protocol setup for NetBIOS over TCP/IP allows you to specify up to four names.
If you can't get those names input via MPTS setup, any text editor can be used
(see below).
Basically, this is where you tell your machine the IP address of
the NetBIOS machine names that you want to access. This figure shows all the
addresses as host names, but you can equally well use IP addresses like
18.178.0.30. The limit of four is defined in the protocol setup. If you really
need more, then it's time to agitate for a NetBIOS nameserver. You may be able
to use a WINS server, but I don't know anyone yet who has. (See RoknRob's web site for more
information on WINS configuration.)
You also need to configure the Broadcast List. When you select
that radio button and then click on Configure, you get:
The NetBIOS protocol, as a non-routable protocol, only knows how
to achieve certain tasks by basically sending a message to every machine it can
find (broadcasting). As you might imagine, this is something of a problem for
big networks, hence the need for nameservers. You need to put the same machines
in this list that you put in the names list. Again, either hostnames or IP
addresses are acceptable.
After you exit from this program, you may be told to reboot. That
isn't necessary if all you've done is modify these two lists. Just go to the
\IBMCOM directory and run RFCADDR from the command line: this registers the
lists with the currently running peer daemon, so you're all set.
You can also edit RFCNAMES.LST and RFCBCST.LST with any text
editor. The file format is straightforward: RFCNAMES.LST is composed of records
that pair a NetBIOS name, inside of double quotes, with an IP hostname, and
RFCBCST is just a list of hostnames:
The only tricks are (a) to make sure that the NetBIOS names in the
RFCNAMES.LST file are inside of double quotes; (b) put a space (or several)
between the NetBIOS name and the hostname/IP address; and (c) make sure that
every hostname/IP address that appears in the RFCNAMES.LST file also appears in
the RFCBCST.LST file. You can edit these files at any time, but any changes you
make will not be recognized by the peer daemon processes until you run RFCADDR
after saving these files.
Done! Your machine is now peered to the MITNet. If you want to
drive someone crazy, you can even use the Network Messaging tool to send
messages to those machines whose names you have registered - and they'll be
unable to get back to you if they're on an NT machine. To get those NT machines
to recognize you, you'll have to get the users on the other end to make some
changes to their machines.
Getting The NT Machines To
Behave (top)
There are three rules that the NT machines you wish to peer with
must follow:
On one hand, if the resource is something that you don't want to
protect, it's pretty straightforward to give EVERYONE on the net access to the
resource. Great, but not particularly attractive if you're trying to share work
files. But giving password restricted access to a peer resource is not trivial.
And the reason for that seems to be that every NT machine that you want to share
with must have a local user registered on each NT machine that has the same
USERID and PASSWORD; and that must match the USERID and PASSWORD that you use to
log onto the network! This seems too insane to be true, but it's the only way
that I've been able to set up password-restricted access to peer resources. If
there's an easier (and more secure!) way to do this, I'd love to hear from
someone who knows!
Now you know as much as I do about this. I hope that I can improve
this document over time, and I encourage anyone out there who follows these
instructions and finds them deficient will feel free to point out the errors
and/or limitations of this document. Please feel free to e-mail me.
And Good Luck!!!
Frank R. Field, III
Director, Materials Systems
Laboratory
Massachusetts Institute of Technology
mailto:%20furd@mit.edu