Notes on Setting up Ethernet and Routing
----------------------------------------

It is much simpler than you think. It only looks complicated because IBM has
created scripts that run the basic programs, and other scripts to run those.
Then IBM has setup SLIPPM to make it even more complicated.

Let's cut through all the complexity and discuss the rock bottom level where
only a few programs are needed. All the complexity IBM created is just a way
of running three basic programs: IFCONFIG, ROUTE and ARP.

			      IFCONFIG
			      --------

IFCONFIG.EXE  sets up an "interface" to the internet. An "interface" can be a
slip interface, which means a com port and modem. Slip interfaces have names
like sl0, sl1, sl2,...

An interface can also be a networking card, such as an Ethernet card. These
interfaces have names like lan0, lan1, lan2,...

Finally, there is the "loopback" interface, which doesn't connect to anything.
It is a mirror. Everything that goes out bounces right back. It allows the
machine to talk to itself. The loopback interface is called lo.

What do we need to do when we configure an interface? As an analogy,
interfaces are like the COM1 and LPT1 ports on your PC. Configuring an
interface with IFCONFIG is like setting the COM port parameters with a MODE
command. However, no serial parameters are involved. The configuration
really only has to specify the IP address. That is analogous to being able
to specify the phone number that is connected to COM1.

To configure an interface, you just run IFCONFIG followed by the name of the
interface, the IP address of the interface, and any other required parameters.

For example, to configure the loopback interface with IP address 127.0.0.1
the command is:

ifconfig lo 127.0.0.1

Configuring the SLIP interface sl0 is done like this:

ifconfig sl0 199.99.99.99  199.99.99.88 netmask 255.255.255.0

Two IP addresses are given. They are the addresses at each end of the
slip line. The command above configures the sl0 interface with IP address
199.99.99.99 such that the other end of the serial connection is another
SLIP interface whose IP address is 199.99.99.88. The machine at the other
end may also have an Ethernet card. It has a different IP address than its sl0
interface. The "netmask" specifies that the sl0 interface is on a network
where all the IP addresses start with 199.99.99 and only the last pair of
digits change from machine to machine.

To configure an Ethernet card, with the IP address 199.99.99.77 the
command is

ifconfig lan0 199.99.99.77 netmask 255.255.255.0.

Testing if IFCONFIG worked
--------------------------

If you have a working interface, you can ping it. If your machine isn't
connected to anything, the only working interface will be the loopback
interface. Let's say you've given it the IP address 127.0.0.1. Then do this:

ping 127.0.0.1

If the IFCONFIG command that configured the loopback interface worked, you'll
get a series of echos coming back from the ping command.

If your slip interface goes from 199.99.99.99 (your machine) to 199.99.99.88
the remote machine, you won't be able to ping 199.99.99.99 unless you
are connected by SLIP. Ping will report that there is no route. This may
be puzzling because 199.99.99.99 is actually on your machine. It makes sense
if you think of it like this. The sl0 interface is an interface to your phone
line. Anything send to this interface will cause the lights on you modem to
flicker. If your modem isn't connected, then 199.99.99.99 isn't working
either.

Associating names with IP addresses
-----------------------------------

People typically use the name "localhost" instead of 127.0.0.1 for the
loopback interface. Try this:

ping localhost

It won't work unless you have a file called HOSTS in \TCPIP\ETC which
associates the IP address 127.0.0.1 with the name "localhost". Setting up
a HOSTS file is important. Just make a file called HOSTS and put in it
the following line:

127.0.0.1   localhost

Now "ping localhost" should work.

Suppose you are setting up a connection between two machine called "home" and
"work". Lets say the IP addreses are 199.99.99.99 and 199.99.99.88
respectively. Then, it would be a good idea to associate the machine names and
the IP addresses by putting these lines in the hosts file:

199.99.99.99 home
199.99.99.88 work


How TCP/IP finds machines: the RESOLV file and the DNS
------------------------------------------------------

Lets say you do this:

ping somebody

