Linux: A Network Solution For Your Office


Making the Connection

So how do you go about establishing a cost-effective, reliable connection for your network to the global Internet? Here are the basic steps:

1. Understand what you're doing (by reading the preceding chapters, for instance) and prepare your systems for the connection
2. Find the right Internet service provider (ISP)
3. Establish IP connectivity using, for instance, PPP over a modem line
4. Configure routing for your network if necessary

Preparing for the Connection

All the discussion in the preceding chapters about the basics of Internet networking is meant to serve one purpose: to help you make an informed decision when it comes to shopping for an ISP and getting your network connected. You want to obtain the services you need, at the best possible price; you do not want to pay for services you don't require. Most ISPs also appreciate it when they can deal with a "knowledgeable user," one who can provide a coherent response to questions such as "how many addresses do you need in your subnet?" or "do you have a firewall that performs IP aliasing?"

Finding the Right ISP

How do you pick an ISP for your business? How can you tell good ones from bad ones? How can you provide the best connectivity for your network at a moderate price?

Picking an ISP is hard. Most service providers serve the mass market; their idea of an Internet user is a teenager with a Windows 95 machine, browsing the Web, wasting time in chat rooms, and exchanging silly emails. With rare exceptions, the service these ISPs provide is totally inadequate when connecting a server of any sort. Some even explicitly state in their service contract that no such connections are allowed. In other words, don't expect to be able to connect your company's local area network (LAN) to the Internet for $20 a month!

Before you choose a provider, list your needs. Here is a simple set of questions you'll need to be able to answer when shopping for the service:

1. Do you require IP connectivity for your network?
For instance, if you plan to provide Web access to users on your network, run your own Web or FTP server, the answer is yes.
1.1 Do you require a high-speed connection?
A high-speed connection is essential if you have many users, or if you are offering services such as a Web server to the Internet public.
1.2 Do you require a dedicated (full-time) connection?
1.3 Do you require a fixed IP number?
If you will be offering services on the Internet, such as a Web or FTP server, a dedicated connection and a fixed IP number are a must.
1.4 Do you need more than one IP number?
More than one IP number is needed if you're connecting a network of more than one computer to the Internet, unless you're using your Linux system as a masquerading firewall (see Chapter 11, "Firewalls," for more information on this topic.)
1.5 Do you require routing for a network or just an individual host or firewall gateway?
If you are using more than one IP number, routing is required.
2. Do you require mail services?
2.1 Will you run your own mail server?
Running your own mail server frees you from having to rely on your ISP for managing user mailboxes, and it also allows you to easily implement intra-office email.
2.2 Do you require batch delivery of mail?
Batch email delivery is not essential but very helpful if you are running your own mail server and don't have a full-time Internet connection.
2.3 Do you want the ISP to act as your backup mail server?
If you're running your own mail server, naming your ISP as your backup server helps you avoid losing messages in case your server is down.
2.4 Do you require mailboxes at your ISP? (How many?)
If you aren't going to run a mail server, you must have mailboxes somewhere else, such as a public freemail service or your ISP.
3. Do you need a domain name?
3.1 Do you want the ISP to register the domain name for you?
If you're registering a domain name in the .com domain, it's probably cheaper to do it yourself, unless your ISP offers this service as part of a package deal.
3.2 Do you want the ISP to act as your primary or secondary name service?
Even if you will run your own mail server, a secondary server (in case yours is down) is useful.
4. Do you plan to have a Web site?
4.1 Do you want the ISP to provide Web hosting services?
Having your ISP host your Web site frees your Internet connection from the added load of incoming Web traffic. It also provides faster download speeds for your visitors, at the cost of more cumbersome Web site management procedures and added expenses.
4.2 Do you need secure transaction capability?
Secure transaction processing is important if you plan to offer online shopping services or deal with confidential information.
5. Do you want to have a local news server?
5.1 Do you want to exchange Usenet newsgroups with your ISP?
Some news servers are used to host only private newsgroups; however, you may opt to host a few public newsgroups as well, if they're viewed often by users on your network. See Chapter 9, "Mailing Lists and Newsgroups," for more information.

