Installing Internet Support in OS/2 Warp: Difference between revisions

From OS2World.Com Wiki
Jump to navigation Jump to search
No edit summary
Line 260: Line 260:


==Adapting a REXX Login Script==
==Adapting a REXX Login Script==
Prior to the "PPP Update" it was necessary to use a REXX login script to handle most connections. With the simple scripts listed previously, REXX is now only needed to redial from a busy signal or to handle special cases. Most of the people who initially complained that they couldn't get Warp connected mentioned that they didn't know anything about REXX and didn't use it. Running OS/2 and not knowing REXX is something like living in Key West and not knowing how to swim. This is not the place to teach an entire language, but fortunately you don't need to know much about REXX to accomplish this task.
Click here for a quick introduction to the REXX language .
The ANNEX.CMD Script
IBM supplies a sample ANNEX.CMD script in the \TCPIP\BIN directory during installation of the Internet Connection. This section examines key lines from that script. The examples provided here will not provide any more function than can be accomplished with the standard login sequence scripting language.
/*----------*/
Anything in a REXX program between "/*" and "*/" is a comment. All REXX programs must begin with a comment. Its a rule.
After some standard modem initialization comes the key logic. It is reproduced below, with some comments removed:
call waitfor 'CyberGate&gt ' ; call flush_receive 'echo'
On the whole, this is lousy REXX and is not the example I would choose if the purpose of this exercise was to learn the language instead of connecting to the provider. However, this is what you get to start with and so we have to live with it as a starting point.
The particular communications controller that IBM chose to support starts by sending out a block of greeting junk followed by a command prompt of the form "CyberGate&gt ". It is fairly standard practice for the command prompt to end in "&gt ", but the "CyberGate" part is terribly specialized. The script responds with the command "SLIP" and a Carriage Return character (that the script has conveniently stored in the CR variable in an earlier section not reproduced here).
The script now waits for a prompt "Username:" and responds with the USERNAME variable (remember, this was extracted in the first PARSE statement shown above and was the second word in the argument list that you configured in the Login Script field of the first configuration panel.
The controller prompts for "Password:" and the script responds with the contents of the PASSWORD variable.
The controller now wants to respond with a line that includes something like:
Annex address is 130.132.57.20.  Your address is 130.132.57.27.
The script wants to capture the two addresses in this string. It waits for the "Your address is" part of the reply.
call waitfor 'Your address is' 
When that string has been received, then the first address is in the WAITFOR_BUFFER and the second address has not yet been processed. The first PARSE statement discards leading trash (the first period), the string "Annex address is" in the source gets matched, and the address is deposited into A ("130"), B ("132"), C ("57"), and D ("20"). The next line then recombines these numbers into a IP address string assigned to variable ANNEX_ADDRESS.
call waitfor crlf 
Remeber, the previous WAITFOR trigger in the middle of a line of output being sent by the Controller. This second WAITFOR reads the rest of the line (up to Carriage Return and Line Feed). This puts the second address into the WAITFOR_BUFFER. This second PARSE statement decodes it, and uses it to construct a variable OS2_ADDRESS.
===Building Your Own Script===
The first step to build a script is to use any terminal emulator, even the Terminal accessory in WINOS2, to connect to the communications controller and to run through the initial logon sequence. Capture this for further study. Consider the following example captured from the Cisco communications controller at Yale:
<pre>
CONNECT 14400/ECLC
***************************************************************************
Welcome to the Yale University Network
-Authorized access only-
-Connections may be logged-
Type:
? for help
&lt command&gt ? for help with a particular command
logout to logout
***************************************************************************
User Access Verification
Username: gilbert
Password:
Yale-Remote-01&gt SLIP
Entering SLIP mode.
Async interface address is unnumbered (Ethernet0)
Your IP address is 130.132.57.30. MTU is 1006 bytes
Header compression will match your system.
</PRE>
This sequence has the same elements as the ANNEX script, but with some important differences. For one, the Userid and Password must be entered first, before the SLIP command can be typed. The Cisco controller uses the "invisible" approach where it advertises no IP address for itself. The convention at Yale, however, is that the Gateway router will always have the last number in its IP address set to 1. Thus although the Cisco hasn't sent any explicit information about the gateway, if this remote PC has been assigned address 130.132.57.30, then the Gateway must have the first three numbers and end in 1 (130.132.57.1). With these changes, now we can rearrange the ANNEX script as follows:
call waitfor 'name:' ; call flush_receive 'echo'
annex_address = a||'.'||b||'.'||c||'.1'
A few of these changes are stylistic. For example, after examining a number of different communications controllers, one discovers that some end the prompt "Username:" and some end it "username:". Although REXX ignores case in variable names and keywords, it honors it inside a quoted text string. So after a while one learns that the best general approach is to trigger on the end of the word and match both the capitalized and uncapitalized prompt. The same idea drops the "Pass" in "Password:". Clearly we want to dump whatever gets put in front of the "&gt " in the command prompt.
The "MTU" phrase appears immediately after the IP address gets printed out, so we use it as a trigger to stop the WAITFOR. Then the address gets parsed out of the buffer. In this case, the IP address presented belongs to this remote machine (it is the OS2_ADDRESS) and in this case the Gateway IP address can be deduced by taking the same first three numbers as a prefix and ending with a "1".
Obviously calling this ANNEX.CMD and leaving the ANNEX_ADDRESS variable name is a bit confusing, since this script now has nothing at all to do with an ANNEX brand controller. However, cleaning things up involves more work that is necessary, so this script makes the fewest possible changes and just gets things working.
It is now possible to fall through to the rest of the IBM ANNEX.CMD script and it will do the right thing. It is, however, informative to examine what the "right thing" really is:
call flush_receive 'echo'
The FLUSH_RECEIVE lets the user see the output from the communications controller that is still in the buffer. The two SAY statements also show up on the screen and are useful diagnostic statements in the event that the processing gets completely fouled up. The last two statements execute two OS/2 commands that configure the TCP/IP protocol. In this example, they will expand to
ifconfig sl0 130.132.57.30 130.132.57.1 netmask 255.255.255.0
route add default 130.132.57.1 1
The IFCONFIG statement tells the TCP/IP support that the SLIP connection ("SL0") is a route to send messages to a machine with IP address 130.132.57.1 and that in this connection the address assigned to my PC is 130.132.57.30. The ROUTE statement says to send all messages for all other machines to the gateway at 130.132.57.1 (and therefore to send them all on the SLIP line). IFCONFIG.EXE and ROUTE.EXE were installed with the rest of the Internet Connection programs in \TCPIP\BIN. However, as was noted previously, many DOS/Windows packages also have programs with this name. Since \WINDOWS is often configured in the OS/2 PATH before the \TCPIP\BIN directory, it was important at the start (as explained in First Clean Your Windows) to remove programs with this name from the WINDOWS directory or these statements will try to execute the DOS versions of the utilities and will therefore fail.
Note that the original ANNEX script generated a ROUTE command for a visible controller that presented its own IP address. This script changes it to support an invisible controller. Therefore the ANNEX_ADDRESS variable is set to the address of the LAN gateway and the generated ROUTE statement reflects the result.


==Handling "Unknown Host" Problems==
==Handling "Unknown Host" Problems==

Revision as of 23:20, 25 May 2013

By Howard Gilbert

Connection to the Internet is one of the most important features of IBM's OS/2 3.0 Warp operating system. IBM has been refining its OS/2 Internet support for five years, and the current generation of programs show the sophistication and polish that comes from iterative refinement.

Warp will be a family of operating systems. The first version (lets call it Personal Warp) provides Internet support for dial-up modem connections using the SLIP or PPP protocols. Sometime in early 1995, IBM is expected to provide the LAN Client version of Warp with Ethernet and Token Ring drivers for connection to the Internet, to IBM LAN Servers and NT Servers, and to Novell Netware. For those who cannot wait, it is possible to install the OS/2 LAN Requestor diskettes from the current IBM LAN Server 4.0 product to get immediate LAN access. However, the Internet support provided with Warp is slightly advanced over the version supplied with the LAN Server package, so there is a small amount of effort involved to integrate the two.

Personal Warp includes all the subroutines and protocol support needed to run any TCP/IP application written for Windows or for a previous version of OS/2 over a phone line. Once the LAN drivers are added, Warp will provide full support to client or server applications. It ships with updated versions of the most important modern client programs. Additional applications and server programs are available in the full TCP/IP for OS/2 product group, but they will not be required by most users. OS/2 Warp Article Contents:

Prerequisites and Preparation

Realistic Prerequisites

The claim that either Warp or Chicago will run on a machine with only 4 megabytes of RAM is questionable. In both cases it is possible to load the basic operating system and run simple applications. However, additional memory is needed if Warp is to run Windows applications, multimedia, HPFS, or the Internet Connection package.

To get the full benefit from Warp, a machine should have 8 megabytes of memory. If you intend to simultaneously download files from the network, play music, and edit a large document with Word 6, then a 12 megabyte machine might be recommended. The same is true of Windows 95 (Chicago), so this is a statement about the direction of technology and not about any particular system.

First Clean Your Windows

A common problem that users have after installing Warp is some confusion trying to run WINSOCK applications. WINSOCK is a DLL routine, and the standard Windows processing, which Warp doesn't change, is to search for any DLL first in the \WINDOWS directory, then in the \WINDOWS\SYSTEM subdirectory, and then in the DOS path.

Now we encounter a fundamental difference between Microsoft and IBM. Microsoft, following the lead of Steve Jobs and the Macintosh, assumes that a PC must be a simple system that takes care of all the configuration details automatically. In concrete terms, Microsoft installs all its system support code into the WINDOWS and WINDOWS\SYSTEM directory and encourages all other vendors to do much the same. This works wonderfully well as long as there is only one copy of anything, or at least that two modules with the same name do the same thing and you only need the one with the latest date.

IBM, on the other hand, realizes that as the PC grows toward 16 megabytes of RAM and a Gigabyte of disk, real systems will never be all that simple. The OS/2 practice is to install each component it its own directory. Multimedia support goes in MMOS2, basic LAN support in IBMCOM, the file server client goes in IBMLAN, and Internet support goes in TCPIP. As each new component is added to the system, its directory is added to the PATH (to find EXE modules) and to the LIBPATH (to find DLL modules). This approach increases the complexity of simple systems, but it provides the control needed for more sophisticated configurations.

When Warp is installed, a vanilla installation will produce an OS/2 PATH (from CONFIG.SYS) that looks like:

D:\OS2;D:\OS2\SYSTEM;D:\OS2\INSTALL;D:\;D:\OS2\MDOS;D:\OS2\APPS;C:\WINDOWS ;D:\MMOS2;D:\VIEWER\BIN;D:\TCPIP\BIN;D:\TCPIP\UMAIL;

and a DOS PATH (from AUTOEXEC.BAT) that looks like:

PATH=D:\OS2;D:\OS2\MDOS;D:\;C:\WINDOWS;D:\TCPIP\DOS\BIN;

Of course, the disk letters may vary, but the important matter here is that C:\WINDOWS occurs first in both the OS/2 and DOS paths, and in any event, WINDOWS will always search its own directory first. Since the WINSOCK.DLL that OS/2 supplies, which is needed for Windows programs to run under OS/2, is installed in the \TCPIP\DOS\BIN directory, it will not be found if a Microsoft or other WINSOCK.DLL is installed in \WINDOWS. Worse, any commonly used TCP/IP utility installed in the Windows directory will be found before the corresponding OS/2 utility in \TCPIP\BIN.

Although this can be cleaned up later on, it may be a good practice to address the problem before installing Warp. Check the \WINDOWS directory for the following files:

WINSOCK.DLL, PING.EXE, ROUTE.EXE, IFCONFIG.EXE

If they are found, move them to a separate directory and add them to the Plain Old DOS PATH in AUTOEXEC.BAT. Reboot and verify that the old WINDOWS Internet programs still function correctly.

Installing Warp and the Bonus Pak

Installing Warp

This is not the place for a full discussion of the Warp installation process. IBM has done a lot of work so that Warp will install automatically on most mainstream computers. However, there are many obscure hardware vendors who sold equipment that just barely works on Plain Old DOS, and there are a number of new cards that appear initially with only Plain Old Windows drivers. The manual that comes with OS/2 is fairly comprehensive here and does not need to be restated.

The "Easy Install" process will install Warp on the C: drive and establish a Dual Boot configuration. DOS system files are moved to the C:\OS2\SYSTEM directory. The BOOT.COM program switches the DOS and OS/2 system files and selects which operating system boots. Before starting, make sure that there is enough space (~50 megs, plus 10 more for multimedia) on the C: drive to hold all the files.

The "Advanced Install" will install OS/2 on any disk letter, provided that it is possible to install the Boot Manager in its own one megabyte partition on the first hard disk. If there is no room for Boot Manager, it will probably be easier to move some files around and install on the C drive.

Warp will detect the presence of most Sound Blaster or Media Vision sound cards. During the installation of the Warp operating system, it will also install the multimedia drivers in the MMOS2 directory.

If Warp is installed on a typical DOS/Windows system, all of the disks will be formatted with the "FAT" file system. OS/2 has another file system, called "HPFS" that provides long file names and better performance on larger systems. However, HPFS requires a large amount of memory and is not a good choice on typical desktop configurations. A user with 8 megabytes of RAM who intends to run Warp with Internet or Multimedia support should use only FAT volumes and should remove or comment out the first line of CONFIG.SYS:

REM IFS=D:\OS2\HPFS.IFS /CACHE:64 /CRECL:4

This will free up memory and can make a big difference in performance.

Some clever options can also take up large amounts of memory. Although it may look nice to have a picture as the background of the display, an image has to be loaded into memory. At high resolution (1024x768) the image will occupy 768K of memory. Someone in a memory constrained environment should avoid "cute" options.

Installing the Bonus Pak

The Bonus Pak is distributed as either a directory on CDROM or a whole bunch of diskettes. There are many programs in the Pak, but the four that will be discussed here are the Multimedia Viewer, the Internet Connection for OS/2, Person to Person, and Works.

The Multimedia Viewer provides additional programs and file formats to extend the base multimedia support installed with Warp. The component of the operating system that provides the ability to play multimedia files is called MMPM and it is installed in the \MMOS2 directory. In OS/2 2.0 it was a separate program item. In OS/2 2.1 it was distributed with the OS/2 system but was installed separately. In Warp, MMPM is installed automatically when the system detects a sound card during the installation of the basic operating system.

The Multimedia Viewer include components of a previous product called Ultimedia Workplace. It was originally targeted to the developers of multimedia projects. However, the ability to more easily handle images and sound files now extends to the ordinary user community. In particular, Gopher and the Web Browser make it easy to transfer a photograph from the Smithsonian or an image of artwork at the Louvre. Multimedia Viewer is supposed to provide an easy way to organize these images.

The Bonus Pak program calls a utility named MINSTALL to install the Viewer software. MINSTALL is part of the MMPM support and is responsible for installing and updating all software related to multimedia support. For example, Multimedia Viewer includes support for the .AU sound file format commonly used on the Internet to store sound files. Although this support is packaged with Viewer, it actually goes into the MMOS2 directory and extends the capability of all the existing multimedia utilities and program interfaces. Other files are installed in the \VIEWER directory.

Multimedia files are too large to be comfortably fetched using a SLIP connection through an ordinary modem. It may be better to wait until the LAN Client version of Warp is distributed. The Multimedia Viewer is also appallingly buggy and may not be very useful until IBM releases the first set of fixes.

The Internet Connection for OS/2 is the package of Warp support for client access to Internet resources. It contains five general types of components:

  1. Client programs for commonly used Internet protocols: Gopher, Web Explorer, FTP, Telnet (terminal logon to mainframe and minicomputer hosts), and E-Mail.
  2. The DLL libraries to provide access to the TCP/IP protocol by application programs written for OS/2 or Windows.
  3. The low level drivers loaded by CONFIG.SYS to provide TCP/IP protocol support as an extension of the OS/2 operating system.
  4. SLIP support and the utilities to configure phone numbers and manage logon scripts.
  5. Higher level tools to establish an account with the IBM network service and update software through the network.

The Internet Connection package is obviously the most important part of the Bonus Pak, but its installation has no important options. The user is asked to select a target disk letter, then the files are copied into the \TCPIP directory and its subdirectories. The hard part will be the configuration that comes later.

Person to Person (P2P) isn't part of the standard set of Internet programs. It is an rather nice IBM package for workgroup communication that happens to work over the Internet. A group of users in different locations establish a network connection. P2P supplies a shared "whiteboard" on which they can exchange text, graphics, or other files. P2P does not provide voice communication, since this is easily arranged through a telephone conference call. It does allow the exchange of other forms of information.

Works is a grab-bag of simple applications: a word processor, spreadsheet, address book, and date book. These applications are integrated with the Workplace Shell, and WPS is always running. Several people have reported that performance on memory challenged machines was greatly improved by removing Works. Some have suggested that the system was more stable without these applications. At this point, the best advice appears to be to avoid installing Works if its functions are not needed.

Understanding Warp Configuration

OS/2 Internet software is installed under the \TCPIP directory. Programs and CMD files go in the \TCPIP\BIN directory, and configuration files go in the \TCPIP\ETC directory.

The name "etc" and the format of most of the files stored in this directory is a convention carried over from Unix. The information has to be stored somewhere, and Unix has established the standard for Internet software. During the early stages of development, Unix systems provided the router and gateway components from which the Internet was constructed. The legacy of those days are configuration files that are much more complicated than necessary. Today, most systems provide a simple front-end that allows the workstation user to enter a few important values that are used to populate all the configuration files.

Before Warp, all Internet software assumed a LAN connection. If a system used a modem instead, it was assumed that the modem connected to a device that provided a gateway to a corporate or campus LAN. The system was therefore configured with the machines, addresses, and services of the "home" network. Warp is the first Internet package specifically designed to be used by an ordinary consumer who has established a personal account with one or more network service providers. This presents an entirely new configuration problem.

Each network has its own set of addresses. Each has its own name server, news server, mail server, and so on. If a consumer has more than one account in more than one network provider, then the configuration of all these items has to change when the user dials a different phone number.

The applications are effected as well. Network News ties together the news servers of all organizations. When an item is posed to a news group, it eventually propagates to all news servers. However, each server maintains its own database and assigns each incoming item a local identifier. A program that displays news items keeps a record of the items that have already been seen, so that they will not be redisplayed the next time the program is run. However, the list of subscribed groups and viewed items uses identifiers that apply only to a specific news server. Switch to a different news server in a different network and the items have all been renumbered, so the list of previously viewed items becomes meaningless.

The News Reader V1.07 update (available through the Retrieve Software Updates panel previously discussed) now maintains a separate set of configuration and history files for every network to which the user may connect. This can be very useful in today's two income households. He can dial into his network to read his news, and she can dial her network to read her news.

Most of the time, configuration can be accomplished using the public front end. Occasionally it is useful to understand the lower level configuration files to debug problems or handle special cases. Four topics need to be considered

  1. A general understanding of SLIP/PPP and the ways in which it can be configured
  2. An examination of the SLIPPM utilities and connection scripts supplied with Warp
  3. A discussion of the layers of TCP/IP support in OS/2
  4. The structure of LAN support and its connection to higher level TCP/IP layers.

Different SLIP &amp PPP Configurations

SLIP and PPP

The Internet developed from research sponsored by the Department of Defense. To allow computers from many different vendors running many different operating systems, the Internet provides clear standards when individual machines connect to Ethernet or another LAN. Each corporate or campus LAN is then connected to the larger network over high-speed long distance phone lines. What may be surprising is that the phone connections have not been standardized.

Instead, if a company decides to connect to the Internet, it has traditionally contracted with a Regional network to provide the connection. The Regional network establishes a phone line to the company, and places a router box at the company location. The router connects to the company LAN, as do all the local computers. Since the Regional network buys all its router boxes from the same company, it really doesn't care how the routers communicate over the phone line. When two Regional networks need to connect, they each put a router box in the same room and run a LAN between them.

Internet routing has been dominated by devices produced by the Cisco company. Most companies, universities, and networks use Cisco devices as routers. Thus much of the long distance Internet communication uses whatever protocol Cisco decided to build into their hardware. This is not really a bad thing. The process of drafting any official standard takes years, while technology is constantly changing. Too often, by the time a standard is officially published it has already become obsolete. A private company is more agile and adapts more quickly.

When it became possible to run Unix on personal workstations, a need developed to connect remote systems to a central LAN over ordinary low cost modems and standard phone lines. A simple protocol was proposed called Serial Line/IP (SLIP). SLIP was never intended to be a "standard", just a temporary quick and dirty solution that was easy to code and would suffice until something better came along.

Unfortunately, when the Internet community decided to do something better, they defined the problem very broadly. First, they wanted a standard that would work on high speed long distance leased phone lines to replace the vendor proprietary protocols supplied by Cisco. A version of the same standard would then be used on inexpensive asynchronous serial modems used by Personal Computers. They also wanted a protocol that would support not only the TCP/IP protocol used by the Internet, but also Appletalk, DECNet, Novell IPX, and everything else.

The Point-to-Point Protocol (PPP) has been developing over a period of many years. Standards are drafted and discussed by a committee of the group that manages the Internet, but there is broad participation by computer, software, and network vendors. While SLIP only provides a method of exchanging data, PPP allows the two ends of the connection to negotiate or adjust buffer sizes, data compression options, addresses, and other housekeeping. PPP even provides for the automatic exchange of Userid and Password information.

To the Warp user, PPP may provide a slightly simpler method of connection. More of the configuration information is provided automatically. Less has to be configured or extracted during a logon script. If the central site supports all the options, the user may only have to configure the phone number and everything else can be handled automatically. This is the way that Microsoft uses PPP in Windows 95 (Chicago) and Windows NT.

However, IBM currently supports PPP only as an alternative to SLIP for Internet access. IBM doesn't have a PPP server, and it doesn't support the use of PPP with other LAN protocols (Communications Manager, LAN Server, or Novell Requestor). This eliminates most of the advantages that PPP would normally have. In Warp, the difference between SLIP and PPP is more a matter of taste than technology.

The TCP/IP protocol manages the Internet. As the name suggests, the Internet is a network of networks. If you configure SLIP or PPP "honestly", then each phone line is supposed to look like a link between your "network" at home and the network at the other end of the phone. Of course, most PC users don't want to configure and administer a "network" consisting of one machine.

So most implementations of SLIP or PPP are configured somewhat dishonestly. Each remote machine is given a set of parameters that make sense, but the central network "cheats" to make the overall configuration simpler.

Remote users dial into modems connected to a Communications Controller. The Controller is then connected to a LAN by an adapter card (represented by a red circle). Elsewhere on the LAN a Gateway Router connects this LAN to the rest of the corporation or campus and eventually to the Internet and the rest of the world.

Assume there are 32 dial in modems connected to the Controller. If you configure SLIP honestly, every SLIP line is a connection to a remote network. The Gateway would then have to be programmed to regard the Controller as a device that provides an interface to the 32 different remote networks. Each remote user has to configure one of these networks. The result is a mess.

There are two reasonable lies that the Controller can tell. The most outrageous lie is that it can claim all 32 remote users are actually connected directly to the LAN. The Gateway tries to send messages directly on the LAN to each of the 32 separate workstations, but the Controller catches all these messages and sends them out the phone line. In this situation, the Controller makes itself invisible to the Gateway.

In a more modest lie, the Controller can act as if all 32 remote users are on a single separate LAN and that it provides a path between this imaginary LAN and the real LAN. In this case the Controller is visible and must have an IP address. The Gateway sends messages for any of the 32 remote users to the Controller's one address for forwarding, and the remote users send messages to the Gateway over their individual phone connection. At first, this seems to be very close to reality. The underhanded part is that the Controller is probably using the same IP address on all the connections. An "honest" TCP/IP implementation would require the Controller to have a different IP address for the LAN and for each phone line. However, since nobody is really looking, the Controller can cheat and get away with it.

Suppose that the Gateway has address 130.132.57.1. Suppose that the first dial in modem line is associated with address 130.132.57.32, and the second with .33, and so on. For the rest of this example, "*" will replace the "130.132.57" part of the address.

If the controller is invisible, then the first SLIP line will be declared to be a connection between remote address *.33 and the Gateway at *.1. The SLIP user will send all messages to the Gateway. The Gateway will believe that these machines are on the LAN. The Controller will forward messages between the remote user and the Gateway transparently.

If the Controller chooses to be visible, then it will probably have the address *.31. The first SLIP/PPP line will be treated as a connection between *.31 and *.32. The second line will be a connection between *.31 and *.33. The LAN connects the Gateway at *.1 to the Controller at *.31. In this view, the Gateway sends all traffic for any of the remote users to the Controller at *.31 so that it can be forwarded. The remote users send all traffic for everyone to the Gateway at *.31 so it can be forwarded. The same *.31 address gets used over and over again, but since the Gateway and remote users have need for a global view of network architecture, the trick is never discovered.

If the user selects the PPP protocol, the Controller configures the remote user directly. SLIP, however, has no low level housekeeping messages. The remote computer initially connects to the Controller box as a terminal. The Controller writes the configuration information in messages send to the "terminal screen." The user supplies a script to provide Userid and Password and to extract address information.

If the Controller chooses to be visible, then during the initial connection it will send out a message of the form:

Your IP address is 130.132.57.34.  My IP address is 130.132.57.31.

The script anticipates this message and captures both address values. It plugs the *.34 address in as the value assigned to the remote PC, and the *.31 address is treated as a "gateway" value. If the controller chooses to be invisible, it will simply send out

Your IP address is 130.132.57.34.

The user will not be told about the *.1 gateway. The user has to know this address already. Generally, it will have been supplied by the central network administrator.

An invisible gateway would pose a minor routing problem if two remote SLIP users want to talk to each other. Since each believes that the Gateway is the route to all other machines, they would initially send it the message. However, from the Gateway point of view two machine on the same Ethernet should be able to talk directly to each other and do not need assistance. The Gateway then sends back a mild rebuke to each system to address traffic directly to each other. This is a minor issue, and in any event, remote SLIP users are not servers and are therefore unlikely to talk to each other directly.

Defining a "Provider"

For the PC to access the Internet over SLIP or PPP, it must first

  1. Initialize the COM port to the correct speed and settings (no parity, eight bits per character, hardware pacing).
  2. Initialize the modem to the correct settings
  3. Dial the phone number and wait for a connection

In a small number of cases, the communications controller will be configured to use only PPP protocol and to exchange Userid, Password, and configuration information automatically. In this case, nothing further is required. Otherwise, there are several possible sequences:

  • The communications controller may prompt for a Userid and Password, then present a command prompt to which the correct reply is "SLIP" or "PPP".
  • The communications controller may present a command prompt, and if the user enters "SLIP" or "PPP" then the controller may prompt for Userid and Password.

The PC may then have to scan the remaining messages from the controller to extract IP addresses.

In addition, the user may have to supply information provided by the network administrator, including a subnet mask and gateway address. It is also important to define a name server, news server, mail server, and other important service machines.

To supply this information in a way that allows several different people to dial the same network from the same machine, or to allow one person to dial any of several different networks, Warp supplies the "Dial Other Internet Providers" program (actually a module named SLIPPM.EXE).

The main panel of SLIPPM provides lots of useful information. In the middle there is provision for a list of "phonebook entries" for different networks. Two are listed here, Yale and Another. A new line is added by clicking the Add Entry icon and filling in information. Select and entry and click the phone icon to dial the phone. Messages during the initial connection appear in the scrollable box at the bottom. While connected, the window shows the elapsed time of the current connection, and the total time online since the counter was last reset. This allows a user to control cost when the network provider charges by connect time. There is even a nice little box to click when dialing out requires a "9" prefix from the current phone. Clicking the Add or Modify icons brings up a notebook of configuration settings for one of the providers.

The first page of the notebook provides the essential information for this provider. It is given a name "Yale", a phone number, and a Userid and Password is supplied. The user selects either the SLIP or PPP protocol. There is an inactivity timer that will hang up the phone if no data has been transferred for a number of minutes. This eliminates the threat of racking up connect time charges with a commercial Internet vendor if you are unexpectedly called away from your computer.

The Login Sequence in the middle is the most important and most complicated field in the configuration. Note that there is Help for the configuration, so if you have trouble filling out this field, hit F1 or the Help button for more details.

In a few cases, someone will dial a phone number which is dedicated to PPP access. Since most of the configuration can be handled automatically, it may not be necessary to use a Login Sequence.

In other cases, a user will dial a phone that is often busy. The user will want the system to wait a few minutes, then retry the number until it answers. To provide this level of support, one must supply a REXX program to control the line.

Most users will confront a Communications Controller that will prompt in some order for Userid, Password, and the SLIP or PPP command. It will then supply address information. The exact sequence varies from vendor to vendor. For example, some controllers ask for "Username", some for "Userid", and some use other words for the same thing.

The Login Sequence shown above provides an example of the most common sequence. The user supplies a set of lines that alternate between output expected from the Communications Control and input that should be supplied by the PC. Special variables are defined in as "[VARIABLE]". IBM provides one example for the ANNEX (visible) communications controller.

\r
sername:
[LOGINID]
ssword:
[PASSWORD]
annex:
slip
address\sis\s[$IPDEST]\sYour\saddress\sis\[$IPADDR]

The first line is sent from the PC to the Communications Controller after the modem has connected. The special value "\r" asks for the PC to send a Carriage Return. The Controller prompts for "Username" or "username". The script leaves off the first letter and therefore doesn't care if it is capitalized or not. The script now responds with the string configured in the "LOGIN ID" field in the configuration panel. The Controller then prompts for password and the PC supplies the value typed into the password field. The Controller then generates a command prompt ending in "annex:". The PC responds with the command "slip". The Controller types out a line of the form:

Annex address is 130.132.57.20.  Your address is 130.132.57.27.

The last line of the script matches this output. The special sequence "\s" matches one or more blanks. The first address "130.132.57.20" is stored as variable $IPDEST which becomes the address that the PC will use for the Gateway. The second address "130.132.57.27" is stored as $IPADDR and becomes the IP address that the PC will assign itself.

Now consider another script used to connect to a Cisco Controller:

[LOGINID]
word:
[PASSWORD]
&gt
SLIP
IP\saddress\sis\s[$IPADDR]

This particular system doesn't require a starting Carriage return from the remote user, but the IBM script requires the PC to speak first. The Cisco allows the user to typeahead, and will take whatever is sent in as the answer to the first question, so this script sends the userid initially in response to a question that has not yet been asked and then waits for the second prompt for "Password:". Note also that the Cisco controller is one of the "invisible" type and only sends out the address that the PC should adopt. The user needs to obtain information about the Gateway address from the network administrator and enter it in the supplied field of the next panel.

In either of these examples, the "SLIP" command can be replaced by "PPP" and the Connection Type button on the configuration panel can be switched to PPP. Once PPP is selected, the last line of the script is not needed, because PPP will obtain the address information at the protocol level. However, the line can be left in if the user expects to switch between SLIP and PPP frequently.

The second page of the configuration notebook allows the user to enter basic network information. These values would be supplied by the network administrator of the network into which you are dialing.

The field Your IP Address can be filled in when a user dials a dedicated phone number and is always assigned the same address each time a connection is made. The Destination IP Address is filled in with the address of the Gateway ("invisible" controller) or of the Communications Controller ("visible" controller). The Netmask indicates the part of the IP address that defines individual workstations and the part that defines the remote network. The MTU is the maximum size of data packets that can be exchanged over the link.

VJ Compression triggers a special algorithm that reduces the size of TCPIP packet headers dramatically. Most Communications Controllers support VJ compression, but they are often configured to remain passive. When they seen the PC sending a compressed header, then they respond by sending compressed headers back. If you know that VJ compression is possible, then it is best to force the issue by checking the box.

Domain Name Servers are used in most large organizations. They are configured with the name and IP address assigned to all of the local machines. They also provide access by local machines to the other name servers on the network. When a Web browser wants to connect to "pclt.cis.yale.edu" it will first send a message to the machine configured as the local name server. That machine uses the "yale.edu" part to contact the name server at yale to locate information on the PCLT server. It passes back an IP address that can be used to send a request to the PCLT server.

Fill in the field named "Your Host Name" with anything. Machines on the LAN have a name when they act as servers. Each dial-in line often is assigned an arbitrary name by the name server, which the dial-in user normally doesn't need to know. The field "Your Domain Name" provides a default suffix that is added to any Internet name that doesn't have any periods. As configured here, the OS/2 command "ftp fred" will be treated as a reference to "fred.cis.yale.edu".

The News Server name identifies a Network News Transfer Protocol (NNTP) server that will be used by the News Reader utility to fetch news. The name configured here works within the Yale environment but will not support requests from outside. Find your own news server.

The Gopher Server identifies a "Home" machine to which the Gopher client program will send its first query when it starts up. YALEINFO is the campus information and bulletin board system.

The WWW server field is not very helpful. To start a Web browser, one needs a URL. Configure the "home page" in Web Explorer after it starts up.

The Mail Server information is supposed to provide a starting configuration for the Ultimail Lite package. It identifies a Post Office Protocol (POP) server that receives mail on your behalf. When requested, Ultimail contacts this server to fetch any new mail. Mail sent by Ultimail or by the News Reader goes out through this server.

The mail configuration is rather complicated. In Ultimail itself there are six panels of parameters to establish a signature field at the end of each mail item, to annotate mail quoted during a reply, and handle other special features. Information provided here many not be successfully transferred. It is best to start Ultimail and check all the settings there directly.

In this example, the mail client contacts a machine named "minerva.cis.yale.edu". It supplies the userid "gilbert" and a password not shown. This would be the same userid and password that I would use to logon to that particular Unix host. Instead of logging on, the POP server uses the userid and password to retrieve any mail received by that host and to send it to my PC.

This is not, however, what appears to be happening in the Reply fields. The two reply fields suggest that return mail should be sent to "Howard.Gilbert@yale.edu". This is a convention adopted by the University to save reprinting business cards every time machines change. No matter how the network is configured, there will be a machine acting as "yale.edu". It will have no users or accounts. Its only function is to receive mail and forward it to another machine. In this particular case, mail arriving for "Howard.Gilbert@yale.edu" gets forwarded to "gilbert@minerva.cis.yale.edu".

The last panel selects a type of modem, a COM port, and modem speed. When the brand of modem is selected, the Initialization Strings in the last two fields are filled in. A speed of 38400 is probably a good choice on a computer with a decent (16550A) serial port. If the computer has an older inadequate chip, then 19200 is the highest recommended modem speed. SLIP or PPP will always run with 8 data bits and no parity.

There is also a section to disable the "call waiting" feature where the line generates a "beep" when someone dials into your phone when another call is active. The "beep" may or may not disconnect the data session. If you do not want to be disturbed, then this option may be used.

Adapting a REXX Login Script

Prior to the "PPP Update" it was necessary to use a REXX login script to handle most connections. With the simple scripts listed previously, REXX is now only needed to redial from a busy signal or to handle special cases. Most of the people who initially complained that they couldn't get Warp connected mentioned that they didn't know anything about REXX and didn't use it. Running OS/2 and not knowing REXX is something like living in Key West and not knowing how to swim. This is not the place to teach an entire language, but fortunately you don't need to know much about REXX to accomplish this task.

Click here for a quick introduction to the REXX language . The ANNEX.CMD Script

IBM supplies a sample ANNEX.CMD script in the \TCPIP\BIN directory during installation of the Internet Connection. This section examines key lines from that script. The examples provided here will not provide any more function than can be accomplished with the standard login sequence scripting language.

/*----------*/ 

Anything in a REXX program between "/*" and "*/" is a comment. All REXX programs must begin with a comment. Its a rule.

After some standard modem initialization comes the key logic. It is reproduced below, with some comments removed:

call waitfor 'CyberGate&gt ' ; call flush_receive 'echo' 

On the whole, this is lousy REXX and is not the example I would choose if the purpose of this exercise was to learn the language instead of connecting to the provider. However, this is what you get to start with and so we have to live with it as a starting point.

The particular communications controller that IBM chose to support starts by sending out a block of greeting junk followed by a command prompt of the form "CyberGate&gt ". It is fairly standard practice for the command prompt to end in "&gt ", but the "CyberGate" part is terribly specialized. The script responds with the command "SLIP" and a Carriage Return character (that the script has conveniently stored in the CR variable in an earlier section not reproduced here).

The script now waits for a prompt "Username:" and responds with the USERNAME variable (remember, this was extracted in the first PARSE statement shown above and was the second word in the argument list that you configured in the Login Script field of the first configuration panel.

The controller prompts for "Password:" and the script responds with the contents of the PASSWORD variable.

The controller now wants to respond with a line that includes something like:

Annex address is 130.132.57.20.  Your address is 130.132.57.27.

The script wants to capture the two addresses in this string. It waits for the "Your address is" part of the reply.

call waitfor 'Your address is'  

When that string has been received, then the first address is in the WAITFOR_BUFFER and the second address has not yet been processed. The first PARSE statement discards leading trash (the first period), the string "Annex address is" in the source gets matched, and the address is deposited into A ("130"), B ("132"), C ("57"), and D ("20"). The next line then recombines these numbers into a IP address string assigned to variable ANNEX_ADDRESS.

call waitfor crlf  

Remeber, the previous WAITFOR trigger in the middle of a line of output being sent by the Controller. This second WAITFOR reads the rest of the line (up to Carriage Return and Line Feed). This puts the second address into the WAITFOR_BUFFER. This second PARSE statement decodes it, and uses it to construct a variable OS2_ADDRESS.

Building Your Own Script

The first step to build a script is to use any terminal emulator, even the Terminal accessory in WINOS2, to connect to the communications controller and to run through the initial logon sequence. Capture this for further study. Consider the following example captured from the Cisco communications controller at Yale:

CONNECT 14400/ECLC
***************************************************************************
Welcome to the Yale University Network
-Authorized access only-
-Connections may be logged-
Type:
? for help
&lt command&gt ? for help with a particular command
logout to logout
***************************************************************************
User Access Verification
Username: gilbert
Password:
Yale-Remote-01&gt SLIP
Entering SLIP mode.
Async interface address is unnumbered (Ethernet0)
Your IP address is 130.132.57.30. MTU is 1006 bytes
Header compression will match your system.

This sequence has the same elements as the ANNEX script, but with some important differences. For one, the Userid and Password must be entered first, before the SLIP command can be typed. The Cisco controller uses the "invisible" approach where it advertises no IP address for itself. The convention at Yale, however, is that the Gateway router will always have the last number in its IP address set to 1. Thus although the Cisco hasn't sent any explicit information about the gateway, if this remote PC has been assigned address 130.132.57.30, then the Gateway must have the first three numbers and end in 1 (130.132.57.1). With these changes, now we can rearrange the ANNEX script as follows:

call waitfor 'name:' ; call flush_receive 'echo' 

annex_address = a||'.'||b||'.'||c||'.1'

A few of these changes are stylistic. For example, after examining a number of different communications controllers, one discovers that some end the prompt "Username:" and some end it "username:". Although REXX ignores case in variable names and keywords, it honors it inside a quoted text string. So after a while one learns that the best general approach is to trigger on the end of the word and match both the capitalized and uncapitalized prompt. The same idea drops the "Pass" in "Password:". Clearly we want to dump whatever gets put in front of the "&gt " in the command prompt.

The "MTU" phrase appears immediately after the IP address gets printed out, so we use it as a trigger to stop the WAITFOR. Then the address gets parsed out of the buffer. In this case, the IP address presented belongs to this remote machine (it is the OS2_ADDRESS) and in this case the Gateway IP address can be deduced by taking the same first three numbers as a prefix and ending with a "1".

Obviously calling this ANNEX.CMD and leaving the ANNEX_ADDRESS variable name is a bit confusing, since this script now has nothing at all to do with an ANNEX brand controller. However, cleaning things up involves more work that is necessary, so this script makes the fewest possible changes and just gets things working.

It is now possible to fall through to the rest of the IBM ANNEX.CMD script and it will do the right thing. It is, however, informative to examine what the "right thing" really is:

call flush_receive 'echo' 

The FLUSH_RECEIVE lets the user see the output from the communications controller that is still in the buffer. The two SAY statements also show up on the screen and are useful diagnostic statements in the event that the processing gets completely fouled up. The last two statements execute two OS/2 commands that configure the TCP/IP protocol. In this example, they will expand to

ifconfig sl0 130.132.57.30 130.132.57.1 netmask 255.255.255.0
route add default 130.132.57.1 1

The IFCONFIG statement tells the TCP/IP support that the SLIP connection ("SL0") is a route to send messages to a machine with IP address 130.132.57.1 and that in this connection the address assigned to my PC is 130.132.57.30. The ROUTE statement says to send all messages for all other machines to the gateway at 130.132.57.1 (and therefore to send them all on the SLIP line). IFCONFIG.EXE and ROUTE.EXE were installed with the rest of the Internet Connection programs in \TCPIP\BIN. However, as was noted previously, many DOS/Windows packages also have programs with this name. Since \WINDOWS is often configured in the OS/2 PATH before the \TCPIP\BIN directory, it was important at the start (as explained in First Clean Your Windows) to remove programs with this name from the WINDOWS directory or these statements will try to execute the DOS versions of the utilities and will therefore fail.

Note that the original ANNEX script generated a ROUTE command for a visible controller that presented its own IP address. This script changes it to support an invisible controller. Therefore the ANNEX_ADDRESS variable is set to the address of the LAN gateway and the generated ROUTE statement reflects the result.

Handling "Unknown Host" Problems

OS/2 TCP/IP Components

Internet LAN Access