DOCS

 

WHAT IS LINUX?

IP MASQUERADING

LINUX IP CHAINS

SETTING UP AN INTERNET CONNECTION

What is Linux?

In layman's term...

Applications for Linux...

Where do I get it?

 What is IP masquerading?

IP masquerading is a feature recently introduced into the Linux kernel that allows you to use one network interface, be it an Ethernet, SLIP, PPP, or other TCP/IP interface, using an internal network number. Clients on the masqueraded network use IP numbers (usually something like 10.0.0.x or 192.168.0.x) which are designated as internal network numbers on the Internet and have no real computers attached to them. The masquerading Linux server restamps all outgoing packets with its own real IP address and an alternate port, and restamps all incoming packets with the masqueraded addresses and sends them over the masqueraded network to the client. The client system has no way of knowing whether or not it is actually on the Internet, except that operations that involve the client taking the role of a host do not work with IP masquerading, since the IP address of the client is not a real, valid IP address.
 
IANA Reserved Private Networks
Network type 
Number of addresses		 Network address Netmask
Class A 
16,194,277		 10.0.0.0-10.255.255.255 
127.x.x.x (loopback)		 255.0.0.0 
8-bit
Class B 
64,000		 172.16.0.0-172.31.255.255 255.255.0.0 
16-bit
Class C 
253 x 253 networks		 192.168.0.0-172.168.255.255 255.255.255.0 
24-bit
 
What are the advantages and disadvantages of using IP masquerading as opposed to real IP addresses?
With IP masquerading, there is virtually no limit to how many computers may be put on a network, since masqueraded IP addresses are not real. And because masqueraded IP addresses may not be addressed from anywhere but the network itself, the network is effectively put behind a firewall --- a big security advantage.

Without masquerading, one must obtain enough IP addresses to house every computer on the network. Not only is this a waste of rapidly-depleting IP address space, it costs money and may not be a good idea security-wise.

Most client-only TCP/IP applications work with masquerading, notably Web browsers, FTP clients, and Internet Relay Chat clients (except for DCC file sending and receiving). IP masquerading does not yet work with everything. Some things will never work with masquerading, notably applications of TCP/IP that require a system to take the role of a host, or peer-to-peer TCP/IP communication that goes through the masquerading server. Examples of peer-to-peer include wide-area file sharing, TCP/IP video conferencing (CU See Me, for instance). Setting FTP servers up within the masqueraded network is also impossible.

For some appliations, such as RealAudio and IRC, separate modules are available which provide functionality for these services.

Are there any performance penalties when using IP masquerading?
Within a network, there is no performance penalty as the workstations on the network communicate directly with one another over the wire. When data travels through the masquerading server (a.k.a. "gateway"), there is some CPU overhead because the kernel must restamp each and every incoming and outgoing IP packet with different addresses. However, as long as the masquerading server has a fast enough processor and enough RAM, there should be no noticeable performance penalty when using IP masquerading.
What you will need
In order to use IP masquerading on an Ethernet network, you will need two Ethernet cards, one for the masqueraded network and one for the outside world. Both cards need to have been detected by Linux. If your entire network is currently wired to a bridge or router, the Linux box will go between the bridge or router and the rest of the network.

You will also need a 2.n kernel.  If your distribution does not include masquerade support, you will have to build your own kernel.

Getting the patch and rebuilding the kernel
Here is a typical IP masquerading setup:

 

This document assumes that you will arrange your network in a manner similar to what is illustrated in the above graphic.

Although it isn't recommended, it is possible to daisy-chain the two Ethernet cards on the Linux computer to create one continuous network with both masqueraded and real IP numbers on it. Use this in a situation in which you would like to have real IP hosts and masqueraded clients on the same network. Or, you might have a proxy server on the Linux machine which the clients' network traffic must go through. Either way, using this double-networking is always an option, but it tends to increase network traffic because each packet going two or from a masqueraded client is transmitted twice over the same wire -- a bad idea on busy networks.   Further, it becomes impossible to enforce the virtual IP addresses, because anyone on the network may change the TCP/IP settings from their workstation to use a real IP address.

Rebuild your kernel with IP masquerading capabilities. The first step of rebuilding the kernel is to reconfigure it. To reconfigure your kernel, change to the /usr/src/linux directory and type:

make config

If you're running on a curses-compatible terminal or in X, try make menuconfig and make xconfig, respectively.  You will be asked a rather long series of questions about your computer hardware. Unless you've reinstalled your kernel source since your last rebuild, the last settings you used before are probably the defaults now, meaning that you can probably press Enter at most of them. A little ways down you should be asked whether you want TCP/IP networking enabled. Choose "yes" here, and you will be asked another string of questions. The following table contains suggested responses.
 