The networking software has to locate a machine called "somebody". First it
will look in your HOSTS file. If you haven't associated it with an IP
address, it will try to find out by asking another machine.

The machine it asks is called the DNS (Domain Name Server). It is really
just "Directory Assistance".

Lets say you set up an interface sl0 as 199.99.99.99 and give it the name
"home". Other machines will only be able to find you if the Directory
Assistance (DNS) has a listing which says "home" is 199.99.99.99.

It's a little more complicated. The name "home" is the name on your subnetwork.
The subnetwork is the part of the IP address that matches the 0's in the
netmask. Since the netmask is 255.255.255.0, only the last number 99 in the
IP address is associated with "home".

The part of the IP address that matches the 255's in the netmask is 199.99.99.
This part is called the "subnet". Your subnet also needs a name. How does it
get one?

The subnet name is the first line in a file called RESOLV that should exist
in \TCPIP\ETC. If you want to call your subnet "my.private.net", then
the RESOLV file has one line that looks like this:

domain my.private.net

The actual name of your machine is the combination of the name "home" and
the subnet name.  That is, your machine is "home.my.private.net".

There is a command called HOSTNAME.EXE that tells you the name of the
machine you are using.

If you've configured the loopback interface and associated the name 'localhost'
with 127.0.0.1 in the hosts file, then the HOSTNAME command will respond with
"localhost".

If you set up a slip interface and set up the routing (as explained below)
then the HOSTNAME command will return your machine name "home" combined with
the name of your subnet "my.private.net". That is, it gives
"home.my.private.net".

You can give your machine any name you want, and put any subnet name you want
in your RESOLV file, but if you want anyone else to find you, you'll have to
use the names that Directory Assistance (the DNS) has in its listings.

The DNS
-------

A DNS is a machine that you can contact to convert names into IP addresses.
You've got to know the IP address of the DNS. If you only had its name, you'd
have to find it first and ask it the IP address of its name in order to find
it. A Catch-22. So your machine has to have the IP addresses of a DNS, and
(better yet) several DNS machines. These are also put in the resolv file. My
resolv file is:

domain chem.ualberta.ca
nameserver 129.128.5.233
nameserver 129.128.76.233
nameserver 129.128.4.241


Let's say you've configured the slip interface and have a working slip
connection between your machine and the Internet. Ping will then work with the
IP address of your sl0 interface. Try using ping with the IP address to
confirm its working.

If you've put a name for your machine in your HOSTS file. Ping will work with
the name of your PC's sl0 interface. Try using ping with a name to make sure
your hosts file is set up correctly.

At this point, your work and home machines have found each other and are
talking.

The next problem is: how can you talk to other machines? In other words, you
are at home and you're connected to your machine at work via its sl0
interface. You want to ping another machine at work called "otherwork". Let's
say you try this:

ping otherwork.my.private.net

The firt thing that happens when you give this command is that your home
machine tries to determine the IP address of "otherwork.my.private.net". If
it finds this IP in your HOSTS file, it will go on to the next step. If it
doesn't find it in the HOSTS file, it will try to contact the DNS to ask it.
Since we haven't get got things working, it won't be able to get the name from
the DNS, so to get any farther, we have to put the IP in the hosts file. Add
the following line to HOSTS:

199.99.99.55 otherwork.my.private.net

Now your ping command works exactly the same as if you had typed:

ping 199.99.99.55

Will this work? Well, not quite. There are actually two problems.

Problem 1. Lets say your TCP/IP software has lo and sl0 interfaces. Out which
interface should it send the ping in order to reach 199.99.99.55? That
problem is solved by setting up a "default route". The default will be to
send all packets for machines whose location is uncertain to the machine
at the other end of the slip connection.

This is done with ROUTE.EXE as follows:

route add default 199.99.99.88 1

The only IP addresses your machine really knows about are the ones you've
specified in the IFCONFIG commands. Those are 127.0.0.1, the loopback
interface, and the two IP addresses that make up the SLIP connection, which
are 199.99.99.99 and 199.99.99.88. Packets for these IP addreses can be
handled by your PC. All other packets are sent out the default route. That is,
they are sent to your work machine.

