OS/2 e-Zine! - How to share an Internet connection for little or no cost

How to share an Internet
connection for little or no cost

- by Ethan Hall Beyer

A basic guide to setting up a SOCKS server under OS/2

In these modern and connected times, a certain issue seems to become a problem more and more often. Many people in the same house or apartment own a computer, and they all want to use the Internet at the same time. The days of cheap, dedicated high speed Internet connections is yet to come, so often the only solution in these cases is to jockey the use of a single modem phone connection. So Internet users in this precarious situation need to figure out how they can all simultaneously Get On The Net. Thankfully, it's not that difficult to do if the computers are already networked in a small home LAN.

Even if the systems aren't networked, some surfers might find the initial investment required to link their computers together well worth it. In this brief tutorial I'll explore how you can set up an computer that is running OS/2 and connected to the Internet, so that other systems connected to the OS/2 machine through a private network, can also access the Internet. And as always, minimal cost for this venture is of interest as well.

The OS/2 server software that allows this "sharing" was made available a few months ago and is now quite mature (despite some bugs, which I am pursuing with the author). This software is a "SOCKS server", and the machines on the private network that need to talk to the Internet, are "SOCKS clients". In a nutshell, here's how it works:

On the clients, the TCP/IP programs know which addresses designate sites on the real Internet, and which ones indicate machines only on the private network. For requests that go to the Internet, the client machine instead sends the request to the SOCKS server which then talks to the real Internet machine, and makes sure that the response it receives is forwarded to the correct client machine. This is done for any type of command that must go to a system on the Internet.

For more technical information on SOCKS, explore the NEC SOCKS site. There is a lot of information here, and setup information for other non-OS/2 systems.

In summary, here are the steps needed to set up a working SOCKS network over an existing LAN:

1. Download, install and configure the SOCKS server (SOCKD.)

2. Download, install and configure the NAME SERVER for the SOCKS server (BIND, DNS Kit, or DNSPROXY.)

3. Test the SOCKS server from a client machine.

4. Configure the computers on the network to talk to the SOCKS server.

5. Automate the startup procedures for the SOCKS server.

So, to get many machines all using a single Internet connection, what do you need to do? First, the computers that will be sharing the connection must be networked together with TCP/IP. This guide isn't a tutorial in setting up a LAN, as there are excellent How-To's on this topic available on the 'net.

Assuming the private network is functioning properly, the required software can now be set up.

Setting up the Socks Server

The OS/2 machine that will be running the server requires two key software options:

1. The actual SOCKS server, properly configured.

2. A Domain Name Server (DNS). For the SOCKS server for OS/2 to function, it requires that a DNS also be running.

Setting up the actual SOCKS server is quite simple. First, obtain the distribution file and unzip it into a separate directory. Though the server can be customized extensively, only a single basic setting is required. This can be set interactively within the server itself once it's running, but I prefer to edit the text configuration files directly.

In your ETC directory, create the file SOCKD.CFG with the single line

permit aa.aa.aa.aa bb.bb.bb.bb 0.0.0.0 0.0.0.0 ge 0

where "aa.aa.aa.aa" is your private network address and "bb.bb.bb.bb" is your private network address mask (netmask). For example, see the settings I use.

This file specifies which systems can "talk" through the SOCKS server. In more complicated setups, you could restrict which machines can go to the Internet, and even to which sites on the Internet. Explore the server's help files for more information on these settings.

Once this file is saved, start the server by running SOCKD.EXE. There is no install program, so you might want to create a program object for it.

At this point there still isn't any local DNS running, so the server cannot yet be used.

Setting up the Domain Name Server (DNS)

Having a DNS on the private network is nice. It allows the computers on the network to refer to other systems by name instead of by TCP/IP address, which makes things a lot easier. That aside, the SOCKS server (called SOCKD, or Socket Daemon) for OS/2 requires one, so for our purposes, you will have to set it up.

Surprisingly, it is configuring the name server that is the most complicated part of this whole procedure. There are three main options, and I'll cover how each one is set up.

1. IBM DNS Kit for TCP/IP for OS/2

2. Berkeley Internet Name Daemon (BIND) 4.9.4 OS/2 port

3. DNSPROXY for OS/2

1. IBM DNS kit for TCP/IP for OS/2.