If you can answer these questions, you can present a shopping list to prospective ISPs. For instance, a few years ago, when I switched to a new service provider, I was able to ask them for a quote for the following services:

1. I need dial-up PPP (not dedicated) at 28.8Kbps. I have my own portable set of IP numbers (a Class C subnet) for which I require routing.
2. I need two-way batched mail delivery via UUCP.
3. I need two-way batched delivery of a specific set of about 100 Usenet newsgroups.
4. I have my registered domain name, for which I require primary and secondary name service.
5. I need to be able to establish a Web site on the provider's host (no secure transactions required).

As I began shopping around, I found that some ISPs had no idea what I was talking about when I mentioned things such as UUCP. Others did not provide certain services I needed or quoted an exorbitant price. Eventually, I found a local ISP that was able to provide all the services I asked for, and I remained their happy customer for several years thereafter, even today maintaining a backup account with them.

In addition to checking whether the ISP delivers the services you need at a competitive price, you also want to ensure that it's an ISP you can rely on for your Internet connectivity. You don't want to be stranded without an Internet connection when your modem loses carrier during the evening peak hours and isn't capable of reconnecting for several hours afterward because all lines are busy. You don't want an ISP that has plenty of modems and offers all the services you need, but has limited outgoing data capacity, causing extreme lag during peak periods of usage. Lastly, you don't want an ISP that goes out of business or gets locked up in an ownership dispute while you remain disconnected. Switching to another ISP in an emergency can be done, but I assure you that it's no fun at all!

For my test system, I have the following shopping list:

1. I need dedicated dial-up PPP service.
2. I need a single, fixed IP number for my server.
3. I need the option of batched UUCP mail delivery for test purposes.
4. I need a domain name that can be one from the ISP's namespace. I want to provide primary name service for this subdomain.
5. I will run my Web server, newsgroup server, and other servers locally.

Picking the ISP is easy: I am going to provide these services for myself, using other existing systems.

Setting Up Your Modem

Before you can establish a dial-up connection over a telephone line, you obviously need a working modem.

Under Linux, it is not necessary to install a modem. Unless you managed to compile a kernel for yourself with no serial line support, your system already has everything it needs to "talk to" and utilize an internal or external modem.

The easiest way to test the modem is by using a communication program. minicom is a robust, simple, but versatile communication program is included with most Linux distributions.

When you run minicom for the first time, do so as the root user, and use the 3s command-line switch. This invokes a menu through which you can set the program's initial configuration (see Figure 7.1). The actual settings are, of course, dependent on your system configuration, modem type, etc. Save the configuration as dfl, the default configuration.

FIGURE 7.1 Configuring minicom.

If minicom is successfully configured, you should be able to interact with your modem. For instance, typing AT and pressing Enter should cause the modem to respond with OK.

One odd feature of Linux serial line handling is that the standard interface that many applications use to configure the line allows only 38400bps as the maximum speed of the line. Higher speeds can be achieved by setting a special flag, which minicom knows about, but other applications may not. This flag can be set at system boot time using the setserial utility. For instance, to set up /dev/ttyS1 so that a speed setting of 38400bps actually means 115200bps, you'd use the following:

setserial /dev/ttyS1 spd_vhi

Using PPP

Had I written this book a few years ago, it would have featured SLIP (Serial Line Internet Protocol) prominently. Times change, however; most (if not all) ISPs nowadays offer dial-up connections using (only) PPP.

This was meant to happen of course. Whereas SLIP was a quick-and-dirty solution that provided just the barest essentials for delivering IP traffic over a serial connection, PPP is a full-featured beast; in addition to IP, it can also be used to deliver packets using Novell's NetWare and other protocols, it supports user authentication, password encryption, and more.

PPP Components

So what, exactly, does PPP look like under Linux?

In the strictest sense, PPP is a feature of the Linux kernel. In order for the PPP interface to exist, the kernel must be compiled with this feature enabled. (Don't worry if you haven't recompiled your kernel; if you're using the Caldera OpenLinux distribution from the attached CD-ROM, PPP is configured as a loadable module. Nearly all other Linux distributions also include a kernel that supports PPP. For more information about recompiling the kernel, please refer to Appendix A, "Configuring the Kernel.")

Of course no kernel features exist by themselves; programs are needed to enable or disable them or to control their behavior. PPP is no different. The program that sets up and maintains a PPP connection is pppd, the PPP daemon. This program usually runs in the background, and it is responsible for configuring the PPP interface, setting up routing when the interface is enabled, providing authentication information, and more. The daemon can also be run from the command-line; for instance, you may log on to a remote system, run pppd there, and then enable the PPP interface on your machine to establish an IP connection.

The Dial-Up Process

Before you can run pppd, you need to have an established connection. The PPP daemon knows nothing about modems, and certainly cannot dial a phone number.

There is, fortunately, a small utility usually distributed along with pppd. The chat utility is used to perform a simple conversation with your modem. This term is commonly used in UNIX-land to describe simple command-response scripts that look somewhat like this:

Wait for this Then send this
Host Name: CIS
User ID: 70000,1111/go:pppconnect<CR>
One moment please  

You get the idea. This, incidentally, is a valid, live script that I use to connect a Linux machine to CompuServe if my primary Internet connection fails for some reason. The actual syntax is different; the conversation strings are passed to the chat program in a file as follows:

"" ATDT5551212 CONNECT "" "Host Name:" CIS "User ID:" \
"70000,1111/go:pppconnect" "Password: " "SECRET*WORD" "One moment please"


Okay, so pppd knows how to establish an IP connection, whereas it lets chat take care of the actual dialing process. But who determines when the connection must be established in the first place?

For a single-user workstation, the easy answer is to let the user invoke pppd, perhaps from a simple command-line script to make his life easier. Not an elegant solution, to be sure, but it works. It would be so much nicer though if you could make the dialing happen automatically instead, so that the connection comes up when the user starts using a Web browser, for instance, and it's automatically terminated when no data traffic occurs for a set period of time.

What's merely a useful feature on a workstation becomes an essential one on a server. For servers not permanently connected to the Internet, the demand-dial capability ensures that the system's users can access the Internet seamlessly (that is, without having to log on to the server and invoke pppd manually, and then forgetting to shut it down afterward!) Even on systems with a permanent connection over a dial-up line, it's necessary to be able to re-establish a connection automatically in case it's terminated due to bad phone line quality, for example.

All this and more can be established by a very useful tool: diald, the dialer daemon. Developed by Eric Schenk, this utility works with a complex set of rules that determine when a connection should be established or torn down.

The rules can say something as simple as "keep this connection up at all times," or "keep this system connected between 9 a.m. and 5 p.m. on weekdays, otherwise connect when there's outgoing traffic, and disconnect after five minutes of inactivity." Or they can be more complex, ignoring specific types of packets for instance, or adjusting the dialer's behavior to match the metering rules of phone companies in countries where local calls are metered.

A version of the diald daemon is available on the attached Caldera OpenLinux CD-ROM. If you're interested in obtaining the latest version of diald or just want to find out more about it, (at the time of this writing) the diald home page was available at

Routing and Forwarding

When the IP connection is up and running, the system must be configured to use the connection for traffic that is sent to destinations outside the local network. This is accomplished by setting up the default route , that is, the route used for any data packet for which no other known route exists. This can be done automatically; pppd under Linux can set up the default route when the physical connection is established and remove the route once the connection is broken.

Setting up the default route, however, is not sufficient by itself to turn the system into a router, that is, a host that acts as an interface between other machines on your local network and the external connection. For this, packet forwarding (IP forwarding) must also be supported by the kernel and enabled. (If you are using a recompiled kernel, make sure it contains IP forwarding support.)

If you're using the stock Caldera kernel from the attached CD-ROM, IP forwarding support is already present. Caldera OpenLinux, however, disables the IP forwarding feature by default and it must be enabled through the LISA utility.

To do so, start LISA with the -system parameter, and select the Configure server/daemon Autostart option from the menu. In the subsequent screen, one of the options is labeled IP forwarding (normally disabled!). Enable this option (see Figure 7.2).

FIGURE 7.2 Enabling IP forwarding.

For the new setting to take effect, you need to restart the kernel. Alternatively, you can manually enable IP forwarding using the following command (issued as the root user):

echo 1 >/proc/sys/net/ipv4/ip_forward

Obtaining IP Numbers for Your Network

Turning on IP forwarding is still not by itself sufficient to allow other computers on your network to connect to the Internet via your Linux system. The problem is that those other computers all have IP numbers that might not be recognized by any system outside your local network. Therefore, even though those machines will be capable of sending data packets out, no return packets can reach them and, therefore, no IP connections can be successfully established.

There are two solutions to this problem. First, you can enable firewall gateway capability (specifically, IP aliasing, also known as IP masquerading) on your Linux server. This enables your entire network to appear under a single IP number to the outside world. The use of Linux as a firewall gateway is covered in detail in Chapter 11, "Firewalls." The disadvantage of this solution is that a firewall gateway doesn't support all types of Internet connections.

Another solution is to obtain an address range from your ISP. The main advantage of this solution is simplicity and compatibility; once the addresses are properly configured, all computers on your network will have full Internet access with no restrictions. One important disadvantage is that if your IP numbers change, you need to reconfigure all systems on the network; another is that since all machines are directly accessible from the Internet, you are not taking advantage of the full protection that a firewall gateway can offer.

Regardless of which solution is used, the address of your Linux machine must be specified on all participating workstations on your network as the default router address.

Incoming Connections

Modems on servers are often used not only to dial out to a remote host, but also to accept incoming connections. For instance, you might want to be able to dial in to the system when its Internet connection is down for some reason. Or you might want to maintain a second modem to accept incoming connections from the system's regular users, who may be on the road, dialing in for their email from home, etc.

A Linux server can also be turned into a receive-only fax server with a modest effort. Incoming fax pages can be packaged as email attachments and sent to a mail recipient (for example, your company receptionist).

Incoming Data Calls

When it comes to accepting incoming connections over serial lines, UNIX systems have a distinct advantage. Unlike MS-DOS, UNIX has been designed from the beginning to support multiple users connecting via serial terminals. Consequently, it's practically second nature for a UNIX system to allow a user to connect and log in via a serial port. This feature lets remote users log on using any terminal emulation program in combination with their modem.

The secret to this capability is the getty program and its variants. If you list running processes on your system (using ps axu , for instance), you'll notice a number of copies of this program running, one for each virtual console in fact. It is the getty program that displays the initial login prompt, and after accepting the user's identifier, calls the login command for password validation and to start the user's shell.

Now getty works just as well on serial lines as on virtual consoles. The trick to using it with a modem is to place the modem in auto-answer mode. On many external modems this can be accomplished by setting a switch. On internal modems, you can configure and store this setting in the modem's non-volatile memory (NVRAM) to ensure that the modem comes up in the proper configuration after it's powered up. Please refer to your modem's manual for more information.

To ensure that the modem operates properly you might also want to enable the Hangup on DTR and Carrier Detect settings. The first ensures that the modem correctly drops the phone line connection when the user's work is finished. The second setting allows the modem to inform the computer if the line was disconnected.

NOTE: Once you enable your modem's auto-answer setting, it will always answer the phone line when powered on, unless explicitly disabled by software. If you have a dual-use phone line, you might want to adjust the number of rings that the modem waits before answering (see your modem's manual for details).