TCP/IP networking works on the principle that packets are passed from machine
to machine until they eventually reach their destination. TCP/IP automatically
forwards packets to IP addresses it knows how to reach. If a machine doesn't
know how to reach an IP address, it passes the packet along its default route.

Your "ping 199.99.99.55" command is therefore passed to your work machine,
which (presumably) is working properly and can pass the packet to
199.99.99.55.

Let's look at how "work" sends the packet to "otherwork". An understanding of
this is very important. "Work" and "otherwork" are both on the same Ethernet.
They can find this out by comparing their IP addresses and the netmask. Since
the netmask is 255.255.255.0, all IP addresses with the first three numbers in
common are on this subnet. Since "work" has IP 199.99.99.88 and "otherwork"
has IP 199.99.99.55, the first three numbers are 199.99.99 for both. Hence,
they are on the same subnet.

If the packet were intended for a destination outside the subnet, "work" would
send the packet to its default route, which is a router that forwards the
packet to the rest of the Internet. But because the packet is for a machine
inside the subnet, the packet has to be handled by the machines inside that
subnet. This means that "work" and "otherwork" have to transmit the packet
between them without any outside help.

Machines on Ethernet always communicate using MAC addresses. A MAC address is
a number such as 00:00:00:0c:11:22:33:44 that is built permanently into every
Ethernet card. This number assigned at the factory. Every Ethernet card ever
manufactured has a unique MAC address.

To send the packet to "otherwork", "work" needs to know its MAC address. It
broadcasts a request on the Ethernet which says "Who has IP address
199.99.99.55?". "Otherwork" responds and broadcasts its MAC address, which
"work" hears and remembers. Then "work" puts this MAC address on the front of
the ping packet and broadcasts it on the Ethernet. "Otherwork" sees a packet
with its MAC address and says "that's for me". That's how it gets the ping
packet. "Otherwork" ignores all packets on the Ethernet except packets
addressed to it.

I had to explain that because this method doesn't work when "otherwork"
tries to respond to the ping packet. "Otherwork" follows the same steps I
just outlined when "work" talks to "otherwork". First it looks at the
IP addresses of itself and "home". It determines that "home" is on the
same subnet, so "otherwork" knows that it must pass the packet directly to
"home" itself using MAC addresses, instead of sending the packet over the
default route to the rest of the Internet.

"Otherwork" needs to get the MAC address of "home" so it sends out a broadcast
asking "Who has IP address 199.99.99" and waits for a responce. These
broadcasts are not echoed over the slip connection between "work" and "home"
If such broadcasts were echoed, your modem would be so busy that data
communication would be slow. Hence, the broadcast doesn't reach the home
machine. Since no machine responds, "Otherwork" cannot obtain a MAC address to
use and must give up trying to return the ping packet.

The solution to this problem is the most complicated thing I had to do to
get this package working. Here is the solution.

"Otherwork" has to send the ping packet to "work" so that "work" can forward
it over the slip line to "home". To make this happend, when "otherwork"
broadcasts a message asking "Who has IP 199.99.99.99", the machine "work" has
to respond and give its MAC address.

This is called "proxy arp". The term means that the machine "work" is acting
as a proxy for your home machine. The command to set this up is the following.
This command has to be executed on "work":

arp -s 199.99.99.99 00:00:00:c0:11:22:33:44  pub

Arp stands for "Address Resolution Protocol". This is how TCP/IP "resolves"
which MAC address matches a given IP address. The "pub" at the end means
"publish". It makes "work" respond with its own MAC address
00:00:00:c0:11:22:33:44 whenever it hears a broadcast message asking for the
MAC address of the machine with IP address 199.99.99.99.

That's it. Once the arp command has been given on the "work" PC, the ping
packets from "otherwork" will be sent to "work", which will relay them
over the slip line to "home".