Kernel Build Parameters Needed for Masquerading
Option Suggested Response
TCP/IP networking yes
IP: forwarding/gatewaying yes
IP: firewalling yes
IP: firewall packet logging no
IP: masquerading yes
 

In the section marked "It is safe to leave these untouched," press Enter to accept the defaults for each (unless, of course, your setup is different). When configuration is done, type:

make dep
make clean
make zImage

If all goes well, your kernel will recompile. Compilation should end with messages similar to:

System size is 1234567 bytes.
Compressed is 12345.

When you are returned to your shell prompt, create a backup of your kernel by typing the following (replacing vmlinuz with the filename of your kernel, if necessary):

cp /vmlinuz /kernelbackup1

Next, copy the newly made kernel to your current kernel (again replacing /boot/vmlinuz with the filename of your kernel):

cp arch/i386/boot/zImage /boot/vmlinuz

Last, but most important, type

lilo;sync

... to install your new kernel. If all goes well you should see:

* Added linux

Restart your system to boot with the new kernel.

Setting up network routes
Once you have the masquerading-enabled kernel running, you need to set up the data routes for your network. Your internal network number should be one designated as internal, such as 10.0.0.0. In this example, we will use 10.0.0.0 as the network number, using only a single 253 address block.

Each client attached to the to-be masqueraded Ethernet card will have an IP address 10.0.0.x, where x is a number between 1 and 254. The Linux system also needs to have an IP address on the internal network (under Linux, a computer may have one IP address per network interface, which means that it may have several IP addresses). It is recommended that the Linux system's IP address be 10.0.0.1.

Linux assigns names to each network interface on the system. A network interface may be an Ethernet card, a SLIP or PPP connection, a Token Ring connection, or other network link. Ethernet interfaces are named eth0, eth1, and so on. When Linux starts, it will assign interface names automatically as it detects them. Make sure that your existing, real-IP-address network interface is on eth0 and that your masqueraded network is connected to eth1. To determine if your existing real-IP-address network is connected to eth0, try starting up with only the existing network connected to the computer and pinging another computer. If you can ping, that is the right card, eth0. Otherwise, try moving the cable to the other Ethernet card. If you can ping from that card, that card is eth0. Plug your to-be-masqueraded network into the other card, which is named eth1 if it was detected by Linux at startup.

One of the programs necessary to set your IP masquerading table up correctly is called "ipfwadm."  This should be included with your Linux distribution.

Try issuing the following commands to establish your network route to the to-be-masqueraded network, replacing 10.0.0.1 with the IP address of your Linux computer on the to-be-masqueraded network, and replacing the 10.0.0.0 with the IP of that network. Change the netmask as necessary. The 0.0.0.0 IP is a loopback IP number and should be OK for any setup.

ifconfig eth1 up netmask 255.255.255.0 10.0.0.1
ipfwadm -F -a m -S 10.0.0.0 -D 0.0.0.0
route add -net 10.0.0.0 dev eth1

Try changing the IP settings on one of the clients connected to your masqueraded network to the following, replacing 10.0.0.2 with an IP address not yet used on your masqueraded network, if necessary. The gateway setting should be the masqueraded IP address of your Linux computer (which should 10.0.0.1 unless you are using different settings). The netmask 255.255.255.0 should be OK for most setups as well.

Once the client is properly configured, try pinging it by typing the following at your Linux prompt (replacing 10.0.0.2 with the IP address of the client):

ping 10.0.0.2

If ping indicates that packets are traveling back and forth, then your setup is correct. Place the ifconfig, ipfwadm, and route commands mentioned earlier at the end of your rc.local file.

The moment of truth has arrived.  Now you're ready to reboot to see if the masquerading starts automatically at startup as it should. Go for it! When the system comes back up the masquerading should be automatically set up and working. Try 'surfing the net from the client which was test-configured a moment ago, to make sure that everything works as it should. Assuming it does, you are ready to configure each client on your masqueraded network with its own IP address, just like you configured the test client. Test each client to make sure they can all communicate with the world.

Congratulations on your newly masqueraded network!

SETTING UP LINUX IP CHAINS

 This document contains a minimal set of instructions to get Linux IP Masquerading working on 2.2.x kernels that use IP Chains.

Contents:

What are IP Chains

