📄 lsg31.htm
字号:
ifconfig sl0 down</FONT></PRE>
<P>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 <A HREF="lsg20.htm">Chapter 20</A>, "Processes," for more information on the ps and kill commands.
<BR>
<BR>
<A NAME="E69E200"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Using dip</B></FONT></CENTER></H4>
<BR>
<P>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.
<BR>
<P>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:
<BR>
<PRE>
<FONT COLOR="#000080"># 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</FONT></PRE>
<P>The script would be called and executed with a command like this
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">dip script_file</FONT></PRE>
<P>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.
<BR>
<BR>
<A NAME="E68E174"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Setting Up PPP</B></FONT></CENTER></H3>
<BR>
<P>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.
<BR>
<P>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.
<BR>
<P>Prior to establishing a PPP link, you must have a loopback driver established (see <A HREF="lsg30.htm">Chapter 30</A>, "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).
<BR>
<BR>
<A NAME="E69E201"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Setting Up a PPP Account</B></FONT></CENTER></H4>
<BR>
<P>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 <A HREF="lsg16.htm">Chapter 16</A>, "Users and Logins," for more information about users and /etc/passwd.)
<BR>
<P>A sample /etc/passwd entry for the ppp account (with UID set to 201 and GID set to 51) looks like this:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">ppp:*:201:51:PPP account:/tmp:/etc/ppp/pppscript</FONT></PRE>
<P>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:
<BR>
<PRE>
<FONT COLOR="#000080">#!/bin/sh
mesg n
stty -echo
exec pppd -detach silent modem crtscts</FONT></PRE>
<P>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.
<BR>
<BR>
<A NAME="E69E202"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Dialing Out: chat</B></FONT></CENTER></H4>
<BR>
<P>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 <A HREF="lsg27.htm">Chapter 27</A>, "UUCP").
<BR>
<P>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:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">chat "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1</FONT></PRE>
<P>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.
<BR>
<P>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:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1</FONT></PRE>
<P>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:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin:-BREAK-ogin: ppp word: secret1</FONT></PRE>
<P>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:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">chat -f chat_file</FONT></PRE>
<P>The chat_file will contain the string:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">"" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1</FONT></PRE>
<P>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.
<BR>
<P>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:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">ABORT BUSY ABORT 'NO CARRIER' "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1</FONT></PRE>
<P>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.
<BR>
<BR>
<A NAME="E69E203"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Running ppd</B></FONT></CENTER></H4>
<BR>
<P>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:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">pppd /dev/cua1 38400 crtscts defaultroute</FONT></PRE>
<P>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).
<BR>
<P>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
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">147.23.43.1:36.23.1.34</FONT></PRE>
<P>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
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">147.23.43.1:</FONT></PRE>
<P>just sets the local IP address and accepts the remote IP address as whatever the machine sends.
<BR>
<P>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:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">pppd connect "chat -f chat_file" /dev/cua1 38400 -detach crtscts modem defaultroute</FONT></PRE>
<P>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.
<BR>
<P>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.
<BR>
<P>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.
<BR>
<P>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:
<BR>
<PRE>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -