8.2 PPP Configuration in Linux

   


PPP drivers in the Linux kernel have comparatively few configuration options. The reason is that most settings were moved to pppd, which means that they can be changed at runtime or even set separately for different devices.

It is important to note that PPP over ISDN requires different settings, which have nothing to do with the settings discussed in this section, because the ISDN subsystem includes its full PPP implementation. This applies particularly to the kernel options, but also to the pppd configuration. To be able to use PPP over ISDN, for example, it is not necessary to activate the "normal" PPP in the configuration of the Linux kernel.

8.2.1 Kernel Options

The Linux kernel version 2.2 included only one option that could be used to enable or disable the full PPP support. Version 2.3 introduced three additional setting options (shown in Table 8-2).

Table 8-2. PPP driver options in the Linux kernel.

Option

Meaning

CONFIG_PPP

Activates the generic PPP.

CONFIG_PPP_ASYNC

Activates the asynchronous PPP.

CONFIG_PPP_DEFLATE

Supports payload compression.

CONFIG_PPP_BSDCOMP

Supports alternative payload compression.


The payload compression by the deflate option is preferred over the BSD compression algorithm, because it is free from patents and more effective. By the way, the deflate algorithm is also used in gzip.

8.2.2 pppd the PPP Daemon

As was mentioned before, most settings are effected by pppd. The configuration files required for these settings are normally stored in the directory /etc/ppp/. See also the manpage of pppd, Files section, for details.

Upon startup, pppd reads first the general configuration file options and then a device-specific configuration file (e.g., options.ppp0). In addition, there is a possibility of adding user-specific settings in $HOME/.ppprc. These files include information about the serial interface to be used, about whether configuration requests of the peer should be accepted, and about which user name will be used to log into the peer. The following represent some important entries in the configuration file; however, they do not represent a full configuration:

 # Options for pppd over a serial line # /etc/ppp/options modem                     # use the modem control lines crtscts                   # use hardware flow control lock                      # create lockfile to ensure exclusive access defaultroute              # set default route to this interface debug                     # enable connection debugging facilities user egon 

The user name in the last line serves as key for the entry in the pap-secrets and chap-secrets files, which include the passport of each user in a PAP or CHAP authentication. Both files have the same structure and include clear-text passwords, so the user root should have exclusive read access to these files:

 # Secrets for authentication using PAP # /etc/ppp/pap-secrets # client          server     secret       IP addresses "egon"            *          "mypassword" "hugo"            *          "myotherpassword" 

The structure of the underlying physical connection is left to an external program. For modem connections, this program has to deal particularly with the modem initialization, dialing of the correct phone number (perhaps from a choice of several numbers), and appropriate handling of error messages output by the modem. chat is a program especially suitable for this task; it processes a special script (the so-called chatscript) and is included in the pppd package. Of course, you don't need a chatscript to connect two neighboring computers over a null-modem cable.

pppd offers a way to run shell scripts after successful establishment of a connection or before a connection is torn down. The most popular scripts are ip-up and ip-down. The ip-up script is invoked as soon as an IP address was allocated to the end system. It can be used, for example, to send all waiting mails automatically. It is less well known that a number of different scripts can be invoked, in addition to ip-up and ip-down. For example, auth-up is invoked as soon as the user authentication over PPP or CHAP was successful, but before the network protocol used (e.g., IP) is initialized, and ipv6-up and ipx-up are the counterparts to ip-up for IP Version 6 and IPX, respectively. Of course, there is a corresponding "down" script to each of these "up" scripts.

8.2.3 Dial on Demand

Since Version 2.3, pppd supports the dial-on-demand mode directly (i.e., no additional program, such as diald, is required).

The dial-on-demand mode means that a PPP connection is established automatically when needed (i.e., when IP packets are ready to be output from the corresponding network device). If the connection remains idle for a specific (configurable) period, then pppd tears it down automatically. This means that the expensive telephone line is used only upon demand, and the user does not have to dial. The only drawback of this mode is that it introduces a certain delay until the connection is up.

This functionality is implemented by the state PHASE_DORMANT. (See Section 8.4.2.) pppd assumes this state before a peer dialed, if the option demand is stated in its configuration file. In this case, the generic PPP driver in the Linux kernel sends outgoing IP packets for the respective PPP device directly to pppd, which dials into the provider, rather than to the asynchronous driver.

To better control the cost, the option active-filter can be used to specify a filter to decide which network traffic is important enough to establish a connection. Detailed information about this functionality is found in the manpage of pppd in the Options section.

8.2.4 Automatic Callback

The automatic callback function means that the client first dials normally to a remote server. During the configuration phase, however, the client uses the PPP subprotocol CBCP (Call Back Configuration Protocol) to request a callback. Subsequently, the connection is torn down, and pppd terminates with return value 14. If the server is configured appropriately, then it calls back the client, so that the client and the server, in effect, switch their roles. This functionality is suitable, for example, when a company wants to assume the cost for its teleworkers dialing into company computers.


       


    Linux Network Architecture
    Linux Network Architecture
    ISBN: 131777203
    EAN: N/A
    Year: 2004
    Pages: 187

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net