For the purposes of this document, IP Chains allow you to multiplex a bunch of computers on a private LAN onto a single connection to the Internet. The idea is that all computers inside the LAN use IP addresses reserved for testing to communicate with each other. A single computer (the gateway) on this LAN maintains a connection to the Internet (presumably by PPP), and all clients inside the LAN set this computer as their gateway for all traffic not destined for the local network. The gateway computer then forwards the packets on behalf of the internal client, and delivers any response from the outside world back to the internal client.

If you haven't figured it out already, this saves you from having to get multiple phone lines, or limit the house to one data line which everybody must share. In other cases, if you have a single ISDN or ADSL line, everybody can share in the use of a REAL connection.

Requirements

The first major thing you must set up is a house LAN (or a normal LAN) to use the masquerading services that we are going to add. If you have read the house LAN description and are wondering why you need the LAN, then you probably don't need IP Chains...read the ``What is it?'' section again. Remember, the goal of IP Chains is to have only one computer actually connected to the outside world, while allowing many computers on the private LAN to think the are also connected to the outside world.

Next, you need a computer with Linux installed and running. This should work on any distribution of Linux, but our testing has been done on Red Hat 5.2 and Slackware 3.4. To make IP Chains work, we will be building and installing a new kernel, so you will need gcc to recompile. We will use the Linux 2.2.0 kernel, although any 2.2 kernel should work. If you are running a 2.0.x kernel, IP Chains will not work for you, look at the Linux IP Masquerading page.

It should be fairly obvious, but you do need some type of connection to the outside world. This connection may be a dialup SLIP or PPP connection, or it can even be a ethernet connection. Before going any further, you should make sure that you are able to dial you provider (ISP) and perform activities such as using DNS, telnet-ing, ftp-ing, browsing the web etc... See the USSN PPP HowTo for help with setting up the dialing.

Kernel Setup

This work is to be done on the gateway machine only. The instructions in this section assume:
  1. This machine has working dialup access
  2. You have root access on this machine
  3. Willingness to install a new kernel

Configure the kernel options using any of the three methods (config, menuconfig or xconfig). Use the options you would normally use for your computer PLUS the following:
Description #define
Prompt for development and/or incomplete code/drivers CONFIG_EXPERIMENTAL
Enable loadable module support CONFIG_MODULES
Networking support CONFIG_NET
Network firewalls CONFIG_FIREWALL
TCP/IP networking CONFIG_INET
IP: firewalling CONFIG_IP_FIREWALL
IP: always defragment CONFIG_IP_ALWAYS_DEFRAG
IP: masquerading CONFIG_IP_MASQUERADE
IP: ICMP masquerading CONFIG_IP_MASQUERADE_ICMP
Dummy net driver support CONFIG_DUMMY

In summary, this prepares the kernel to do firewalling for your network. Part of the firewalling functionality is doing IP Chains.

Next, recompile the kernel. Read the instructions on how to do that. In general though, these will be the steps:

  1. make menuconfig
  2. make dep clean bzImage modules
  3. < Install kernel >
  4. make modules_install

Check the kernel:

Install the kernel and reboot. Make sure all of your other devices are working correctly. Do some of your ``normal'' work and make sure everything works; if not, you will need to repeat the kernel configuration, recompile and install to get the devices correct. A quick list of things to check:

Dial your provider and make sure that works just as it did when you first started. If you forgot to add serial device support or PPP to the kernel, then this will not work.

Configuring IP Chains

Now you should have a system running a 2.2.x kernel. You should find a file called /proc/net/ip_fwchains on the system; if not, then you did something wrong in the kernel setup, or you loaded the wrong kernel. The next step is to configure the firewall/IP Chains rules.

It is beyond the scope of this document to explain the full usage of the Linux firewalling system, so only the items which directly affect masquerading will be explained.

You will now need to download and install the IP Chains utility program if you do not already have it. Check to see if you have it by running "which ipchains"; if it does not show any files, then you will need to install it. You can get a copy at the home page.

In the interest of maintaining security when possible, we will configure the firewall to be very strict in who can use our masquerading services. To do this, we first set the firewall to deny forwarding (and hence masquerading) services to clients by default. As root, issue the following command: 


/sbin/ipchains -P forward DENY

This command means that for forwarding, the default policy should be to deny service. Next, we need to authorize certain clients to forward/masquerade; these are the people inside the private LAN that this computer is serving as a gateway for. If you are following the standard procedures, you are using the 192.168.0.0 network and therefore have clients such as 192.168.1.2

We will instruct the kernel to forward to any address from each individual client inside our network. This command says to forward and masquerade packets coming from IP addresses beginning with 192.168.1; it does not matter where they are asking to go. 


/sbin/ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0.0.0.0/0

The kernel forwarding flag may need to be set. Please check the file /proc/sys/net/ipv4/ip_forward. If it is zero, execute the following: 


echo 1 > /proc/sys/net/ipv4/ip_forward
NOTE: On Red Hat systems, this can also be activated by setting the following line in /etc/sysconfig/network: 

FORWARD_IPV4=true
This will only take effect though if the runlevel 2 startup scripts are run (S10network), so it is a good exercise to know how to do this manually.

Because some protocols that ride on top of TCP/IP are poorly designed, certain applications need special purpose code in the masquerading code. FTP is the most widely used protocol that needs a special kernel module inserted into the Linux kernel to run properly. Execute the following command to insert the module: 


/sbin/insmod /lib/modules/2.2.0-final/ipv4/ip_masq_ftp.o
There are other modules for playing Quake etc... For more information about IP Chains, see the "Other Resources section.

Configuring clients:

 The true beauty of masquerading is that its existance if completely transparent to the clients using it. These are generic instructions for configuring a client.

There are one general requirement that must meet for client to outside world communications to work. The client must be configured to use the server (the one we setup above) as a gateway. This may require routing or other changes on the client, depending on the system.

On a UNIX box, the most important route will look like (assuming 192.168.1.1 is the gateway): 



  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              192.168.1.1           UG       0    789
You can examine your routing table using the command netstat -rn. The "n" supresses translation via the host name resolution facility and displays IP addresses instead.

On some UNIX systems, adding this route is as easy as creating a file named defaultrouter in /etc (takes effect on next reboot). It is also possible to add the route manually with the route command in a startup script or manually. Many GUI based systems will simply provide boxes to fill in your IP address and that of your router.

Troubleshooting

Here is some information that may help in setting up the gateway machine. First, an example routing table (netstat -r): 

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
pm2-higuera.fix *               255.255.255.255 UH     1500 0          0 ppp0
localnet        *               255.255.255.0   U      1500 0          0 eth0
loopback        *               255.0.0.0       U      3584 0          0 lo
default         pm2-higuera.fix 0.0.0.0         UG     1500 0          0 ppp0
Also, the output from a minimal IP Chains setup (/sbin/ipchains -L): 

[root@marbles /root]# /sbin/ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy DENY):
target     prot opt     source                destination           ports
MASQ       all  ------  192.168.1.0/24        anywhere              n/a
Chain output (policy ACCEPT):
[root@marbles /root]#

Other Resources:

 

SETTING UP AN INTERNET CONNECTION

Setting up an Internet connection can get tricky, even frustrating, especially if you're a new Linux user. If your ISP is like most others, it will use
Point-to-Point Protocol. I will first describe setting up and using minicom and pppd separately, and then using a chatscript. One can connect to the
Internet with either of these methods; if one doesn't work for you, try the other. If both work for you, then you can choose whichever one is the most
convenient.

If you want to try to get set up quickly, there's a web-based configuration script that will help you. It uses CGI scripts to create files for you to paste
into your configuration files in /etc/ppp/. The URL is http://www.linux.net.nz/pppconfig/.

Lord Pyromage mentioned the pppsetup program, which comes with Slackware. According to him, it makes the PPP setup process much easier. So if
you've got Slackware, you might want to give it a try if you don't want to read this page.

If I haven't scared you away by now, read on. Please, please be patient with my writing. I try to explain things so you'll understand, not so you'll get
through it quickly. I try, though. :-)

1.Using Minicom with PPPd 
Stuff to Watch Out For 
DNS and Nameserver Configuration 
PPP Options 
Using PAP or CHAP? 
Dialing In 
Possible Routing Problems 
Other Sources of Help 
2.Using a Chatscript 
3.Disconnecting 
4.Modem Trouble 
PnP and Winmodem 
IRQ Conflict 
Finding Exact Init Strings 
5.Author's Notes 
No Pico? 

Using Minicom with PPPd

First you should start out by configuring minicom (a terminal dialup program). At the Linux prompt, as root, type minicom -s.

That will load minicom in setup mode; after this, just set up the configurations: modem initialization strings (if you have a generic modem the initialization
string you might want to try using would be AT&D2; consult your modem manual for the fancy options), baud rate, and so on. Make sure all this is done,
and then choose 'Save as dfl' (saving it as the default) from the main minicom menu.

