Coexistence of Warp & NT Machines on the MITNet
©1998, Frank R. Field, III
Ed. Original version is HERE. I have altered the page to 600 pixels wide, renamed some images with the convention of LAPS*, changed the page title from "BODY" to the title at the top so search engines might find it faster. Otherwise, the page and it's contents are unchanged. The author, Frank R. Field, III, maintains all copyrights to this derivative and the original version. At this time, 6 Nov 06, some links may not be functional. As time permits they will be fixed.
have (poorly?) edited this page into a ten page PDF Much of the interlocution
has been stripped out.
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.
Getting It To Work (top)
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:
Other useful sources are:
(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)
(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).
(An incredibly detailed description of the inner workings of TCP/IP.)
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.
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:
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 220.127.116.11. 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:
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.
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.
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