So how do you ensure that getty is started every time the system is powered on and that it monitors the modem line? Why, by putting it in /etc/inittab of course! If you recall from Chapter 4, "Internet Configuration and Basic Security," it is /etc/inittab where you specify what programs are run at startup. If you look at this file, you will already see entries containing the getty command; these entries initiate getty on virtual consoles. What you need is another entry, one that initiates getty on a serial line with a modem attached.

My test system contains an external U.S. Robotics Sportster 33.6 modem. This modem has a row of DIP switches in the back that can be used to adjust the modem's default behavior. I set switch 1 to the Off position (dropping DTR terminates the call), and switch 5 also to the Off position (Auto Answer).

My /etc/inittab file contained six getty lines for the six virtual consoles, but no entry for the modem. My modem is on /dev/ttyS1, so I added the following line:

s1:3:respawn:/sbin/getty ttyS1 38400 vt100

It is interesting to note that the 38400 parameter isn't really a line speed parameter; it is a label that identifies an entry in /etc/gettydefs. This file contains terminal configurations for consoles ( VC) and serial lines, one of which ( 38400) is the correct configuration line for most modern high-speed modems.

The last parameter, vt100, is what getty initially sets the terminal type to (the TERM environment variable.) This setting is compatible with most terminal emulation programs.