If minicom complains about not having /dev/modem, get out of the program and type ln -sf /dev/ttyS1 /dev/modem. If your modem was on COM2 under DOS or
Windows, use that. Otherwise if you have COM1, for example, you'd use ttyS0 instead of ttyS1. The number after the letters is one less, since Linux
starts at 0 instead of 1.

Stuff to Watch Out For

I would try watching out for what baud rate you use. Don't use too high of a baud rate, or you might be disconnected because of an unstable
connection. Also, make sure the baud rate is high enough to use your modem at its highest speed. I put the baud rate up just one setting above my
modem's fastest transfer speed. Your initialization string could possibly also have something to do with unstable connections. If you don't know what
you're doing (like me), I would suggest that you use a simple initialization string like AT&D2.

DNS and Nameserver Configuration

At the Linux prompt again, type pico /etc/resolv.conf to enter the nameserver addresses.

Insert something similar to the following lines, replacing them to match your own:

search local.net
nameserver 205.136.28.2

A nameserver is a machine that most providers set up to translate the hostnames of Internet hosts into their IP addresses (for example, it would resolve
www.local.net to 205.136.38.10). Many ISPs have more than one nameserver, so don't be confused if you receive two (or more) addresses when
requesting information about your ISP's nameserver. You might want someone who is already using Linux to do a dnsquery on your ISP's domain. For
example, if your ISP is Local Net (mine) and their front page is at http://www.local.net, then have whoever is doing the DNS query type this:

dnsquery local.net

Or:

dnsquery www.local.net

Again, I'm using my own ISP as an example. There will also probably be a secondary nameserver for your ISP, so you can use either one, or even better,
both. The nameservers are the last lines in the dnsquery; make sure the person doing the dnsquery knows that. Yours will be different if you don't use
Local Net as your provider. I want the IP address of ns2.local.net, not the hostname. ns2.local.net is 205.136.38.2 so I write that down somewhere.

Just add that "nameserver" line in /etc/resolv.conf followed by the IP address of the actual nameserver (205.136.38.2) and complete the rest of the process.
You can also call up your ISP through the phone and ask them the IP address of the nameserver, if you don't know anyone who is already on Linux or who
can find out. If you already know what your ISP's nameserver is, then you didn't really need to read the previous few paragraphs on the nameserver.

As far as I know, you can use anybody's nameserver as long as you have the IP address (numerical, e.g. 205.226.156.2) for it. That means you can have
your /etc/resolv.conf file look exactly like mine and it would still work.

PPP Options

Now you also should edit /etc/ppp/options by typing pico /etc/ppp/options. This is really important in starting point-to-point protocol (PPP). If you don't fill it in
you'll have to specify the options every time you type pppd, and that's would be a big hassle. Insert the following lines into the file:

0.0.0.0:
/dev/ttyS1
lock
crtscts
defaultroute
asyncmap 0
mtu 576
mru 576

