I've been using a little tool call diald for some time now, so you may have heard me speak of it before. Unfortunately, DSL and cable modems are still not practical for me in my location yet. Hopefully that will change soon. But until it does, I'll use diald to manage my upstream network connection to my ISP.
Yes, there are dozens of spiffy tools that make raising and lowering your network connection as simple as pushing a button on your desktop. But, sometimes you want the network connection to be managed intelligently when you aren't at the keyboard. Diald does this wonderfully.
Normally, when your ppp0 link to your ISP is down, network services that try to access the Net get an error message that says something like ``Network unreachable''. Diald replaces the default route with one to a mock device (a proxy interface) usually called sl0. This SLIP interface always stays up while diald is running. Your network services think they are connected to the outside because diald fools them into thinking sl0 is really the door to the Internet. But sl0 is really the door to the door to the Internet on your system. When someone tries to get out to the Internet, they don't get an error message, they simply get a delay while diald, who has detected that someone wants to get out to the Net (because they used the sl0 interface), then brings up the link to the ISP (or peer network). Aside from a small delay, all your network services (and local network users) believe they have a dedicated link to the Internet (or peer network). And you didn't even have to bring up the link yourself.
After you download diald from its homepage (http://diald.sourceforge.net) and install it according to the instructions it provides, you must configure it, and this is where people sometimes stumble.
Diald configuration consists of three steps:
Connect Script. Perhaps the hardest part is getting a working chatscript to your ISP. There are various HOWTOs in the Linux documenation project that cover how to create a basic working chat script. There are also many mailing lists, IRC chatrooms, and newsgroups where you can get help. Since this subtopic (creating a working chatscript for your PPP connection) is larger than I can fit into this article, I'll have to assume you have managed to get a working chatscript on your own somehow. But at least I can pass along a few tips for making those scripts work with diald.
First, be sure that all your debugging switches in your configuration files are set for maximum verbosity. You want the program to tell you as much as possible about where and why it's breaking.
Normally your diald connection scripts go into /etc/diald. But you can specify any connect script in your /etc/diald/diald.options file. So if you find that you aren't connecting with your /etc/diald/ip-up script, then use another script in your diald.options file. See if you get any further. For example, some Linux distributions give you a tool or a script to configure your ppp facility. Point to that finished script from /etc/diald/diald.options and see if you can at least log in.
You'll want to troubleshoot by checking /var/log/messages, /var/log/diald.log, and /var/log/ppp.log, or similar log names in your Linux distribution. The first part of the script initializes the modem. If that succeeds, you should see ``Dialing System.'' If that succeeds, you should see ``Connected'' or if not, you'll see one of 6 error messages. The next portion of the script does the logging in, and if you get that far, you should see ``Logging in'' in your /var/log/messages. This is where most people get hung up. If the log in fails, you should see something like ``Failed to log in'' in your /var/log/messages. Sometimes people forget to enter their password or username correctly, or they don't tell the chatscript what to expect, or there's another carriage return needed somewhere. You'll need to work this out through experimentation, and perhaps by dialing in by hand with Minicom or the like. That way you know exactly what the sequence is to start a PPP session. If all goes well, however, and you do log in, the chat script will start the PPP daemon.
The basic wisdom here is don't try to use diald until you're comfortable writing and debugging chat scripts!
Basic Diald Config. Basically, your diald connection needs will fall into one of the following categories:
These configurations are all done in the diald.options file. There are sample configurations in /usr/doc/diald/examples, and there are even some more for special circumstances under /usr/doc/diald/examples/contrib. You'll want to look at the man page for diald-examples (man 5 diald-examples). The instance of connecting two remote segments of a private network is covered there. If you're constructing a configuration that doesn't fall into one of the above scenarios, subscribe to the diald mailing list at linux-diald@vger.rutgers.edu (put subscribe linux-diald in the body of the message and send to majordomo@vger.rutgers.edu). Also, see http://diald.sourceforge.net/support.html.
Later versions of diald now allow you to use the dialback option in the default connect script (/etc/diald/connect). You set the variables in the script while you're preparing your chat sequence, and when you choose other options such as AUTHENTIFY and DEBUG, you can also set CALLBACK. When you do, diald will connect with the remote server, authenticate itself, then hangup and wait for the remote server to dial back and then start the PPP session. This can be useful for a private network configuration.
Lastly, the /etc/diald/diald.options file is a great place to give your PPP daemon options under which diald should run. Options such as ``debug'', ``noauth'', ``noipdefault'', and ``ipcp-accept-remote'' should get you started.
Fine Tuning Rules. I'll have to write another article about filtering rules alone, because there's quite a bit to it. First, there are two relevant files--/etc/diald/diald.defs and /etc/diald/standard.filter. Together, these files tell diald whether the network connection should be up or down based on the type of packet traffic.
Thankfully, you don't have to build these files from scratch. So you'll have a working diald even if you don't touch anything. Problem is, you'll probably be making your diald connection more often and for longer than your ISP likes using the default rulesets.
/etc/diald/diald.defs contains ``protocol rules'' and ``var rules''
(variable definitions). Protocol rules specify which packets will be
found on the link, and variable definitions specify each part of every
type of packet. For example, you'll see something like
prule tcp tcp 9:12:13:14:15:16:17:18:19:+0:+1:+2:+3:9:9:9 in your
diald.defs file. This protocol rule simply says there is a protocol
called tcp with the following packet header construction (specified by
the colon-separated long number).
You'll also see something like
var ip.ihl 0(24)&0xf and similar statements. These specify a
packet-type.packet-field combination and its description. In this case,
``ip.ihl'' means IP protocol and its header length. tcp.source and
tcp.dest would mean the source and destination ports for TCP packets.
And so on.
/etc/diald/standard.filter contains the rules on whether diald should accept or ignore these packet types. For example,
ignore tcp tcp.dest=tcp.domain and
ignore tcp tcp.source=tcp.domain
will prevent named transfers from holding the link up. Likewise,
accept tcp 120 tcp.dest=tcp.www and
accept tcp 120 tcp.source=tcp.www
will make http transfers hold the link up for 120 seconds (2 minutes). (Note, ``www'' must be defined in your /etc/services file.)
The standard filter includes rules for TCP, UDP, and ICMP packets, plus a general catchall rule at the end. You can further refine your rules using ``restrict'' and ``or-restrict'' rules together with ``up'' and ``down'' commands. These can apply different filter rulesets to different time periods, and they can tell diald when to be connected and when not to.
Diald Tools. There are a few more tools for diald you should know about. Some of them are
Diald is a small tool, but it's worth its weight in platinum. Once you get comfortable with it, you'll probably be so thankful that you'll send Eric Schenk a ``thank you'' email for ever coming up with it in the first place.