Lemur zaprasza
Linux System Administrator's Survival Guide lsg31.htm Setting Up the Dummy Interface Setting Up SLIP Configuring SLIP Using dip Setting Up PPP Setting Up a PPP Account Dialing Out: chat Running ppd Checking Problems PPP Authentication Using DNS for SLIP and PPP Summary Chapter 31 Configuring SLIP and PPP This chapter looks at the configuration and setup required to use either SLIP (Serial Line Internet Protocol) or PPP (Point to Point Protocol) on your Linux system. This follows the general TCP/IP configuration performed in the previous chapter. Both SLIP and PP work over a dialup modem, essentially establishing a normal modem link with a remote system, then invoking either the SLIP or PPP protocols. In many ways, SLIP and PPP are like PLIP interfaces; even though SLIP and PPP use a serial modem port, they are really point-to-point interfaces involving two machines. Unfortunately, SLIP and PPP are more complicated to configure than PLIP. You can do the SLIP and PPP configuration when you are configuring the general TCP/IP files, or you can wait until you need to set them up for SLIP or PPP access. Since not all installations will require SLIP or PPP, you can quite easily wait. However, most Internet service providers prefer SLIP or PPP access from small systems, because they provide fast, efficient transfers. Setting Up the Dummy Interface What's a dummy interface? It's a bit of a trick to give your machine an IP address to work with when it uses only SLIP and PPP interfaces. A dummy interface solves the problem of a stand-alone machine (no network cards connecting it to other machines) whose only valid IP address to which data can be sent is the loopback driver (127.0.0.1). While SLIP and PPP may be used for connecting your machine to the outside world, when the interface is not active you have no internal IP address that applications can use. The problem arises with some applications that require a valid IP address to work. Some word processors and desktop layout tools, for example, require the TCP/IP system to be operational with an IP address for the target machine. The dummy interface essentially sets an IP address for your local machine that is valid as far as TCP/IP is concerned, but doesn't really get used except to fool applications. Creating a dummy interface using the loopback driver is very simple. If your machine has an IP address already assigned for it in the /etc/hosts file, all you need to do is set up the interface and create a route. The following two commands are required: ifconfig lo 127.0.0.1 route add 127.0.0.1 The lo portion of the ifconfig command indicates that the line refers to the loopback driver. This line creates a link to the IP address 127.0.0.1. If you do not have an IP address for the localhost already in the /etc/hosts file, add one before you create the dummy interface. To create the loopback interface, edit the /etc/hosts file so it includes a line like the following: 127.0.0.1 localhost This line sets up your local machine to use the IP address 127.0.0.1 as the localhost interface. You can verify that the loopback interface is working properly after you have used the ifconfig command by using the ifconfig command with the interface name to show statistics: merlin $ ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:2000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 TX packets:12 errors:0 dropped:0 overruns:0 The statistics show that the loopback interface is running, has been assigned the IP address 127.0.0.1, and has the broadcast mask of 255.0.0.0. After you add the loopback driver to the routing table using the route command, you can use the ping command to check that the interface is responding properly: merlin $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.7 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.7 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.7 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=255 time=0.7 ms --- localhost ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.7/0.7/0.8 ms You must interrupt the ping command with a Ctrl+C to stop it. The output above shows that the packets destined for the localhost machine were properly delivered and replies were almost immediate. If you receive output anything like this output, your interface is properly set up. If you receive an unknown host message, your localhost name is not recognized. Check the /etc/hosts file and use ifconfig to verify that the loopback driver is installed properly. Setting Up SLIP SLIP can be used with many dial-up Internet service providers, as well as for networking with other machines. When a modem connection is established, you don't get to see a shell prompt, but SLIP takes over and maintains the session for you. The SLIP driver is usually configured as part of the Linux kernel. The Linux SLIP driver also handles CSLIP, a compressed SLIP version that is available with some implementations. For most Linux systems that use SLIP, a serial port has to be dedicated to the device. This means that a serial port must be specifically configured to use SLIP and cannot be used for any other purpose. The kernel uses a special program called SLIPDISC (SLIP discipline) to control the serial port, and blocks other non-SLIP applications from using it. The Linux SLIP driver is installed into the kernel usually by default, but some versions of Linux require you to rebuild the kernel and answer y to a question about SLIP and CSLIP usage. Once you have the kernel SLIP drivers in place, you can configure the serial port to be used for SLIP. Configuring SLIP The easiest way to dedicate a serial port for SLIP is to use the slattach program. This takes the device name of the serial port as an argument. For example, to dedicate the second serial port (/dev/cua1) to SLIP, you would issue the command: slattach /dev/cua1 & The command is set into background mode by the ampersand. Failure to send to background means the terminal or console the command was issued from is not usable until the process is terminated. You can embed the slattach command in a startup file if you want. Once the attachment has succeeded, the port is set to the first SLIP device /dev/sl0. If you are using more than one serial port for SLIP lines, you need to issue the command for each line. Subsequent SLIP devices (/dev/sl1, /dev/sl2, and so on) will be assigned by slattach. Most versions of Linux will support up to eight SLIP lines. By default, most Linux systems set the SLIP port to use CSLIP. If you want to override this default, use the -p option and the slip name: slattach -p slip /dev/cua1 & You can use modes other than slip and cslip to follow the -p option: slip6 (a six-bit version of SLIP) and adaptive (for adaptive SLIP, which adjusts to whatever is at the other end of the connection). You must make sure that both ends of the connection use the same form of SLIP. For example, you cannot set your device for CSLIP and communicate with another machine running SLIP. If the versions of SLIP don't match, commands such as ping will fail. Once the serial port has been set for SLIP usage, you can configure the network interface using the same procedure used for normal network connections (including the dummy interface set up earlier). The commands used are ifconfig and route. For example, if your machine is called merlin and you are calling arthur, issue the commands: ifconfig sl0 merlin-slip pointopoint arthur route add arthur The ifconfig command above configures the interface merlin-slip (the local address of the SLIP interface) to be a point-to-point connection to arthur. The route command adds the remote machine called arthur to the routing tables. You can also issue another route command to set the default route to arthur as a gateway: route add default gw arthur If you want to use the SLIP port for access to the Internet, it has to have an IP address and an entry in the /etc/hosts file. That gives the SLIP system a valid entry on the Internet. A better approach is to use DNS, but the configuration is more complex (see "Using DNS for SLIP and PPP," below). Once the ifconfig and route commands have been executed, you can test and use your SLIP network. If you decide to remove the SLIP interface in the future, you must remove the routing entry, use ifconfig to take down the SLIP interface, and then kill the slattach process. The first two steps are done with these commands: route del arthur ifconfig sl0 down while the termination of the slattach process must be done by finding the process ID (PID) of slattach (with the ps command), and then issuing a kill command. See Chapter 20, "Processes," for more information on the ps and kill commands. Using dip Many Linux versions include a utility program called dip (Dial-up IP), which helps to automate the preceding steps, as well as provide an interpretive language for the SLIP line. Many versions of dip are currently available, some of which have different capabilities. This section doesn't go into exhaustive detail about dip, primarily because most of its functionality is not used by most users. This section looks at a typical setup file and leaves the rest to the documentation supplied with dip. The dip system uses scripts to control its behavior. The following is a sample dip script to connect to a remote machine with comments (prefaced by a pound sign) to explain each action: # dip script to connect to remote darkstar # begin by setting local interface name and address get $local merlin-slip # now set the remote end name and address get $remote darkstar # now set parameters port cua1 # serial port /dev/cua1 used for SLIP speed 38400 # use 38,400 as the modem speed modem HAYES # set the command set type for the modem # initialize modem reset # reset the modem and port flush # remove any modem responses # dial darkstar and log in dial 5551234 # dial the remote wait CONNECT # wait for the CONNECT message send \r\n\r\n # send a couple of CR/LFs wait ogin: # wait for login prompt send $merlin\n wait word: # wait for password prompt send secret1\n print Connected to the remote # now clean up default # set this link to default mode SLIP # go to SLIP mode The script would be called and executed with a command like this dip script_file where script_file is the name of the file containing the script. You can put lots of extra steps in the script, including multiple levels of error checking, however, since most people find SLIP fairly easy to work with anyway, the dip utility is really for the person who wants to perform extra automated steps. Setting Up PPP PPP is a more talented protocol than SLIP and is preferable for most uses. However, the configuration is a little more complex than SLIP's. Linux divides the PPP functions into two parts, one for the High-Level Data Link Control (HLDC) protocol, which helps define the rules for sending PPP datagrams between the two machines; and one for the PPP daemon, called pppd, which handles the protocol once the HLDC system has established communications parameters. In addition, Linux uses a program called chat, which calls the remote system. As with SLIP, PPP establishes a modem link between the two machines, and then hands over the control of the line to PPP. You, as the user, never get to see a shell prompt or login, because PPP handles it all for you. Both HLDC and pppd are complex utilities with many options available to fine-tune their behavior. Since most of these options will never be used by you, we can safely ignore all but the most important aspects necessary to get a PPP connection up and running properly. Prior to establishing a PPP link, you must have a loopback driver established (see Chapter 30, "Configuring TCP/IP"). You should also have a name resolution system in operation, even if it's the /etc/hosts file or a simple DNS cache-only name server (see "Using DNS for SLIP and PPP," below). Setting Up a PPP Account If you are worried about compromising your system's security, it is best to use PPP with a special user account (for example, one called ppp) for optimum protection and behavior. If you use a standard user login, there is a chance that people calling your system can exploit file permission weaknesses to access parts of the system you don't want them to touch. The use of a dedicated login for PPP is not strictly necessary, and you can easily use PPP from any user account, but for more secure operation, you should consider creating a ppp user. The process is simple. First, you need to add a new user to the /etc/passwd file. You can use whatever script your system normally uses to add new users, or edit the /etc/passwd file yourself. (See Chapter 16, "Users and Logins," for more information about users and /etc/passwd.) A sample /etc/passwd entry for the ppp account (with UID set to 201 and GID set to 51) looks like this: ppp:*:201:51:PPP account:/tmp:/etc/ppp/pppscript In this case, the account is set with no password (so no one can log in to the account) and a home directory of /tmp (since no files are created). The startup program is set to /etc/ppp/pppscript, a file you create with the configuration information in it (you can use any filename, of course). A sample contents for the pppscript file looks like this: #!/bin/sh mesg n stty -echo exec pppd -detach silent modem crtscts The first line forces execution of the script into the Bourne shell. The second command turns off all attempts to write to the ppp account's tty. The stty command is necessary to stop everything the remote sends from being echoed again. Finally, the exec command runs the pppd daemon (which handles all PPP traffic). You will see the pppd daemon and the options later in this section. Dialing Out: chat PPP requires you to establish a modem connection to the remote machine before it can take over and handle the communications. The chat program is the most commonly used of the utilities available to do this. The chat program is popular because it uses a scripting style similar to that used by UUCP (see Chapter 27, "UUCP"). To use chat, you have to assemble a command line that looks almost the same as a UUCP /etc/Systems file entry. For example, to call a remote machine with a Hayes-compatible modem (using the AT command set) at the number 555-1234, use the following command. It is all formatted as a chat script, UUCP style: chat "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1 If you read the UUCP chapter, this code may look familiar. If not, all the entries are in a send-expect format, with what you send to the remote specified after what you receive from it. The chat script always starts with an expect string, which you must set to be empty because the modem won't talk to us without any signal to it. After the empty string, send the ATZ (reset) command, wait for an OK back from the modem, and then send the dial command. Once a CONNECT message is received back from the modem, the login script for the remote machine is executed. Send a blank character, wait for the ogin: (login) prompt, send the login name ppp, wait for word: (password) prompt, and then send your password. After the login is complete, chat terminates but leaves the line open. If you want to see all the activity that goes on with the chat program, you can force all messages to the syslog daemon for future study. The -v option forces the messages to syslog, so the command would be: chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1 If the other end of the connection doesn't answer with a login script as soon as its modem answers, you may have to force a Break command down the line to jog the remote end. This is done the same way as with UUCP: chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin:-BREAK-ogin: ppp word: secret1 Because any user doing a ps -ef command sees the entire command line (with its passwords), this type of chat entry has a security problem. If you are the only user of your system, this isn't a concern, but to save yourself any problems, you can embed the script portion of the command in a file and read the file in to chat. Then the script will not appear on a ps output. To call a file for use with chat, use the -f option: chat -f chat_file The chat_file will contain the string: "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1 The chat script can help you detect common error conditions, such as a line busy or no connection established. The messages from your modem (Hayes uses BUSY and NO CARRIER respectively) are embedded in the chat script with the ABORT option, which enables you to exit from the chat script gracefully if one of these error conditions occurs. To handle these abort conditions, embed the chat keyword ABORT, followed by the message that should trigger an abort, prior to your normal chat script. For example, to modify the chat script above to abort on a BUSY or NO CARRIER message from the modem, the script should look like this: ABORT BUSY ABORT 'NO CARRIER' "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1 You need two ABORT commands because each takes only one argument. The rest of the chat script is as usual. Note the need to put quotation marks around the NO CARRIER message: the space in the middle would confuse the script otherwise. Running ppd To set up a PPP connection, you need to invoke the pppd daemon. If you have a PPP connection already established and your machine is logged into a remote using the ppp account, you can start the pppd daemon. If we assume your local machine is using the device /dev/cua1 for its PPP connection at 38,400 baud, you would start up the pppd daemon with this command: pppd /dev/cua1 38400 crtscts defaultroute This command tells the Linux kernel to switch the interface on /dev/cua1 to PPP, and to establish an IP link to the remote machine. The crtscts option, which is usually used on any PPP connection about 9,600 baud, switches on hardware handshaking. The IP address the local system will use is taken from the local hostname, unless one is specified on the pppd command line (which you will seldom need to do, since the localhost IP address should be correct for the PPP line). If you want to force the local or remote IP addresses to be something other than the machine's default values, you can add the addresses with an option to pppd. The general format is to specify the local IP address, a colon, and then the remote IP address. For example, the option 147.23.43.1:36.23.1.34 when added to the pppd command line, sets the local IP address as 147.23.43.1 and the remote IP address to 36.23.1.34, regardless of that the local values are. If you only want to modify one IP address, leave the other portion blank. The command 147.23.43.1: just sets the local IP address and accepts the remote IP address as whatever the machine sends. Because you need chat to establish the connection in the first place, you can embed the chat command as part of the pppd command if you want. This is best done when reading the contents of the chat script from a file (using the -f option). For example, you could issue the pppd command: pppd connect "chat -f chat_file" /dev/cua1 38400 -detach crtscts modem defaultroute You will notice a few modifications to the pppd command other than the addition of the chat command in quotation marks. The connect command specifies the dialup script that pppd should start with, while the -detach command tells pppd not to detach from the console and not to move to the background. The modem keyword tells pppd to monitor the modem port (in case the line drops prematurely) and hang up the line when the call is finished. The pppd daemon begins setting up the connection parameters with the remote by exchanging IP addresses, and then sets communications values based on transferred information. Once that is done, pppd will set the network layer on your Linux kernel to use the PPP link by setting the interface to /dev/ppp0 (if it's the first PPP link active on the machine). Finally, pppd establishes a kernel routing table entry to point to the machine on the other end of the PPP link. If you want to change the default behavior of the pppd daemon, you can do it through command line options or a control file. The file is a better approach if you want to change the parameters for every connection established using PPP. Before completing the command line, pppd scans a number of possible options files. The more common file is /etc/ppp/options, which usually is used to set global defaults. An example of a /etc/ppp/options file looks like this: # /etc/ppp/options: globabl definitions domain merlin.com auth # force authentication usehostname # use local hostname for authentication lock # use file locking UUCP-style The domain is established with the domain keyname followed by the full domain name (minus the machine name). The next two lines above (auth and usehostname) deal with authentication of the PPP line, preventing unwanted usage and access. We will look at authentication later in this section. The lock keyword tells pppd to use UUCP-style file locking to prevent device clashes. Locking should be used on all PPP systems to prevent problems. Checking Problems The pppd daemon echoes all warnings and error messages to the syslog facility. If you used the -v option with the chat script, chat's messages are also sent to syslog. If you are having trouble with your PPP connections, you can check the syslog for details and try to isolate the problem. Syslog discards incoming error and warning messages, unless an entry in the /etc/syslog.conf file redirects them to another file. To save the messages from pppd and chat, add this line to the /etc/syslog.conf file: daemon.* /tmp/ppp-log This entry tells syslog to save any incoming messages from a daemon to the /tmp/ppp-log file. You can use any filename you want instead of /tmp/ppp-log. Many Linux versions of the syslog.conf file insist on tabs to separate the columns instead of spaces. Once your script is working, remember to remove this line or the log file will grow quite large! If you really want to watch what is going on with pppd, you can invoke a debugging option with the kdebug command followed by a number. The three values for debugging are: 1 general debug messages 2 display incoming HLDC data 4 display outgoing HLDC data The numbers are added together to give the debug level you want. For example, the command kdebug 5 will display all general debug messages and all outgoing HLDC data. A value of 7 displays everything (this display gets very long). You can send the output to a file or the console. PPP Authentication PPP is a wonderful protocol for modem-based communications, but it has one major problem: it has security holes large enough to drive a bus through. If incorrectly configured even slightly, anyone can use the PPP line to get into your machine, or use the PPP line to get out to other systems. To help prevent this, authentication is often used. Authentication essentially makes sure that each end of the connection is who they say they are and are allowed to use the link. PPP uses two authentication schemes: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP is much like a login procedure. When one machine sends the login name and password to the other, the receiving machine verifies the information with a database on its end. While simple, PAP has the problem that anyone can tap into the line and monitor the passwords being sent. CHAP solves this problem, and hence is the most favored form of authentication for PPP links. CHAP enables one machine to send a random string to the other, along with its hostname. The other end uses the hostname to look up the proper reply, combine it with the first string, encrypt it, and then resend it to the first machine along with its hostname. The first machine performs the same sort of manipulation on the random string it first sent, and if the two replies match, the authentication is complete. CHAP doesn't authenticate only at start time, but at random intervals throughout the connection, which adds to its power. When two machines connect, they don't use authentication unless explicitly instructed to do so (see the auth entry in the /etc/ppp/options file, discussed earlier). When authentication is active, one end will try to use CHAP first, then, if that fails because the other end doesn't support CHAP, it will use PAP. If neither authentication scheme is supported by the other end, the connection is terminated. If you are going to use authentication for all your PPP connections, put the auth entry in the /etc/ppp/options file. If not all your connections support authentication, then those connections will fail if auth is specified. The information needed for both CHAP and PPP are kept in two files called /etc/ppp/chap-secrets and /etc/ppp/ppp-secrets respectively. When authentication is active, one end will check the other for these files, trying CHAP first. If you are going to use authentication for all your connections (which is a very good idea), you can build up the chap-secrets and pap-secrets files. If you configure both chap-secrets and pap-secrets and specify the auth option in /etc/ppp/options, no unauthenticated host can connect to your machine. The /etc/ppp/chap-secrets file consists of four columns for the client name, the server name, the secret password string, and an optional list of IP addresses. The behavior of the system is different depending on whether the local machine is being challenged to authenticate itself or is issuing a challenge to the remote. When the local machine has to authenticate itself, pppd examines the /etc/ppp/chap-secrets file for an entry in the client field that matches the local host name and the server field equal to the remote hostname, and then uses the string to build the authentication message. Such an entry in the /etc/ppp/chap-secrets file looks like this: # client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS" This entry will use the string "I hate DOS" to build an authentication message back to big_guy.big_net.com. The quotations are necessary to surround the string in the file. (The addresses column is discussed below.) If you are setting up your system to connect to three different PPP remotes, you will want an entry for each server, so your file may look like this: # client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS" merlin.tpci.com chatton.cats.com "Meow, Meow, Meow" merlin.tpci.com roy.sailing.ca "Hoist the spinnaker" When your machine is sending the challenge, the process is reversed. The pppd daemon looks for the remote hostname in the client field, the local hostname in the server field, and uses the string to compare the encryption results with the string sent back by the remote. Entries in the /etc/ppp/chap-secrets file for this purpose look like this: # client server string addresses big_guy.big_net.com merlin.tpci.com "Size isn't everything" Again, you will have an entry for each remote machine you may need to authenticate. You can see that you will end up having mirror image entries for the client and server fields for each machine you connect to (as either end may require authentication at any time). A simple /etc/ppp/chap-secrets file really looks like this: # client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS" big_guy.big_net.com merlin.tpci.com "Size isn't everything" merlin.tpci.com chatton.cats.com "Meow, Meow, Meow" chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty" merlin.tpci.com roy.sailing.ca "Hoist the spinnaker" roy.sailing.ca merlin.tpci.com "Man overboard" The size of the file could get quite large, so CHAP enables you to use a wildcard match, usually only for your local machine. For example, in the /etc/ppp/chap-secrets file below: # client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS" big_guy.big_net.com merlin.tpci.com "Size isn't everything" merlin.tpci.com chatton.cats.com "Meow, Meow, Meow" chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty" merlin.tpci.com roy.sailing.ca "Hoist the spinnaker" * merlin.tpci.com "Man overboard" the last entry enables any other machine connecting to the localhost and requiring authentication to use the same string. Of course, the remote must have the same string in its chap-secrets file. This is a little less secure than a dedicated string for each remote, but can be a handy time-saver when using a number of machines only rarely. The addresses field, which wasn't used in the samples above, enables you to list either symbolic names or IP addresses for the clients. This is necessary if the remote wants to use an IP address other than its normal one, which would cause the authentication to fail normally. If the address field is empty (as they all are in the samples), any IP address is allowed. A hyphen in the field disallows all IP addresses with that client. The /etc/ppp/pap-secrets file is much the same as the chap-secrets file. The fields in the pap-secrets file are the client (called a user in the pap-secrets format) and server names, a secret string, and valid address aliases. However, the look of the file is different because the client and server names are not full domain names and the secret string is a single block of text. A sample pap-secrets file looks like this: # /etc/ppp/pap-secrets # user server string addresses merlin darkstar yG55Sj29 darkstar.big_net.com darkstar merlin 5Srg7S merlin.tpci.com merlin chatton MeowMeow chatton.cats.com chatton merlin 73wrh6s merlin.tpci.com In this example, the first two lines show a connection to the machine darkstar. The first line is how we authenticate a request from darkstar, and the second how we authenticate a request from us to them. The user name in the first column is the name we send to the remote, while the server field is their identification to us. This poses a problem: the pppd daemon has no way of knowing the remote host's name, because all it gets is an IP address. You can put the IP address in the addresses column of the file, or you can specify the remote host name at the end of the pppd command line like this: pppd ..... remotename chatton user merlin This shows that the remote is called chatton, and our local host is merlin. The last portion giving the local host name overrides the default values, if specified. Using DNS for SLIP and PPP If you are using SLIP or PPP to connect to the Internet for more than simple tasks (such as downloading e-mail and news), you will probably want to use DNS. The basic configuration for DNS and BIND were discussed in Chapter 30, "Configuring TCP/IP." The easiest method of using DNS for your SLIP and PPP connections is to put the IP address of a name server you can access in the /etc/resolv.conf file. For example, if you can access a name server with an IP address of 45.2.12.1, you would make the following addition to your /etc/resolv.conf file: # /etc/resolv.conf domain merlin.com # the local domain nameserver 145.2.12.1 # the Internet name server Once this entry has been established, SLIP or PPP will send requests for address resolution to the name server and wait for replies. The more accessible the name server is, the better the performance will be. For this reason, choose a name server that is relatively close (in network terms). Using this approach has a problem, though: all address resolution attempts must go out over the SLIP or PPP line. This can slow down applications, as well as increase the amount of network traffic over your SLIP or PPP line, sometimes to the detriment of other applications. A way around this problem is to set up a cache-only name server on your machine. As you may recall from Chapter 30, a name server uses a cache to retain the most commonly used addresses. Since most SLIP and PPP connections are to a few machines only, the cache can dramatically reduce the amount of resolution traffic on the SLIP or PPP link. To set up a cache-only name server, you need to modify the /etc/named.boot file. To set your local machine up as a cache-only name server, your named.boot file would look like this: ; /etc/named.boot directory /var/named cache db.cache ; cache-only primary 0.0.147.in-addr-arpa db.cache ; loopback The file above uses the local network name in IN-ADDR-ARPA format to specify the loopback driver, and the cache points to the file db.cache, which contains a list of root name servers. Summary Once you have performed all the configuration steps and startup instructions mentioned above for SLIP and PPP, you can use the interfaces to the outside world. The applications that make use of SLIP and PPP usually expect only to be told where the interface is, and then to work without any interference from you. SLIP is much easier to configure than PPP, but PPP has faster throughput and more security features that make it attractive if you are using a modem connection a lot. |