Once I made the change, I forced the init program to re-read /etc/inittab by typing the following:

kill 31 1

that is, I sent a hangup ( HUP) signal to the init program, which always runs under process ID 1.

With this setting made, I was able to dial in to the test system from another computer and phone line. I also tested how the system responds to a disconnect during a session; it correctly terminated all running applications on the now orphaned serial line and restarted the getty program which, in turn, reset the modem.

Using plain old getty has a major drawback: it does not permit the sharing of the modem line between applications. If you are using the same modem line for incoming and outgoing connections, getty just won't do.

Fortunately, another version of getty comes to the rescue: uugetty. This program received its name from UUCP, the system from which it inherited its locking mechanism. The idea is simple: When a process wants to use the serial line, it first checks for the presence of a lock file at a known location. If a lock file is present, the process doesn't access the serial line; otherwise, it creates its own lock file before doing so. The lock file contains the process ID, so if a process dies without releasing its lock, other processes can make note of this fact and delete the stale lock file.

This simple mechanism allows cooperating applications to share a modem. The minicom application, uugetty, and pppd are all capable of using compatible lock files. The one problem is that several conventions exist for the location and format of these lock files; fortunately, most decent Linux distributions contain binary versions of important programs that are compatible with each other.

On my test system, all I needed to do to enable uugetty was to change the recently added line in /etc/inittab to the following:

s1:3:respawn:/sbin/uugetty 3d /etc/getty.ttyS1 ttyS1 38400 vt100

The file /etc/getty.ttyS1 contained a single line:


Use of this line ensures that the locking mechanism works properly if you are using /dev/cua1 as the device name with other programs that access the modem, such as minicom.

After this, I once again sent a hangup signal to init ( kill 3HUP 1 ). Because I already had a getty running on the serial line, I also had to remove it. I located the process using the ps command and killed it with a HUP signal. In response to this, init spawned a copy of uugetty on the serial port. I then tested the system by once again dialing in to it from another computer.

PPP for Incoming Calls

Now this is all very good that you can log on from remote machines using terminal emulation but how can remote machines establish an IP connection?

By starting the pppd daemon, of course. This is a bit more complicated than it sounds, for the following reasons:

The first problem is solved on most desktop operating systems through the use of logon scripts. For instance, under the Dial-Up Networking (DUN) facility of Windows 95/98, scripts with the .SCP filename extension are (typically) stored in the Program Files\Accessories directory.

