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
furd@mit.edu