![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
I received two very similar articles this month: this one and one from Mark Nielsen. I received this one first. Mark's is specific to Red Hat 5.0 and can be found at http://linux.med.ohio-state.edu/nielsen/NetHome.html.
Well, this article covers a couple of topics that you've probably seen discussed before in Linux Gazette and/or Linux Journal. Let's say you have 2 or more computers, maybe in an office, maybe at home, and you want to have one of them be the "gateway" for the other(s). If your ISP charges by the minute (or in 5/10/15 minute increments), which many of them do for corporate accounts, then you don't want to spend excessive amounts of time on the line to your ISP. You also don't want to risk forgetting that you are connected and running up a bill while doing nothing! So what you want is a way to get your local network onto and off of the Internet with ease, and with a minimum of extraneous cost. This includes demand-dialing, IP forwarding, IP Masquerading, PPP configuration, and some basics of networking. Sounds like a lot (and believe me, it can be!), but it's not so bad when you find out that, for the most part, you don't necessarily need all the power and flexibility that the packages involved in this setup have.
Please note that while I will be detailing how to set up your Internet gateway in Linux, that does not imply that your entire network needs to be running Linux. You can have one Linux box acting as the gateway, while the rest of the network is a mix of other platforms. You can have any kind of hardware and software on the network, provided that the systems have a TCP/IP stack. Any mix of DOS, Mac, Win95, or unix workstation can be applied to a network configured in this way.
This kind of arrangement is extremely useful for a number of reasons. If WWW browsers are going to be used heavily, this kind of network is ideal. WWW browsers open transient TCP connections for operation, which download chunks of information in spurts, usually not remaining connected for more than a few seconds. While someone reads a web page, the browser generates no (or very little) network traffic, thus leaving the connection idle, and allowing someone else to share the unused bandwidth to full potential. Another reason for installing this kind of arrangement is so that users don't tie up valuable phone lines for extended periods. Recently, I installed a similar arrangement for a small company whose employees were frequently on the Internet from their PC's, each using their own phone line at their desk. Of the few and costly phone lines they had, usually half of them were doing dial-up connections, while the other half could handle voice calls. By the arrangement that I prescribe here, they limited it to one phone line, and everybody was able to access the Internet while using the phone line at their desk for voice.
To describe what I've done here, I'm working from the reference frame of having installed a fresh copy of Red Hat 4.2, with the option of installing everything set. From what I've seen, 5.0 isn't incredibly different (for this stuff, anyway), and I'll also be pointing out the differences between setting this up on Red Hat and setting this up on Slackware 3.3.
First and foremost, I would recommend some other documents for your perusal before engaging in setting up a working LAN. These would be:
I will be using the term "Linux gateway" or "gateway" to denote the machine on your network which will be running Linux and actually have the modem and will be performing the connections to the outside world for your network.
Networks for small offices or within a home are generally not in registered domains. If you are setting up a connection for an office which is in a registered domain with an IP address which is part of the Internet (ie, not one of the reserved network numbers for private use), then you will need to configure your network according to that registered domain and IP address block which you have been allocated by InterNIC. If you don't know what I'm talking about, then you want to use one of the "reserved" network numbers that are set aside for private usage. The network number which I will use will be "192.168.1.0", which I have configured for my home usage. Because it's reserved, I know that all my packets will not conflict with anyone on the Internet, since all packets destined for reserved addresses are dropped by your ISP's routers, and the main backbone routers on the Internet.
Note that the steps I describe here are often done in parallel with the previous section on "Have a Working Network". Once you've selected a reserved IP address block for your network, you need to configure your hardware to be recognized and give the appropriate parameters to the software. I recommend setting the gateway's address to the ".1" node number of your network. It's not a law, but it's commonly accepted and easy to remember. For example, if you are using 192.168.1.0 as your network, then 192.168.1.1 will be your Linux gateway. Then have the other systems on the network numbered as 192.168.1.2 through 192.168.1.254. Some administrators like to have their nameserver for the LAN set up as ".254", but if you only have a few machines on your network, you're not likely to need or want a nameserver.
Selecting a domain name doesn't deserve a huge amount of thought. It's just a matter of coming up with something that is easy to remember, describes your network, and will not conflict with any registered domain names. The extensions of ".com", ".org", and ".edu", as well as country abbreviations (".de", ".uk", ".au", etc.) are off-limits. Just don't use anything that looks like a typical address, and you'll be ok. For example, my local network at home is the domain of "kunz.home". There's no domain out there belonging to ".home", so it's OK. Or if you want to set up an office network for "ACME Inc.", then you might try "acme.office" as your domain name.
The network parameters can be set up in Linux either while performing the initial installation or after the installation has been done. If you decide that you would like to have your gateway named "linux-gw", and that you want your domain to be "smith.home", you will not have any conflicts with names outside of your network. If you are using 192.168.1.0 as your network number, then the parameters for networking should look like this:
Also, notice that it's important to leave the default gateway empty! The routing tables will be modified by diald, which will be discussed later.
On "linux-gw", you should make/edit the /etc/hosts file. It should contain the IP addresses and names of all the machines on the network. Let's say you will have 4 machines on the network besides the Linux gateway. You might, conceivably, have an /etc/hosts file that looks something like this:
127.0.0.1 localhost localhost.localdomain 192.168.1.1 linux-gw.smith.home linux-gw 192.168.1.2 winchester.smith.home winchester 192.168.1.3 ruger.smith.home ruger 192.168.1.4 browning.smith.home browning 192.168.1.5 mossberg.smith.home mossbergBy doing this, the Linux gateway knows the names of all the machines on the network. This should also be done on any unix workstations or other Linux machines you have on the network. On Slackware installations, you'll need to edit this by hand. On Red Hat, you can use the "netcfg" program under X to modify the "Hosts" entry.
On each of the other machines in the network, you will need to configure their parameters as follows. Be sure not to duplicate IP addresses between different machines! The following sample entry is for a client on the "smith.home" network named "winchester".
If you are configuring a Slackware Linux machine as your gateway after installation, the appropriate way to change the network parameters is to run the program "netconfig" as root. You will be prompted for the network parameters one at a time, and should follow the "linux-gw" listing above. Under Red Hat, you should run the "netcfg" program from X while root. This provides a graphical tool for doing the same thing. Running "control-panel" as root in Red Hat provides an X front-end to many of the administrative tasks, including networking.
By the time you get this far, you should have a working network, where you can telnet from any of the machines on your network into the Linux gateway.
The package that we will be using for performing the automatic dialling is "diald". This assumes that you have a modem which Linux is already aware of. If not, you need to consult your installation documentation and the incredibly useful Linux Resources page
Once you can verify that your modem is working ok and is recognized by Linux correctly, we can configure diald to do the work for us. As a note, I would like to say that I've had the least problems with external modems and with non-PnP modems. These days, it's hard (if possible at all) to find a non-PnP internal modem. If you absolutely have to use a PnP modem, then I recommend getting the isapnptools package for initializing PnP configuration.
First, you need to obtain and install diald. If not already installed on your system, it's possible to obtain the code from Sunsite. If you have Red Hat, you can find the binary distribution in RPM format on your Red Hat 4.2 CDROM. It is located in /[mountpoint]/RHSCont/i386/diald-0.16-3.i386.rpm. The file diald-config-0.1-1.i386.rpm is found in the same directory, and I recommend you install it, since it contains some sample configurations that may be useful to you. Under Red Hat 5.0, I was unable to find it on the 2-CDROM distribution set from Red Hat, so the latest version of diald should be downloaded from Sunsite. The same goes for Slackware. Download the pacakge and follow the build instructions included. [LG HTML note: if you find those links are broken by the time you read this, you should be able to browse http://www.sunsite.unc.edu/pub/Linux/system/network/serial/ to find the current version of diald]
Once you have diald installed, we need to install pppd. This comes up in both Slackware and Red Hat 4.2/5.0 as packages that are selected for installation if you install everything. If it is not installed, it can be found on your Red Hat 4.2 CD in /[mountpoint]/RedHat/RPMS/ppp-2.2.0f-3.i386.rpm. If you have RedHat 5.0, you will find it on the first CD of the set, in /[mountpoint]/RedHat/RPMS/ppp-2.2.0f-5.i386.rpm. Slackware contains the ppp.tgz package at or around floppy N3 or /[mountpoint]/slakware/n3. If you don't have it installed on your Linux gateway already, you may need to download the source for it from Sunsite. Basically, just follow the build instructions and install it via the Makefile.
Now you have diald and pppd installed, but you may not have any support for IP Masquerading, which is an absolute MUST for this kind of networking scheme. If you are using a stock Red Hat 5.0 kernel, you will be fine, as just about everything is compiled as a module. IP forwarding will be provided on-demand by kernel module loader, as long as you have modified /etc/sysconfig/network (see "Configuring IP Forwarding Firewall", below). If you're using a stock kernel that came with Slackware, you probably don't have support for the IP Masquerading ready. If you installed everything as I recommend in the beginning, you'll have the kernel sources already on your Linux gateway. But if not, you can download the source code for kernel 2.0.33 from Sunsite. Be patient! It's a 6M file!
Just untar it in your /usr/src directory, and the do the following:
The next step along the path to having a Linux machine that can act as a gateway to the Internet is to configure IP forwarding. IP forwarding can be a very complicated and involved thing, however, to act as a simple gateway and firewall to the Internet, all we need to do is configure the forwarding rules so that packets of all types found on the ethernet interface are copied onto ppp interface.
Please be aware that you should be fully informed of the security concerns of this. I recommend that you read some materials on security, keep a copy of SATAN handy, and consult some security experts if you worry about security. If you have a dial-up service to a local ISP, there is a lower probability that you will be hacked on than if you are using a university as your ISP. College kids aren't necessarily malicious, but they can be deemed a security risk, as they are usually more "inquisitive" than the typical Windoze 95 user at home who happens to be a customer of your local ISP. Don't take me as Gospel Truth, check into it for yourself and find out the issues about security if it is something you want to know about.
The first thing to have is the ipfwadm package installed on your system. If you have it already installed and your kernel has been compiled in the previous step to support packet forwarding, then you're set, and you can move onto the actual configuration of the firewall. If you are using Red Hat 4.2, the package can be found at /[mountpoint]/RedHat/RPMS/ipfwadm-2.3.0-2.i386.rpm. If you are using Red Hat 5.0, you should find it on the first CD of the set, in /[mountpoint]/RedHat/RPMS/ipfwadm-2.3.0-5.i386.rpm. If you're using Red Hat, you will note that you'll also have to modify the file /etc/sysconfig/network, making the line containing "FORWARD_IPV4" to say "FOWARD_IPV4=true". For Slackware, you should find installed in the base TCP/IP package (N6, "tcpip.tgz"), so if you have TCP/IP networking installed, it should already be there. If you need to download it, the source can be found at its home page.
Once you have the package installed, you need to know how to use it! Depending on how secure you would like it to be, you can make a few changes to what I have here. What you want to do is flush the table of all previous firewall forwarding entries, set a default policy for either accepting or rejecting packets, and then tell it how to forward packets between different interfaces. For example, the following script will flush all forwarding rules, set the default policy to "accept" packets, and will forward packets between all of the available interfaces:
#!/bin/sh ipfwadm -F -f ipfwadm -F -p accept ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0We can view the IP forwarding rules by issuing the command "ipfwadm -F -l -n", which will list the rules numerically. If we do that, we will get output looking like this:
IP firewall forward rules, default policy: accept type prot source destination ports acc/m all 192.168.1.0/24 0.0.0.0/0 n/aThis tells us that any packets going from our network to anything other than just our network will be forwarded between all of the interfaces. Now, if we specify an additional "-e" option to the previous command, we get extended output of the forwarding rules. This is to our advantage, but you should have a 132 character wide screen when you run it. Here is a sample output:
IP firewall forward rules, default policy: accept
pkts bytes type prot opt tosa tosx ifname ifaddress source
destination ports
113 9452 acc/m all ---- 0xFF 0x00 any any
192.168.1.0/24 anywhere n/a
Thus, we can see that even though IP forwarding can be incredibly complicated and selective, we can write a simple script which will do all the work for us and establish a forwarding firewall.
If you read the manpage for ipfwadm, you will find that the -W option may be used to specified. For simple situations and a simple network in a generally trusted environment, the -W option isn't necessary, because you are probably interested in having all interfaces able to see all packets. However, if you are interested in keeping certain interfaces from receiving packets, you may use the -W option for security.
The first thing we want to do is configure pppd, because it's often easier to test out than diald. To do this, we want to create a chat script, which will dialog with the ISP, and establish the connection. You will want to read the man page for "chat" first, but here is an example of a chat script I use:
REPORT CONNECT ABORT BUSY '' atdt5551212 CONNECT '' : tkunz : PaSsWoRd action ppp>From the manpage:
This sequence will expect nothing; and then send the
string ATDT5551212 to dial the telephone. The expected
string is CONNECT. If the string CONNECT is received the
remainder of the script is executed. In addition the pro-
gram will write to the expect-file the string "CONNECT"
plus any characters which follow it such as the connection
rate.
First, the script will report what the modem returns after "CONNECT" into the report file, to be analyzed later, in order to diagnose what could have gone wrong with the dial-up. The ABORT string means to abort the script should it see the "BUSY" string returned by the modem. After that, this script will diald "555-1212" as the phone number, and wait for the CONNECT message to come back from the remote end. It will then wait for a colon (":"), and reply with "tkunz". It will wait for another color (":"), and reply with "PaSsWoRd". When the string "action" is received from the remote end, it replies with "ppp" and the chat script terminates. Chat will then pass control back to the program that called it. But here's another script that will work fine, provided we don't need the "REPORT" error checking, and we don't ever expect to get a busy signal:
atz OK atdt5551212 CONNECT name: tkunz word: PaSsWoRd action: pppThis one will do the same thing, only it will initialize the modem to the default setting by issuing "atz" first, and instead of expecting only a colon, it waits for "name:" and "word:" to be received before issuing "tkunz" and "PaSsWoRd", respectively, to the remote end.
These simple one-line scripts like the above examples can be used with chat to automate the login procedure with your ISP.
pppd uses chat to establish a connection, and then when chat terminates, pppd continues to dialog with the remote end, determining its local and remote IP addresses, and then pppd follows the other command line options to secure a reliable connection.
To give you an idea of what a set of scripts would look like that starts a PPP connection, here is a sample of something I use to manually bring up a PPP connection to my ISP.
The contents of a file in my own directory, named "startppp":
#!/bin/sh /usr/sbin/pppd /dev/cua3 115200 connect 'chat -f /etc/ppp/chatscript' defaultroute crtscts proxyarp passiveThis tells pppd to use my modem, located on /dev/cua3 (COM4 in DOS), at a speed of 115200, which my 33.6kbps modem can handle. The "connect" parameter says to use the next quoted string as the command-line which will connect pppd to the remote host.
The option "defaultroute" tells pppd to modify the routing tables so that this connection is added as a default route to the rest of the world. The "crtscts" option tells pppd to use hardware flow control for the modem, a MUST for modems faster than about 9600 baud. "proxyarp" says to add an ARP entry for the local and remote systems to the ARP table. The "passive" option tells pppd to be patient about receiving LCP packets from the ISP. If pppd does not immediately receive an LCP packet from the remote end, it drops carrier. I have personally found this to be the "magic ingredient" to getting pppd working with several different ISP's. The contents of the file /etc/ppp/chatscript, used by "chat" in "startppp":
REPORT CONNECT ABORT BUSY '' atdt5551212 CONNECT '' : tkunz : PaSsWoRd action pppSubstitute in your login name, password, and the command which starts ppp (if any) for the appropriate fields in the /etc/ppp/chatscript, and see what happens. You may need to contact your ISP if you have never used pppd in Linux before to establish a PPP connection, to determine if there are specific options necessary to make and sustain a PPP connection. You can try the above script and then watch the /var/log/messages file to see what happens. You might need to modify your /etc/syslog.conf file to get the messages printed to the right location if you use Red Hat. I prefer a slightly modified Slackware /etc/syslog.conf, which is shown here:
# /etc/syslog.conf # Very Important! All whitespace are TABs, not " " (space) characters! # *.=info;*.=notice /var/log/messages *.=debug /var/log/debug *.warn /var/log/syslogAfter making this your syslog.conf file, you can do a "touch" on /var/log/messages, /var/log/debug, and /var/log/syslog, restart syslogd and watch the messages appear. Occaisonally, I've noticed strangeness with syslogd not wanting to give up the previous configuration, so you might find a reboot rather than just a restart of syslogd is in order.
Once you have syslogd logging the right level of messages to the locations mentioned above, you can watch the progress of pppd from one window or virtual console while you execute "startppp" from another. By watching /var/log/messages (and possibly by watching the modem lights if you have an external modem), you can determine if chat succeeded or failed, or if the right options were specified to pppd. As root, the command "tail -f /var/log/messages" will enable you to see messages as they are dumped into /var/log/messages.
By experimentation, you should be able to get a PPP connection started by using these scripts and commands. Again, I mention that you might have to call your ISP to find out if any special LCP or IPCP options need to be set.
By this time, you should be able to regularly initiate a PPP link to your ISP by executing "startppp", and you should be able to use web browsers and the like to get onto the Internet from the other machines on the network once you have the IP forwarding rules installed. The next peice of the puzzle is diald. diald is designed as a demand-dialer, meaning that when it senses that you want to get from the local network out onto the Internet, it dials your ISP and sets up the connection for you.
The first thing to realize is that we are going to have to change the way we think about pppd and chat for the moment. Before, in our previous script in the section about configuring pppd, we had pppd start up, then issue the "connect" command. After that occurred, pppd would run according to the options we put on the command line. In diald, we have to recognize that diald will be handling many of the details that pppd handled before. These details include the dialing script and options that would normally be passed to pppd. diald will be responsible for implementing these things now, not pppd.
What diald does is it creates a "virtual" interface, sl0, which is a slip interface to nowhere. We will have it assign the IP address of 192.168.0.1 to sl0, and an IP address of 192.168.0.2 to the remote end (basically nothing!) of the fake slip interface. Then it creates a route so that traffic not intended for the local network will go into sl0. When diald finds packets being copied onto sl0, it realizes that those packets should go into the Internat, and starts the dialing process. In order to make our particular network arrangement work, we have to set up the IP forwarding to be promiscuous, in a sense, in that it forwards between all interfaces, including sl0. Thus, packets which are generated by one of the other machines on the network will go into the Linux gateway, the IP forwarding mechanism will copy them onto the sl0 interface if they are not destined for only the local network, and then diald will take over, starting the dialing process and pppd to bring up the link.
The manpage of diald-examples should have been installed on your system when you installed it. If you read that, you will probably find your own situation there in the manpage, however, most of you will probably find that it corresponds with the section named "A Leaf Node with Dynamic Local Address using PPP". The following comes directly from the diald-examples(5) manpage for this situation:
mode ppp
connect /etc/diald/connect
device /dev/ttyS1
speed 115200
modem
lock
crtscts
local 192.168.0.1
remote 192.168.0.2
dynamic
defaultroute
include /usr/lib/diald/standard.filter
To start off with, you should have the above as your initial /etc/diald.conf file. We will add options to it later. At this point, please understand that diald has to know exactly where to find the external programs of route, ifconfig, and pppd. This article assumes that you have installed pppd, ifconfig, and route into their default locations, which are:
/usr/sbin/pppd
/sbin/ifconfig
/sbin/route
If for some reason you do not have them installed in the above locations, please make links or move them to the appropriate locations.
Now we come to the part where we modify that initial /etc/diald.conf file. First of all, we have created a working chat script in an earlier part of this article, "Configuring pppd". Using that information, we modify the lines starting with "connect ...", "device ..." and "speed ..." to reflect your configuration. If you followed my directions exactly in "Configuring pppd" and have a 33.6kbps modem on COM4 like I do, then you would get a diald.conf that looks like this:
mode ppp
connect "chat -f /etc/ppp/chatscript"
device /dev/cua3
speed 115200
modem
lock
crtscts
local 192.168.0.1
remote 192.168.0.2
dynamic
defaultroute
include /usr/lib/diald/standard.filter
Note that if you have a 28.8k, 33.6k, or 56k modem, your "speed ..." line will look the same. If you're using a 14.4k, you'll most likely have to use "speed 57600". Also, make sure you use the correct number of the COM port. COM ports in DOS are one higher than the appropriate cua number, since DOS starts numbering from "1" and unix tends to number things starting from "0".
One thing to note about the diald.conf file is the set of options which would normally have been specified to pppd. According to the diald manpage, you must not specify those as direct options to pppd. This is one of those details handled only by diald. In our original "startppp" script, we specified "... defaultroute crtscts proxyarp passive". In our new situation, using diald instead of pppd to manipulate those options, we need to set those here in diald.conf. All but the "passive" option can be specified. Thus, we get a diald.conf that looks like this:
mode ppp
connect "chat -f /etc/ppp/chatscript"
device /dev/cua3
speed 115200
modem
lock
crtscts
local 192.168.0.1
remote 192.168.0.2
dynamic
defaultroute
proxyarp
include /usr/lib/diald/standard.filter
If we need to add the "passive" command to pppd to make it work with your ISP correctly, then we can insert a new line into the above of the form:
pppd-options passive
The above diald.conf should get you started with a working connection to your ISP. If not, you may need to consult your ISP's technical support line to find out what they recommend.
At this point, you should be able to start diald and watch the messages in /var/log/messages appear which it generates upon start-up. After diald starts, you should also be able to send packets from other nodes of your network to the Internet, and then watch as diald automatically dials out and establishes a connection. If not, go back over the previous steps to find out what went wrong.
There are also important variables which are not associated with the link uptime itself, but with the time that different portions of diald take to execute or time-out. For example, if dialing your ISP and passing the username, password and related actions take more than 60 seconds, typically, you will want to add a line to the file that says something like:
connect-timeout 120
Or, if you wish to have diald attempt a redial 10 times before giving up and only wait 15 seconds to clear the modem between dials, you will want to add in the following two lines:
retry-count 10
redial-timeout 15
You may also wish to play with some of the other options that diald has to offer. For example, one option that can be useful is "two-way". This tells diald that if carrier is dropped while in operation, that it will not retry dialing. What good is that? Well, if you have to forcibly terminate the PPP connection to your ISP (killing off pppd manually to free the line, physically pulling the phone line connection, etc.) diald will not try to outsmart you and dial again. If you have a somewhat dedicated line, and you are not concerned about how long you are connected to your ISP, you won't need that option very much, as you'll probably stay connected for longer periods of time.
If you are concerned with accounting for the time that is spent online, then you will want to play with the "accounting-log ..." option. The parameter to "accounting-log" should be the full pathname of a file which will log the times when the link comes up and goes down, and how much data was sent down the wire. But I said I wouldn't spend any time talking about accounting and logging ...
The diald manpage is rich with options, and I would recommend that you read it in parallel with reading this article. Diald is wonderfully configurable, and can meet a wide variety of needs, depending on how complex of an arrangement you wish.
OK! Now you can go to any node of your network, start up {Netscape, IE, Arena, Mosaic, any browser} and get to somewhere out on the rest of the Internet. However, why does it seem like sometimes your Linux gateway almost randomly fires up a connection? What's it doing?
Well, now you need to delve into the particular applications on your network and how they're configured. Two of the big things to check are mail client and web browsers which contain mail clients. If your mail client makes requests for new mail, it will generate a packet which goes to your gateway, and initiates a call. This means that while the Internet connection is down, someone with a mail client up and running somewhere on your local network can unwittingly cause the gateway to establish a connection. This can be annoying and/or costly, both for the typical home user and the corporation. I know that I've accidentally done this to my wife on a number of occaisons, where my gateway attempted to dial out while she was on the phone with someone! (But she's a wonderful, patient, forgiving wife.)
To fix this, what you need to do is to inform your staff (or family) that once they finish with their mail client, they should terminate it immediately. And they should also be informed that they should turn off the automatic mail-fetching for any mail client that they use, especially if you are billed for connection time to your ISP or per minute of call (European countries often bill for even local calls).
Another thing to watch out for is the /etc/resolv.conf on the unix hosts on your network. You must not have any nameservers which are outside of your local network listed in it, or else every application that accepts a hostname will generate packets and cause your gateway to dial out. For this reason, it's wise to keep every hostname your local network needs in /etc/hosts on each unix machine. If your local network is large enough to warrant the effort, you might also set up your own local nameserver to handle the name requests. A local nameserver with its own maps for the local domain, and a caching nameserver for outside requests is probably the most efficient way of handling that. If you are going to be using a local mail agent like sendmail, then you will want to be sure to configure it in such a way that it will not cause the gateway to dial-up the ISP at every instance of outgoing mail. You'll want it spooled until a connection is available, or at a routinely scheduled time when all queued mail will be transmitted out.
Obviously, this document is not going to go into any detail about how to configure the various applications on your network around using a demand-dialed gateway. It is useful, however, to be aware of some of the issues you will face when you add different applications and platforms to your network, and why things may not be going the way you initially supposed they would. If you are faced with a larger network which requires greater upkeep in order to keep it working right, and high bandwidth to the Internet on a regular basis, it may be time to consider investing in faster connections (ISDN, T1, T3, OC3, etc.) and leased lines which better suit your needs. Note that diald can work with ISDN, but in a larger-scale network with higher bandwidth demands, a full-time connection may be the best solution.
Well, it's seems apropriate to say that configuring a small network with demand dialing via diald is a task which can be quite involved, depending on the complexity of your network. But if you have fairly "ordinary" needs, you can follow the above procedures to get a working and reliable demand-dialed connection. Many, at this point, will say "Well, what are 'ordinary needs' anyway?" or "How big of a network will this support?". The answer is subjective, however I can say with reasonable certainty that a network of 2 to 8 machines, each running their own web browsers, mail clients, and the like, will be quite adequate over even a 28.8kbps modem. The connection I get to my local ISP rarely gets past 28.8kbps on my 33.6kbps modem, because of the lines in my area, and often drops down to 21.6kbps or so, yet I still get reasonably quick response from having 2 or 3 machines accessing the Internet simultaneously. If you lust for speed, then you will do well to get a 56kbps modem, and a line to your ISP that can sustain 56kbps (yes, 53k download by FCC law). From my experience, diald will have no trouble with a 56kbps, provided it is either external and connected to a 16550 UART, or if you have built some version of a PnP configuration manager which can reliably configure an internal 56k modem.