|
Content © 1998, Frank R. Field, III (Original HERE, last update 13 Feb 1998).
Modified by Louis Ohland and Major Tom.
WARPPEER.PDF I have (poorly?) edited this page
into a ten page PDF. Much of the interlocution has been stripped out.
Table of Contents
- Purpose
- Nomenclature
- Getting It To Work
- Step One: Install File and Printer Sharing
- Step Two: Configure MPTS
- Step Three: Edit IBMLAN.INI
- Step Four: Now You Can Reboot
- Step Five: Identifying Your Peer Machines
- Getting The NT Machines To Behave
- Conclusion
- References
Purpose
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.
Nomenclature
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.
Getting It To Work
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:
References
- The IBM RedPieces Document (RedPiece): Windows NT
Systems Management, SG24-2107. (As the name suggests, this RedPiece - a
gestating RedBook - will walk you through the vagaries of administering NT;
something that is not obvious.) Ed. Salvaged!
- The IBM RedBook Online (RedBook): - EZ30NZ00
- OS/2 Warp Server vs Windows NT vs NetWare
(Chapter 3 is especially useful, describing the interrelationships between
NetBIOS over TCP/IP as implemented in Windows and Warp).
Ed. Link updated.
- John Summerfield's
Web Page
(Summerfield) - especially his
home LAN page.
(Here, John Summerfield describes setting up a LAN at home, working through
many of the details of setting up not only the network, but sharing modem
resources to get onto the Internet) Ed. MyLAN is
rescued, but the format is rough.
- Robert Thomas' Networking Web Page (RoknRob): Surviving
with OS/2 Warp in a sea of Windows. (Probably one of the single best
resources out there, describing not only what you have to do on your Warp
machine, but also how to configure the NT machines.)
Ed. Mostly rescued!
- What is SMB, NETBIOS, etc.. (If you ever wonder why
all these different operating systems work together on the network, knowing
that Microsoft would certainly prefer to do things its own proprietary and
incompatible way, you should look at this description of Server Message Blocks
- SMBs.) Ed. Rescued!
- An article on using Samba
servers with OS/2 Warp. (Samba servers are daemons that enable Unix machines to
interpret SMBs, and thus internetwork with PCs. These instructions look very
similar to those of Robert Thomas', but offer some additional insights.)
- Tim Sipples "Dear Timmy" column on this at
the Warp Server Resource. (Yet another
description of what has to be done - in a How-To column.)
- Tim Sipples' followup "Dear Timmy" columns on 32BitsOnline. (Tim Sipples is a
columnist for the 32BitsOnline e-zine, and he answers questions offered up over
the Internet.)
(The IBM Redbooks home page is
http://www.redbooks.ibm.com/) Ed. Updated.
Other useful sources are:
Barry Nance; Introduction to Networking; Fourth Edition; Que
Corporation; Indianapolis, IN; © 1997 (ISBN: 0-7897-1158-3; Library of
Congress: 96-72212)
(I found this to be a particularly useful resource, describing the inner
workings of and relationships between Warp's networking services and those of
Windows NT, Windows95, and Windows 3.1 - lots of practical information about
these systems, as well as Banyan Vines, Novell Netware and Unix
environments) Neil Stokes, et al.; Getting to Know OS/2 Warp 4; First
Edition; Prentice-Hall, Inc.; Upper Saddle River, NJ; © 1996, IBM; (ISBN
0-13-842147-1)
(A good place to go for a basic description of file and
printer sharing services, but it's not a book that is going to get you over
major hurdles with peer networking). Mark A. Miller; Troubleshooting TCP/IP: Analyzing the Protocols of
the Internet; Second Edition; M & T Books, a division of MIS: Press, a
subsidiary of Henry Holt & Company; New York, NY; © 1996 (ISBN
1-55851-450-3)
(An incredibly detailed description of the inner workings of TCP/IP.)
Step One: Install File and Printer Sharing
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
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
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
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
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
There are three rules that the NT machines you wish to peer with must
follow:
-
NT machines have an RFCNAMES.LST file, too. Of course, its name is
different. RFCNAMES.LST on an NT machine is LMHOSTS (see
this).
You also may want to register your machine name with the NT machine by adding
its hostname and IP address to the HOSTS file (a sort of belt and suspenders
approach to name resolution). LMHOSTS serves the same purpose as RFCNAMES.LST -
it tells the NT machine where to find your NetBIOS-named machine when you
aren't on the same subnet.
Note: Searching for LMHOSTS and HOSTS files on a
NT machine may be difficult. You may not be able to find those specific files;
if not, you will find files called LMHOSTS.SAM and/or HOSTS.SAM (with the SAM
being short for "sample.") The files have enough comments in them so you should
be able to set them up correctly. But, you will have to save them without the
.SAM file extension.
-
NT machines on the same subnet as you will also be invisible to your GUI
resource browsing tools. There is a default registry setting - lmannounce -
that has to be changed from the NT default of 0 to 1. Then, the NT machines
will be visible to you. See RoknRob's WWW page for the
nitty gritty, because each Windows variant has a different way to get the
Windows machine to respond consistently with the NetBIOS LAN communication
defaults.
There are lots of reasons why MIT will probably never setup WINS (Windows
Internet Name Servers) for the entire campus (see
this and
this),
but your local net may have one. If so, there are some additional settings that
you may wish to get from RoknRob's excellent source.
-
NT resources must have NetBIOS names that are less than 9 characters in
length. In this incarnation of Warp, longer names will confuse the graphical
networking tools and you won't be able to use them to connect to resources. The
command line NET command will do the best it can, and you can employ NET USE to
connect to resources with legal names, but NET VIEW will not necessarily be
able to list everything - you'll get the extremely useless error message - More
Data Available - but you won't get to see it.
Finally, NT permission setting is, without a doubt, the most confusing thing
I've tried to deal with yet - and, as I'm sure you'll agree with me up to this
point, LOTS of this is confusing. If you're working with someone who
understands it, let them take care of it for you. If not, the IBM Redpiece on
NT Administration is of some use, but I have some real gaps in my
understanding.
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!
Conclusion
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
|