The answer to the second problem is a properly formulated pppd command line. This command line could be typed manually, but far more likely, you'll make it part of a logon script, such as the scripts used with Windows 95 DUN. The command line, in many cases, will look like this:

exec /usr/sbin/pppd passive silent modem crtscts

pppd has many more options, but this line is typical when handling incoming connections. The use of the exec command is a simple way to save a little bit of memory and system resources. Instead of launching pppd as a separate process, exec causes the shell to transform into the new process. That means one less entry in the list of processes and a little bit of memory and system resources saved.

The passive and silent options tell the pppd daemon to sit there and wait for the user's workstation to initiate PPP negotiation.

The crtscts and modem options ensure that pppd uses hardware handshaking to communicate with the modem, and they monitor the Carrier Detect signal to detect when a connection is dropped.

The final part of the command line specifies the local and remote IP addresses. The local address can be the machine's primary address (in this case, it actually doesn't represent a problem if you use the same IP address that's normally used for the Ethernet interface).

As for the remote address, it can be anything as long as the workstation that connects to your system doesn't expect to connect via your system to other computers. If, however, such routing is desired, the address assigned to the remote workstation must be a valid address for which you can provide routing. Depending on what IP address range you use, it might make sense to reserve a portion of it for incoming dial-up connections. For instance, if you have a full Class C address space of 256 addresses, you might want to reserve the upper 128 addresses for incoming PPP connections and other uses, and use the lower 128 for your LAN (with a netmask of /25, or

As you will see, Chapter 19, "Configuring Workstations," contains more information on setting up workstations to connect to your server.

Running a FAX Server

In a small office or home office, you might not want to maintain separate phone lines for incoming data and fax connections. One solution is to use Linux itself as a fax server.

The tool to use is called mgetty+sendfax. As the name implies, this package actually consists of two parts: mgetty is a smart version of the getty program specifically designed to work with FAX modems, and sendfax is a fax-processing module.

Configuring mgetty isn't always easy. The package is usually distributed in source form, and you need to make adjustments to parameters in a C language source file and recompile the package before it can be used. It's worth the effort, however, if you use a modem extensively for dial-in purposes.

One of the features of mgetty is its capability to call an external program after a fax is received. Utility programs are also available that convert raw group 3 fax files into a more recognizable format, such as TIFF. Using a combination of these tools and features, it is possible to have mgetty invoke a simple shell script that, in turn, creates a mail message with a properly formatted multipage TIFF attachment. Indeed, newer mgetty distributions already come with a sample implementation of this capability.

Connecting the Test System

To demonstrate these principles in practice, I have set up my test system to connect to a "service provider"--a regular Linux system in my home office that accepts dial-in data calls.

My goal is to configure my system to connect on demand, and disconnect when idle, so as to allow incoming calls.

Dial-up Instructions

The "service provider" gave the following instructions for establishing a PPP connection:

1. Dial the server.
2. Connect as usual, typing your user ID and password when prompted.
3. Start the PPP daemon on the server by sending it the following command line:
exec /usr/sbin/pppd passive silent modem crtscts
4. Start your local copy of the PPP daemon.

I was told that my local IP address will be, and my gateway is I can also get name service from this system if I need to, and it runs a mail server as well. My user ID on the remote system is vttoth, and my password is SECRET.

Testing the Login Procedure

Before fiddling with PPP, I wanted to test whether my password worked. I also needed to see what responses I got from the system so that I could build a properly functioning chat script.

Using minicom, I dialed the number provided and logged on. Here is a transcript of my session:

CONNECT 28800/ARQ/V34/LAPM/V42BIS                                              
You have reached a private computer system. Calls to this system are logged    
using calling party identification (caller ID). Unauthorized calls violate     
my privacy, not to mention the law! If you have not been specifically          
authorized by me to access this system, now would be a great time to           
terminate your connection.
Welcome to Linux 2.0.30.                                                        
vtt1!login: vttoth                                                              
Last login: Thu Feb 25 04:12:49 on ttyS0                                        
Linux 2.0.30.                                                                   
Liar, n.:                                                                       
        A lawyer with a roving commission.                                      
                -- Ambrose Bierce, "The Devil's Dictionary"                     