This is the commercial name server software available from IBM for OS/2, released a few years ago. Quite expensive. Actually, very expensive, considering the next option (#2.). It requires a complicated set of configuration files, and is difficult to set up at first. DNS Kit is a complete server, as is BIND, so features such as caching and local name definition may offset the difficult setup. But since a true server does more, running it in the background requires more system time.

Look here for a information on setting up a basic DNS Kit configuration.

2. BIND 4.9.4 for OS/2.

Berkeley Internet Name Daemon for OS/2 is an EMX port of a UNIX name server, for OS/2. Since all name servers essentially share the same origin, BIND is very much like DNS Kit -- except it's free. Otherwise, BIND and DNS Kit can share the same configuration files, though BIND requires that these files have names only possible on HPFS drives (due to its true UNIX origins; if anyone does have BIND running on a FAT system, please let me know). Also, BIND seems to require more overhead than does DNS Kit. But still, to choose between DNS Kit and BIND, I recommend the latter, for cost reasons only.

Look here for a information on setting up a basic BIND for OS/2 configuration.

3. DNSPROXY for OS/2.

This is part of a commercial suite of proxy servers for OS/2, though DNSPROXY may be available separately. It is a very low overhead DNS server by proxy, and requires no setup. It only forwards requests, and is not designed to add local host definitions. As such, all local name resolution for machines on the private network, must be done via a HOSTS file. Contact the author to purchase this product, at http://www2.dhInternet.com/sophisto/.

When the DNS is up and running, you should be able to start of the SOCKS server. First, connect to the Internet with OS/2 machine running the server. Then, start up the name server and, finally, update the your configuration "RESOLV" files so that you actually use the local DNS instead of the one appointed by the ISP. Obviously, this tedious procedure should be automated, and I will discuss this at the end of the article.

To test that the server is functioning correctly without further work (you don't need to test this but, if there are problems, it might save some troubleshooting,) you can use WebExplorer or Netscape on one of the machines on the private network to test the server. Configure the browser to Enable a SOCKS server, and enter the IP number of the OS/2 system running the SOCKS server you just set up. If all is well, and the server is connected to the Internet, you should be able to access and view Internet pages from the machine on the private network.

Setting up the Socks Clients

Once the SOCKS server is set up, all the machines on the private network that need the ability to talk to the Internet, must be configured to use the server. One of the nice things about TCP/IP and its standards, is that any operating system adhering to those standards can talk to all TCP/IP servers, regardless of what hardware or software those servers are running. So in this case, in which the server happens to be running OS/2, there is no limitation on what the client system is running, as long as that client machine can be "SOCKSified", or configured to use a SOCKS server.

There are four key bits of information needed to SOCKSify any system. Though the actual configuration terms used may vary from system to system, what each system refers to should be clear.

1. SOCKS Domain: This it the domain name chosen for the private network.

2. SOCKS Name Server: Since the OS/2 machine running SOCKD is also running a DNS, this is the numeric IP/machine number of the OS/2 server running the SOCKS program and dialed out to the Internet. pr

3. SOCKS Server: This is identical to the SOCKS Name Server (remember, both DNS and SOCKD are operating together on the OS/2 machine.)

4. Direct Routes: This is a list of network addresses and netmasks that are accessible on the private network, and don't need to be directed to the SOCKS server. In a simple private LAN, this is the private network address and netmask.

OS/2-based client systems.

The primary focus is here, since this is what most people are running (I hope). The newest version of OS/2, Warp 4, comes with SOCKS server support built directly into the system, and it need only be enabled by entering the appropriate configuration information. Under Warp Connect, SOCKS support must be downloaded and installed separately, then configured.

NOTE: Make sure you do NOT enable "SOCKS support" in the TCPCFG configuration notebook on the OS/2 machine running the server, unless you know specifically that server machine must communicate through a DIFFERENT socks server, to talk to the Internet. If this is the case, enter the configuration information for that other server, and not circular references to the SOCKS server it is running itself.

Warp 4

Under Warp 4, all SOCKS client configuration can be done via the TCPCFG network configuration notebook. Open it, and switch to the "Socks" tab. Here are the values you should enter:

   Page 1/3
                              [X]  Enable SOCKS
              SOCKS Userid:   (leave blank)
              SOCKS Domain:   (Enter the SOCKS domain name as determined above.)
          SOCKS Nameserver:   (Enter the SOCKS name server as determined above.)

   Page 2/3
   Configure DIRECT Routes.

   Choose "Add", with these values:
    Destination IP Address:   (Direct route IP as determined above.)
                      MASK:   (Direct route mask as determined above)

   and put in the Destination IP Address and Mask for the direct routes
   as indicated above.  For simple networks there should only be one
   entry.

   Page 3/3
   Configure Default SOCKS Servers

   Choose "Add", with these values:
              SOCKS Server:  (The SOCKS Server as determined above.)
    Destination IP Address:  0.0.0.0
                      Mask:  0.0.0.0

Alternatively (and this is how I prefer doing it), the text SOCKS setup files can be edited or created directly by hand. In the client machine's ETC directory, there are two of these configuration files. Enter the values indicated, without parentheses (see the sample configuration files for an example.)

File SOCKS.ENV:

   SOCKS_FLAG      on
   SOCKS_DOMAIN    (SOCKS Domain)
   SOCKS_NS        (SOCKS Name server)
   SOCKS_SERVER    
   SOCKS_USER      

File SOCKS.CFG:

   direct (private network address) (private network mask)
   sockd @=(SOCKS server) 0.0.0.0 0.0.0.0

Warp 3

To SOCKSify a Warp 3 box, first download the "beta" SOCKS code for Warp Connect. Download it to the \TCPIP directory, uncompress it using the "unzip" utility, and then run UPDINST from within that directory. As with the latest version of Warp, the configuration can then be done from the TCPCFG configuration notebook, but for Warp 3 this is the only option, as the information isn't stored in text-files.

Automating it all

By now, all the basic ingredients to getting a working SOCKS server sharing an Internet connection, are in place. However, to make the system smooth and worry-free, everything should be automated.

The SOCKS server determines how it forwards requests to the Internet by looking at what TCP/IP connections are active when it starts. Unless you're one of the lucky ones who has a fixed dialup IP number, the server should be restarted after each connection so the new connection values are used. SOCKS can be configured to start the connection automatically when a request for an Internet site is received but, in my experience, there are some slight glitches when this is enabled. (I'm pursuing these with the SOCKD author.)

In addition, connections to the Internet usually imply that whatever Internet dialer is used, updates the server machine configuration files to point to the DNS server operated by the Internet provider. But the SOCKS server is running its own DNS, and should make use of it. So, as well as restarting the SOCKS server after each connection, the DNS configuration files on the SOCKS server must be reset to "point" to the DNS it is running itself. These files are the RESOLV and RESOLV2 files in the ETC directory. They should be identical, and of the form

   domain (domain name)
        nameserver (server IP address)

The "server IP address" can also be the loopback address, if the loopback (127.0.0.1, usually) is defined on the server. Consult the online TCP/IP help for information on this.

In order to automate these tasks, they should be run immediately after a successful connection is established. Some dialers (such as In-Joy or the IBM Advantis dialer) or dial scripts (such as PPPDial) allow you to specify commands to be executed upon connection. If one of these programs is used, it can be configured to perform the required tasks by calling a CMD batch file that performs the required operations. If this CMD file cannot be run automatically, it can be placed in a program object and started manually when needed, after connection. Refer to dialer documentation for information on setting up the "autostart" options.

A sample "autostart" script (STARTSOK.CMD) is provided, though different ones can certainly be used.

Warm Socks

Once everything is set up properly, a SOCKSified private network is a joy to use, and well worth the time it takes to set it up initially. However, this type of setup is not ideal for all situations. There are alternative methods to sharing dialup connections, such as IP Masquerading, and serving by proxy. I haven't experimented with either.

There are also limitations to the SOCKS technology that prevent specific Internet applications from functioning. Notable examples are the PING command, and DCC transfers in IRC programs (though otherwise IRC works fine through a SOCKS server). Finally, this whole guide assumes a true LAN, and not one based on direct serial connections. Expanding this setup to include machines directly connected to the SOCKS server via serial cable (much cheaper than Ethernet or Token Ring) may be a topic in an upcoming issue.

By now, hopefully everything is set up and working properly. Feel free to e-mail me if there are questions, and I will answer as time permits. Many thanks to David Head for providing a "test case" in addition to my own private network.

Ethan A. Hall-Beyer is a second year Applied Math/Computer Science major at the University of Waterloo.

[Our Sponsor: EmTec Innovative Software - OS/2 ISDN, modem and telnet software.]

This page is maintained by Falcon Networking. We welcome your suggestions.