The Larger Picture. Why You Mustn't use a Private Network
---------------------------------------------------------

A little knowledge is a dangerous thing. Now you have a little knowledge. It's
my responsibilty to caution you about what would happen if you start messing
around with IP addresses that aren't assigned to you.

The fundamental rule for SLIP is this. The IP address for sl0 for your home PC
must be on the same subnet as the sl0 you are connecting to. That is, both
ends of the slip line must be on the same subnet.

In principle, the office PC could have different subnets for SLIP and Ethernet.
That makes it compilicated but it can work. To make it work, the following
problem has to be solved.

How could packets from elsewhere in the Internet find your home PC? That
would only be possible if the existence of the subnet on your slip connection
were known, so that packets would be routed there. Getting that net known
is complicated and won't be convered here.

The only easy way to set up your SLIP link is to have the sl0 and lan0
interfaces of your work machine on the same subnet. That way all packets for
your home machine will be sent to the subnet of your work machine. Then your
work machine will be able to pass those packets to your home machine.

Since both ends of the slip line have to be on the same subnet, the
SLIPHW package requires that you have TWO additional IP addresses on the
same subnet as your work machine. One of these is for the sl0 interface of
that machine. The other is for your home machine.

Since other machines will know your home machine by name, the DNS has to know
the name and IP of your home machine. The other IP you use (for the sl0
interface of the work machine) doesn't need a name. No machine will ever send
a packet there directly. All the packets for the work machine can be sent to
the Ethernet interface of "work".

Hence, the second sl0 IP address of your work machine doesn't have to be
registered with the DNS. However, it is very important that no other machine
on your subnet is using that IP address. Ask your network administrator if
there are any IP addresses he hasn't assigned and have him give you one to
use.


Connecting a Private Network
----------------------------

Let's say you set up a home Ethernet and you install the SLIPHW software
on one machine to provide a link to the Internet. There are two possible
situations.

(1) Your home Ethernet is on the same subnet as "work".

(2) Your home Ethernet is a different subnetwork.

In case (1) you can probably get your entire home network working, but not in
case (2). Let's see what goes wrong with case (2).

Suppose your home net is 199.11.11 and the Ethernet card on "home" is IP
address 199.11.11.11. This card must have a different name than "home" because
"home" is the slip interface 199.99.99.99. Lets call the interface with the
Ethernet card "etherhome". Suppose you have a machine "otherhome" with IP
address 199.11.11.22.

Here's how to set it your home network so that it works as long as you
aren't connected to the rest of the Internet by SLIP:

On both home machines put HOSTS files like this:

199.11.11.11 etherhome
199.11.11.22 otherhome

On each machine, make the default route the other machine. On "etherhome"
the route command is

route add default 199.11.11.22 1

On "otherhome" use

route add default 199.11.11.11 1

Now the two machines can talk to each other and all packets are sent to the
other machine by default. No DNS is defined because none is reachable, (but
none is needed). You can give your home net a subnet name with a RESOLV file
like this:

domain my.private.net

Now lets look at what happens when the SLIPHW package is used to connect
"home" to the Internet via the work machine.

When the connection is made, the default route is changed to the work
machine:

route add default 199.99.99.88 1

That won't affect the ability of the two home machines to continue talking to
each other. They know about each other anyway, and the default route is only
used for packets that are destined to unknown machines.

The "home" machine should work OK on the Internet. When you run Web Explorer
on this machine and use a URL outside your home network, TCP/IP will use
the default route out its sl0 interface to machines on the Internet.

The problem occurs when "otherhome" tries to operate on the Internet.

Lets suppose "otherhome" tries to ping "otherwork". Lets assume that the
IP of "otherwork" has been put in the HOSTS file so that "otherhome" knows
the IP of "otherwork". The ping packet is sent out the default route of
otherhome, which is to "etherhome", the lan0 interface of the home PC.

When the "home" PC sees a packet for otherwork arriving on its lan0 interface,
it forwards it to "work". The packet goes out its sl0 interface to the sl0
interface of "work", which sends it out its lan0 interface to "otherwork".
Hence the packet from "otherhome" arrives at "otherwork" OK.