vtt1:~$ exit

Running pppd

Having assured myself that I can log on to the provider's system, I now need to build a chat script that defines the conversation for login. I named the file /etc/; its contents are based on the transcript of my test session and the instructions of my provider:

"" ATDT5551212 CONNECT "" "ogin:" vttoth "assword:" SECRET "vtt1:~$" 
"exec /usr/sbin/pppd passive silent modem crtscts"

It is now time to test fire PPP. As root, I invoked PPP using the following command line on my local machine. (Don't be confused by the fact that we invoke use of the pppd command on both my local machine, which does the dialing, and the server that accepts incoming calls):

/usr/sbin/pppd -d ttyS1 38400 connect '/usr/sbin/chat -f /etc/' \
modem crtscts lock defaultroute

The result? It worked! I heard the modem dial, and after a few seconds, my system was connected to the Internet. I could verify this a number of ways.

First, I looked at the file /var/log/messages. After invoking PPP, it contained messages similar to the following:

Feb 25 04:25:31 host pppd[18539]: pppd 2.2.0 started by root, uid 0
Feb 25 04:26:01 host pppd[18539]: Serial connection established.
Feb 25 04:26:02 host pppd[18539]: Using interface ppp0
Feb 25 04:26:02 host pppd[18539]: Connect: ppp0 <--> /dev/ttyS1
Feb 25 04:26:03 host pppd[18539]: local  IP address
Feb 25 04:26:03 host pppd[18539]: remote IP address

Next, I typed /sbin/ifconfig. If the PPP interface is functioning, this command shows an entry like the following:

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:  P-t-P:  Mask:
          UP POINTOPOINT RUNNING  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0
          TX packets:6 errors:0 dropped:0 overruns:0

Then there is the routing table; typing /sbin/route showed the newly established default route:

# /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface     *      UH    0      0        0 ppp0     *        U     0      0       28 eth0       *            U     0      0       12 lo
default         UG    0      0        1 ppp0

But most importantly, I was now able to use the ping and traceroute commands to reach remote destinations. For instance

traceroute to (, 30 hops max, 40 byte packets
 1 (  164.715 ms  187.385 ms  169.697 ms
 2 (  139.576 ms  187.577 ms  149.699 ms
 3 (  169.497 ms  198.209 ms  169.679 ms
 4 (  189.530 ms  168.225 ms  189.68
1 ms
 5 (  2
19.522 ms  207.993 ms  189.675 ms
 6  224.ATM10-0-0.GW1.CHI6.Alter.Net (  219.519 ms  218.574 m
s  209.684 ms
 7  111.ATM2-0.XR2.CHI6.ALTER.NET (  229.518 ms  208.602 ms
  209.684 ms
 8  190.ATM8-0-0.GW2.IND1.ALTER.NET (  239.524 ms  208.631 
ms  219.674 ms
 9 (  219.527 ms  248.690 ms 
 219.650 ms
10 (  219.534 ms  218.615 ms  219.66
1 ms
11 (  219.541 ms  219.840 ms  218.672 m

Running diald

Having proven that I can run pppd manually, all I needed to do now was to automate the process using diald.

First, diald needed a configuration file. This file is normally called /etc/diald.conf. One of the simplest diald configurations allows the link to come alive when there is traffic, and it shuts down the link after some time of inactivity. Here is a diald configuration file that accomplishes this:

accept any 300 any

Not a difficult one, is it? In human language, this line simply tells diald to accept any kind of a packet as a trigger to activate the link or keep an inactive link alive. The connection will only be terminated if no packets are sent or received for five minutes.

The problem with this script is that it's a bit too simplistic; with many ISPs you will find that with a script like this, the link stays alive all the time. The reason is that even on an otherwise idle link, routing packets are transmitted occasionally. You can prevent these types of packets from activating the link by using a diald configuration file as follows:

ignore udp udp.dest=udp.route
ignore udp udp.source=udp.route
accept any 300 any

Next, diald itself had to be started. I created a small script file named rc.diald that contained the following:

/usr/sbin/diald /dev/ttyS1 -m ppp connect '/usr/sbin/chat 3f
/etc/' modem crtscts lock defaultroute \
local remote

This script can be invoked from the command line, or it can be integrated into /etc/rc.d to ensure that diald is activated every time the system is booted. Don't be surprised if a newly booted system dials right away; the culprit is probably your name server as it initializes itself. Depending on what service applications you run, it may occur at other times as well that a seemingly idle system suddenly dials and activates the connection.

To make diald start every time the system is booted, I created the file /etc/rc.d/init.d/diald with the following content:

. /etc/sysconfig/network
case "$1" in
  [ -x $DAEMON ] || exit 0
  [ ${NETWORKING} != "no" ] || exit 0
  echo "Startind $NAME"
  if [ -f /etc/diald.conf ]; then
    $DAEMON /dev/ttyS1 -m ppp connect '/usr/sbin/chat -f \
    /etc/' modem crtscts lock defaultroute local \ remote
  [ -f $PIDF ] || exit 1
  echo "Stopping $NAME"
  kill ´cat $PIDF´
exit 0

This is essentially a somewhat modified version of the standard Caldera OpenLinux startup scripts. The name /etc/rc.d/init.d/diald is already known to the Caldera OpenLinux startup process, so creating this file (and ensuring that it has execute permissions!) is sufficient.

After I installed and tested diald, I had a system that provided seamless support for outgoing and incoming IP connections over a single modem line.

Using External Routers

The preceding sections explained how you can use a Linux machine with a built-in modem to connect to the Internet. The instructions also apply if your built-in modem is actually an ISDN device that acts like a modem. But what if you are using an external ISDN or higher speed router?

It turns out that (at least inasmuch as the Linux box is concerned) an external router greatly simplifies things. You no longer need to worry about modem configurations, auto-dialer daemons, and such. If your router is properly configured, you just need to set the default route on your Linux system to point to the router.

In this case, the routing function and other server functions are no longer performed by the same box. Client workstations on your network will use the external router for IP data traffic, but they will continue to use your Linux machine as the mail server, for instance. (See Figure 7.3.)

FIGURE 7.3 Using an external router.

The topic of using external routers is explored in more detail in Chapter 12, "External Routers."


The steps you need to take to successfully establish an Internet connection include finding the right ISP, establishing the connection using PPP, and setting up routing.

In order to choose the best ISP, you need to know your needs--the speed of the connection you want to use, whether it is a dedicated connection, whether you need IP addresses for your network, and so on.

To establish the connection, you need to first set up your modem. Linux supports modems on serial ports by default, so you can verify whether your modem is working properly by using a telecommunication program such as minicom.

With the modem up and running, you need to configure PPP. The pppd daemon uses another program, chat, to execute simple connection scripts. The connection script you use should reflect the logon instructions you received from your ISP.

To ensure that the PPP connection is activated (and optionally terminated) automatically based on usage, you can utilize the diald daemon. This program monitors IP traffic in the background, and establishes the PPP connection as and when needed, based on the rules stored in its configuration file.

You can also use a Linux server in conjunction with an external router. In this case, the Linux server will continue to perform many server functions (such as, mail and name service) while the router will take over IP forwarding and, optionally, firewall gateway functions.

Manual Pages

For additional information on topics discussed in this chapter, please refer to the following manual pages.

man chat

man getty

man gettydefs

man inittab

man minicom

man pppd

man setserial

man 7 signal


© Copyright 1999, Macmillan Computer Publishing. All rights reserved.