The only thing you might need to change is the device entry that tells which device to use for PPP. On my computer, with my external modem using
COM2, it's /dev/ttyS1. You should know what COM port your modem is using, either from your experience as a DOS/Windows user or as a frequent Linux
user (which you're probably not... for now).

Once you find that, you can refer to that device using /dev/modem by making a symbolic link from /dev/ttySX ('X' representing whatever that number is) to
/dev/modem. Do this by typing the following:

ln -s /dev/ttyS1 /dev/modem

Replace ttyS1 with whatever the device that you're using is, if necessary. The basic way to remember is that ttyS0 is actually COM1 under DOS, ttyS1 is
COM2, ttyS2 is COM3, and so on; the number following "ttyS" is just one number less than the number following "COM" in DOS or Windows.

The 0.0.0.0: should be put in the PPP options file if you have a dynamic IP address (your IP address/hostname is randomly assigned to you by your ISP and
usually changes everytime you establish an Internet connection). If you have a static IP address (it remains the same each time you connect), I'm not
sure if you can leave this out or put in the IP address that you're assigned. If anybody can clear this up for me, please let me know.

The mru and mtu lines are your receiving and transmitting packet sizes, I think. I heard someone on IRC ask how to lower the packet size so that a large
download wouldn't get in the way of other accesses to the Internet going on at the same time. The speed you can transfer is still the same; it's just
smaller packet sizes. A packet size of 576 is smaller than a packet size of 1024.

After all this is done, all you'll have to do is type minicom as root and then pppd as root. Minicom can be executed by all users, but the Point-to-Point
Protocol Daemon (pppd) can only be executed by the superuser (root). I tried changing permissions on the file /usr/sbin/pppd. If you ever accidentally
change the permissions on the pppd file/executable, just type chmod 755 pppd from the /usr/sbin/ directory, as root. If you didn't mess with the permissions,
you won't need to do the chmod stuff.

Using PAP or CHAP?

More and more ISPs are switching to PAP or CHAP authentication, which requires a little extra work on your part. Fortunately, this wasn't as hard as I
thought it would be. If you're sure your ISP doesn't use PAP or CHAP, you can skip on to the next section. If you use PAP or CHAP, you won't be
presented with a login prompt when you dial in with minicom, so that's how you know.

You need to fill in /etc/ppp/pap-secrets if your ISP uses PAP, or /etc/ppp/chap-secrets if your ISP uses CHAP. Those files should already be in there, but if they're
not, create whichever one you need. All that you really need to do is fill in the chap-secrets (or pap-secrets) file like this:

# Secrets for authentication using CHAP
# client server secret IP addresses
dork * unpopular

That's where 'dork' is the username, and 'unpopular' is the password. The asterisk (*) can be left like that. The pap-secrets file also uses the same
syntax, just a different filename.

In the PPP options file (/etc/ppp/options) it should look like what it was, except with one extra line.

0.0.0.0:
/dev/ttyS1
lock
crtscts
defaultroute
asyncmap 0
mtu 552
mru 552
name dork

That extra line is name dork, which tells pppd to use that username along with the chap-secrets (or pap-secrets) information when asked for
authentication.

I use CHAP authentication for my new ISP but instead of just the username, they want the username@domain.net (pretty weird, huh?), so instead of just
"name dork" in /etc/ppp/options I would have to put in "name dork@ynn.com". That also goes for /etc/ppp/chap-secrets. Instead of "dork" under "client" I
had to put in "dork@ynn.com". If anyone has to do the same thing, let me know. Otherwise, filling in just the username should work fine.

Dialing In

Now, to establish the dialup connection, run minicom. When it loads, it should show the initialization string with the cursor at the end of the text string.
Press enter and it should say "OK". Type ATDT #phone#, where "#phone#" is the phone number to dial. When the other end picks up, it should prompt you
for a login name and password, which you should type in (unless you're using PAP or CHAP, and if you are, just use the Alt-q combination and answer
"Yes" right there). For some ISPs it will ask whether to use PPP or not, so answer yes. When it shows the PPP data (the stuff that looks like junk and
garbage: *&*&*!^%#!^$!%%@#&^$%&*!$%), press Alt-Q and answer 'yes' to "Exit without reset?". That should take you back to the prompt, where
you should then type pppd. Typing pppd is critical to establishing the connection.

Possible Routing Problems

If your ISP uses a gateway (a computer that connects you to the rest of the Internet) that's a different machine than the one you connect to for dialing
in, here's what you should do. You need to change the routing configuration on YOUR machine so that you can actually be recognized as a machine on
the Internet. The way to tell if you need to change the routing is if you type ifconfig as root and it shows that you have an IP address through your
modem, but you can't get ping responses from any hosts, even when you use IP addresses. The way to fix it? First, type route and it will display something
like this:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 * 255.0.0.0 U 0 0 3 lo
205.226.158.252 * 0.0.0.0 U 0 0 7 ppp0

As you might expect, most of the IP addresses will probably be different on your setup. The bottom route is incorrect on my system, so to change it, I
type route del 205.226.158.252 ppp0 to delete it. Then I type route add default ppp0 to set the new route. Or, if you don't want to delete the old route, you can
just set the new route, and it will work just as well.

Those are the only things I had to do. For some reason unknown to me, that pointed the gateway to the correct address and I successfully got ping
responses.

Other Sources of Help

That should get your dialup connection up and running. If not, keep trying or ask for help (through any of the *linux* newsgroups or the #Linux* channels
on IRC... I hang out in #LinuxHelp on the Undernet).

As usual, I support my work fully, so e-mail me at joshuago@usa.net. You can also use the help form or the guestbook (which is really a feedback form).

Using a Chatscript

This is a very convenient way to connect to the Internet. Once you get this set up, you can connect with a single command prompt. However, there are
things you should know first. Here are things to write down:

What does your login prompt look like? For some ISPs it's login:; for others, it's username:. If you use PAP or CHAP, there will be none. 
What does your password prompt look like? Usually it's password: but fill whatever your ISP prompts you for if you want this to work. PAP and
CHAP users don't get a password prompt. 
How many lines are in between, say, CONNECT 38400 and the first prompt? This is how many \n's you will use. 
Are there any other prompts that are presented to you when you first log in? 

The best thing to have done before this is to have made sure that you could dial in with minicom and use pppd to establish a connection. That would
have ensured that it was possible for you to get connected. This method is a permanent solution so you won't have to go through the tedious process of
typing several keystrokes and waiting to enter the next command.

Now, go on to making the actual script. As root, create a file to use as the actual chatscript (the text file tells the chat program how to communicate with
your modem). I suggest giving it a name with the .chat file extension; for the sake of simplicity, let's just say that we'll use yourispname.chat as the
filename. To edit the file, type pico yourispname.chat.

Now put in the following lines into yourispname.chat:

""AT&D2
OK ATDT#phone#
38400 \n
ogin: foobar
word: altm.415

In place of AT&D2 you can plug in the initialization string that you use. In place of #phone# you should put in the number that you want your modem to
call, so for me it would look like ATDT4755868. The '38400' represents the speed you want to connect at and '\n' is telling chat to expect a new line. The
part saying 'ogin: foobar' is telling chat to expect the text 'ogin:' to appear somewhere and respond to it by sending the word 'foobar'. The same applies to
the next line. Don't put in the last two lines if you're using PAP or CHAP because the passwords aren't authenticated with plain text like that.

Basically you type in any prompts that are presented to you, and then type in what to send back. What is presented and what is sent back can be
separated by a space in between.

If you dial in, watch for the number of lines between your baud rate (like 38400) and the login: prompt; if there's one line in between, use one \n
character; if there are two, use two \n characters, and so on. Be sure to watch out for this.

To prevent users other than root from reading from the file and finding out your password for logging in to your provider, you should change the
permissions on the chatscript so that only root can read from it. I would do this by typing chmod go-rwx yourispname.chat.

Now, you should make another script -- a normal (shell) script. Move to /usr/sbin as root and create the script. Let's call it yourispname. Now we proceed to
edit the file by typing pico yourispname in /usr/sbin. Keep in mind that you can change the filenames to whatever you want.

Put the following line into the normal (shell) script, yourispname:

pppd connect 'chat -f /root/yourispname.chat' /dev/modem 38400 0.0.0.0: asyncmap 0 crtscts defaultroute

You might want to change the path to yourispname.chat, having it correspond to the directory that you placed yourispname.chat. After you put in this line,
make the file executable and only to be accessed by root (the head honcho on the system) by typing chmod 700 yourispname.chat.

To connect, all you have to do is type the name of the file that you created. All this should be done as root.

Disconnecting

The way I disconnect is I type killall pppd, which kills the pppd program from running and therefore shuts down communication between your modem and
your ISP.

Jas has suggested this shellscript:

#!/bin/sh
kill -TERM `cat /var/run/ppp0.pid`

That means you'd put that in a file using a text editor such as pico or vim, and save it as whatever filename you want (ppp-down.sh for Jas' example).
Then when you're back at the prompt, type chmod +x ppp-down.sh so that it can be run (executed). I guess I should try this when I disconnect...

Modem Trouble

There might be all sorts of problems you encounter that are related to your modem, and that is a major obstacle for a lot of people.

PnP and Winmodem

Linux users who have plug n' play (PnP) modems or the notorius WinModem from US Robotics might have a lot of trouble in getting Linux to recognize that
their modem is present. The best solution is to use another modem, make sure that it doesn't say "WinModem", "Plug n' Play", "PnP", "Exclusively for
Windows", or anything similar.

Two ways you can try to get Linux to recognize PnP devices are messing with your BIOS (set the "PnP OS Installed" option to "off") and/or loading
Windows 95 first, then using a DOS program called Loadlin to boot a copy of your Linux kernel, usually found as the file called vmlinuz in your /boot/
directory. The file, LOADLIN.EXE, is usually available from your Linux distribution media, be it FTP or CD-ROM.

IRQ Conflict

Your modem might try to be sharing the same means of communicating with the system with another device that has the same interrupt request, or IRQ.
Symptoms of this include an abnormally slow connection, an error about timeouts sending config-requests, and a disconnect soon afterwards.

HydroFlow from IRC on the Undernet told me that all he had to do was type setserial /dev/modem irq 10 to get it working. Of course, that's his system, so
change the IRQ to fit your own system settings. Then the instructions seemed to have worked.

You can check for what devices have which IRQ settings by typing cat /proc/interrupts.

Finding Exact Init Strings

Since some of you might be wondering about how to find exact initialization strings for your modem, FusionGyro wrote:

I would like to offer a tip for you to possibly include in your FAQ file. For people coming to Linux from Windows 9x, there is a "simple" way to find all of
the exact complicated modem strings. First, make sure you have logged on to your ISP since you booted. Then just fire up the control panel, open
"Modems", highlight the correct modem, press "Properties", hit the "Connection" tab, press "Advanced", and then hit "View Log". (Gee, that wasn't so
easy, was it ;). You should be staring at a text file. This file will contain everything that was sent and recieved until a PPP connection was made. Here's
mine for an example:

12-13-1998 02:56:07.36 - Cirrus Logic 33600 bps PnP V34 in use.
12-13-1998 02:56:07.36 - Modem type: Cirrus Logic 33600 bps PnP V34
12-13-1998 02:56:07.36 - Modem inf path: MDMTI.INF
12-13-1998 02:56:07.36 - Modem inf section: Modem4
12-13-1998 02:56:07.61 - 115200,N,8,1
12-13-1998 02:56:07.62 - 115200,N,8,1
12-13-1998 02:56:07.62 - Initializing modem.
12-13-1998 02:56:07.62 - Send: AT<cr>
12-13-1998 02:56:07.62 - Recv: AT<cr>
12-13-1998 02:56:07.75 - Recv: <cr>
12-13-1998 02:56:07.75 - Interpreted response: Informative
12-13-1998 02:56:07.75 - Recv: <lf>
12-13-1998 02:56:07.75 - Interpreted response: Informative
12-13-1998 02:56:07.75 - Recv: OK
12-13-1998 02:56:07.75 - Interpreted response: Ok
12-13-1998 02:56:07.75 - Send: AT &F E0 V1 W4 &D2 &C1 S0=0 -C1 <cr>
12-13-1998 02:56:07.75 - Recv: <cr>
12-13-1998 02:56:07.75 - Interpreted response: Informative
12-13-1998 02:56:07.75 - Recv: <lf>
12-13-1998 02:56:07.75 - Interpreted response: Informative
12-13-1998 02:56:07.77 - Recv: AT &F E0 V1 W4 &D2 &C1 S0=0 -C1 <cr>
12-13-1998 02:56:08.22 - Recv: <cr>
12-13-1998 02:56:08.22 - Interpreted response: Informative
12-13-1998 02:56:08.22 - Recv: <lf>
12-13-1998 02:56:08.22 - Interpreted response: Informative
12-13-1998 02:56:08.22 - Recv: OK
12-13-1998 02:56:08.22 - Interpreted response: Ok
12-13-1998 02:56:08.22 - Send: ATS7=60\T0L1M1\N3-J1%C1"H3\Q3B0N1X4<cr>
12-13-1998 02:56:08.22 - Recv: <cr>
12-13-1998 02:56:08.22 - Interpreted response: Informative
12-13-1998 02:56:08.22 - Recv: <lf>
12-13-1998 02:56:08.22 - Interpreted response: Informative
12-13-1998 02:56:08.33 - Recv: <cr>
12-13-1998 02:56:08.33 - Interpreted response: Informative
12-13-1998 02:56:08.33 - Recv: <lf>
12-13-1998 02:56:08.33 - Interpreted response: Informative
12-13-1998 02:56:08.33 - Recv: OK
12-13-1998 02:56:08.33 - Interpreted response: Ok
12-13-1998 02:56:08.33 - Dialing.
12-13-1998 02:56:08.33 - Send: ATDT;<cr>
12-13-1998 02:56:09.92 - Recv: <cr>
12-13-1998 02:56:09.92 - Interpreted response: Informative
12-13-1998 02:56:09.92 - Recv: <lf>
12-13-1998 02:56:09.92 - Interpreted response: Informative
12-13-1998 02:56:09.92 - Recv: OK
12-13-1998 02:56:09.92 - Interpreted response: Ok
12-13-1998 02:56:09.93 - Dialing.
12-13-1998 02:56:09.93 - Send: ATDT#######
12-13-1998 02:56:27.67 - Recv: <cr>
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: <lf>
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: PROTOCOL:LAPM
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: <cr>
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: <lf>
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: COMPRESSION:V42B
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: <cr>
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: <lf>
12-13-1998 02:56:27.67 - Interpreted response: Informative
12-13-1998 02:56:27.67 - Recv: CONNECT 28800
12-13-1998 02:56:27.67 - Interpreted response: Connect
12-13-1998 02:56:27.67 - Connection established at 28800bps.
12-13-1998 02:56:27.67 - Error-control on.
12-13-1998 02:56:27.67 - Data compression on.