The problem is the return trip. "Otherwork" has to respond, but it has a
packet that comes from a machine on an unknown network. It cannot respond.

There are ways to handle this situation, but further discussion is beyond the
level of this simple introduction to TCP/IP networking. Even sophisticated
tricks don't really help much. Suppose instead of "otherwork" the machine that
had to respond were far away on the Internet. The only way packets could get
back to "otherhome" would be if the routing throughout the Internet sends the
packets from far away to your local network. If you use some arbitrary subnet
numbers for your home network, the routing will foul up completely and the
packets from far away will be routed to the actual subnetwork whose subnet IP
you have stolen.

How to make Case (1) work
-------------------------

In case (1), your home net is the same subnet as your office. That means
your network administrator has to assign you IP's for each home machine, plus
one unused one for sl0 on the work machine.

For two home machines, you need quite a file IP's. Here is a list of
hypothetical ones:

work machine lan0 199.99.99.77 (must be registered with DNS)
work machine sl0  199.99.99.88 (some unused IP. Doesn't need registration)
home machine sl0  199.99.99.99 (must be registered with DNS)
etherhome    lan0 199.99.99.11 (doesn't need to be registered. Must be unused)
otherhome    lan0 199.99.99.22 (must be registered with DNS)

Let's go through the situation I've just discussed once more, but this time
the home net is a subnet of the work net. As I outlined, when "otherhome"
pings "otherwork", the ping packet follows this route. First it goes to
"etherhome" (otherhome's default route), which relays it over the slip line to
"work" (homes default route), which passes it to "otherwork" (because it knows
how to talk to other machines on the same subnet using MAC addresses).

This time "otherwork" sees that the IP of the home machine is on its own
subnet. So it broadcasts "Who has IP 199.99.99.22". There won't be a response,
UNLESS your work machine also does proxy arp for the second home machine. To
make this happen, you need to give the following
proxy arp command  on "work":

arp -s 199.99.99.22 00:00:00:c0:11:22:33:44  pub

A big home network
------------------

Let's say you have a bunch of work machines that are on the work subnet, and
you want to bring them all home and tie them into the Internet from home. To
do that, you're going to need two additional unused IP addresses. One for the
sl0 interface of the work machine. The other is for the Ethernet interface of
your home machine.

You can probably get this to work by listing all the machines with their
IP's and names in a HOSTS file that you put on every home machine. That will
work when you aren't connected.

To make it all work when you are connected, you'll have to make the work
machine give proxy arp commnds for each home machine. The default route for
all the home machines will have to be the machine with the SLIP connection,
and the default route for that machine will have to be the work machine.



Debugging Tools
---------------

I've mentioned PING.EXE as the most useful tool. Anther very useful tool
is NETSTAT.EXE which is used like this:

netstat -r

This reports all the routes. YOu can see the IP for each interface and the
default route. To see the arp tables use:

netstat -a

Conclusions
-----------

The SLIPHW package is set up for the very simple situation where you connect
one home machine to your office machine. You need an IP on the office subnet
for the home machine (sl0) and one ununsed IP for the work machines sl0.

When I first got into this, it seemed incredibly complex and I was
overwhelmed. If you are feeling overwhelmed, don't worry. It is quite logical.
Just think about it carefully.

I've had a home network working with Warp Connect for about 6 months. But
that isn't functional any more because my son took his PC with him when he
left for college.

If I'd had the SLIPHW package working when I had the home network, I could
have tested out the ideas I've discussed. But I cannot. So the details on
tying in the home net are untested.

If you get a home net working and you make modifcations of the scripts to
automate the process, please send me a copy.

Sometimes what is possible in theory doesn't work because of software bugs.
If someone tries to get a home net working and runs into problems with IBM's
TCP/IP not working as it should, I'd also like to hear about it.

Good luck.


Bruce Clarke
Oct 1, 1995
