| Previous | Table of Contents | Next |
The /etc/diphosts file controls access to SLIP on your machine and contains the connection parameters for each account allowed to use SLIP. It contains lines that look similar to the following:
Slinux2::linux2.burwell.com:linux2 SLIP:SLIP,296
The fields in this file are the user ID, secondary password, host name or IP address of the calling machine, an informational field not currently used, and the connection parameters for this account. The connection parameters field contains the protocol (SLIP or CSLIP) and the Maximum Transmission Unit (MTU) value for this account.
If the second field isn’t empty, diplogin prompts for an external security password when the specified account logs in to your machine. If the response from the remote host doesn’t match the string in this field, the login attempt is aborted.
CAUTION:
The diplogin program requires superuser privileges to modify the kernel routing table. If you aren’t running dip setuid root, you can’t use a link between dip and diplogin. You must make a separate copy of dip called diplogin and have its suid root.
That’s all it takes. Setting up SLIP accounts and the /etc/diphosts file completely configures your system to support incoming SLIP links.
Point-to-Point Protocol (PPP) is another protocol for sending datagrams across a serial link. Developed after SLIP, PPP contains a number of features SLIP lacks. It can automatically negotiate options such as IP addresses, datagram sizes, and client authorization. It can also transport packets from protocols other than IP.
PPP operates in two parts: the PPP driver in the Linux kernel and a program called pppd that the user must run. The most basic means of using PPP is to log in manually to the remote host by using a communications program, and then manually start pppd on the remote and local hosts. It’s much more convenient to use a chat script with pppd that handles the modem, logging in to the remote host, and starting the remote pppd. Before diving into pppd, take a quick look at chat.
Using the chat Program
chat is a program for automating the interaction between your computer and a modem. It’s used mainly to establish the modem connection between the local and remote pppd daemon processes. The syntax for chat is as follows:
chat [options] script
Table 29.4 lists the command-line options for the chat program.
| Option | Description |
|---|---|
| -f filename | Uses the chat script in the specified file. |
| -l lockfile | Makes a UUCP style lock file by using the specified lock file. |
| -t num | Uses the specified number as the timeout in seconds for each expected string. |
| -v | Makes a chat log of everything it sends and receives to syslog. |
| script | Specifies the chat script to use. |
You can’t use the -f option and specify a chat script at the same time—they’re mutually exclusive. If you use the -l option for chat, don’t use the lock option with pppd because the lock file created by chat causes pppd to fail, thinking that the modem device is already in use.
TIP: When debugging chat scripts, run tail -f /var/adm/messages on one virtual console and use the -v option when you run chat in another. You can then watch the conversation chat is having as it comes up on the first virtual console.
Creating chat Scripts
chat scripts consist of one or more expect-reply pairs of strings separated by spaces. The chat program waits for the expected text and sends the reply text when it receives it. Optional subexpect-subreply pairs can be included in the expect portion, separated by hyphens.
Here is a typical chat script for logging in to a Linux machine:
ogin:-\r\n-ogin: abbet1 word: costello
This script says that chat should wait for the string ogin: to appear. If chat times out before receiving it, chat should send a carriage return and line feed and wait for the string ogin: again. When chat sees the ogin: string, it sends abbet1 and then waits for the word: and sends costello in response.
TIP: Include only the text necessary in expect strings to positively identify what you’re looking for, to minimize the chance of a mismatch or having your script blow up because of garbled text. For example, use ogin: instead of login: and word: instead of password:.
chat normally sends a carriage return after each reply string unless a \c character sequence ends the string. Carriage returns aren’t looked for in expect strings unless explicitly requested with the \r character sequence in the expect string.
Most modems can report why a call failed when it gets a busy signal or can’t detect a carrier. You can use the abort expect string to tell chat to fail if it receives the specified strings. Multiple abort pairs are cumulative. The following script is an example of using the abort expect string:
abort ‘NO CARRIER’ abort ‘BUSY’ ogin:--ogin: ppp word: be4me
| Previous | Table of Contents | Next |