Chapter 23 Managing PPP

This chapter contains procedures and information for configuring PPP, procedures to set up less commonly used PPP links, as well as some troubleshooting procedures. The following topics are covered:

• "Overview of the Configuration Process"

• "Adding PPP Security"

• "Configuring Dynamically Allocated PPP Links"

• "Editing asppp.cf for PAP/CHAP Security"

• "Starting Up and Stopping Your New PPP Link"

• "Using PPP Diagnostics for Troubleshooting"

PPP Task Maps

This section shows the various task maps for configuring PPP, maintaining PPP once it is installed, and troubleshooting problems with PPP

Overview of the Configuration Process

You have completed the preinstallation activities noted in Chapter 22, Planning for PPP. Now you can begin PPP configuration.

PPP requires that you:

1. Install the PPP software, if it isn't already installed.

2. Edit the /etc/inet/hosts files on all machines involved.

3. Edit the UUCP database files for all dial-out machines.

4. Edit the /etc/passwd and /etc/shadow files for the dial-in machine.

5. Edit the /etc/asppp.cf file on each machine on the link.

6. Start the link manager aspppd on each machine on a link.

7. Verify that PPP is running successfully.

Although you don't have to perform Tasks 1-4 in order, you must complete them before you can edit the PPP-configuration file.

The sections in this chapter explain the procedures for configuring PPP.

Installing the PPP Software

The PPP software is automatically included when you run the Solaris installation program and select the entire distribution. If you did not select the entire distribution, you need to install PPP as a separate package.

How to Verify Installation

Before proceeding further, you must check that the Solaris version of PPP is installed on all machines to be involved in the PPP link.

1. Become superuser.

2. On each endpoint involved in the link, type:

   # pkginfo | grep ppp

   If 32-bit PPP is installed, the following package names are displayed:

   SUNWapppr PPP/IP Asynchronous PPP daemon configuration files SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service SUNWpppk PPP/IP and IPdialup Device Drivers

   If 64-bit PPP is installed, the following package names are displayed:

   SUNWapppr PPP/IP Asynchronous PPP daemon configuration files SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service SUNWpppk PPP/IP and IPdialup Device Drivers SUNWpppkx PPP/IP and IPdialup Device Drivers (64-bit)

3. If PPP is not installed on an endpoint system, install it using either the pkgadd program or admintool software manager.

   ---

   Note -

   When using pkgadd to install PPP, you must install the packages in the order listed.

   ---

   Refer to System Administration Guide, Volume 1 for more information about pkgadd and admintool software manager.

Sample PPP Configuration

This and the following sections show you how to edit the appropriate files to support the most common PPP configuration: remote hosts and their dial-in server. Figure 23-1 illustrates the configuration used as the example for this chapter. It depicts three remote machines (nomada, nomadb, nomadc) and their dial-in server nubian, which compose the network 192.41.43. This is a separate network from the local area network 192.41.40, to which the dial-in server nubian is directly attached. Network 192.41.40 runs NIS as its name service.

The IP number shown for each remote host is the address of its PPP network interface. However, the dial-in server has a specially created IP address for the PPP interface, 192.41.43.10, in addition to the IP address for its primary network interface, 192.41.40.45.

Figure 23-1 Sample Network of Remote Hosts and Multipoint Dial-In Server

Editing the /etc/inet/hosts File

After ensuring that PPP is installed on every machine involved in your configuration, your next task is to edit the /etc/inet/hosts files on each machine. You must add host information to the hosts database for every machine on the other end of the PPP link that the local machine needs to communicate with.

You must update /etc/inet/hosts regardless of the name service in use on the physical network. This is necessary because PPP starts before the name service daemons during the booting process.

How to Configure the Remote Machine's hosts Database

1. Become superuser.

2. Edit the /etc/inet/hosts file to do the following:

   1. Add an entry with the IP address and host name of the PPP network interface for the dial-in server on the other end of the link.

      In Figure 23-1, nomada must have in its /etc/inet/hosts file an entry with the IP address for dial-in server nubian's PPP network interface. This is true also for the /etc/inet/hosts files for nomadb and nomadc.

   2. Add entries with the IP addresses of any machines on the dial-in server`s physical network that the remote host can remotely log in to.

      The /etc/inet/hosts file on nomadc would look like:

      # Internet host table # 127.0.0.1 localhost loghost 192.41.43.3 nomadc 192.41.43.10 nubian-ppp 192.41.40.20 nismaster

3. Update the databases on the name server (if the network has one) with the host names and IP addresses of the remote hosts.

Multipoint Dial-in Server hosts Database

Multipoint dial-in servers must have a unique IP address for the PPP interface, besides the local IP address for the primary network interface. When configuring the hosts database for the dial-in server, you need to perform the following procedure.

How to Configure the Dial-In Server's hosts Database

1. Become superuser.

2. Add an entry with the IP address for the PPP interface to the /etc/inet/hosts file for the dial-in server.

   For example, the /etc/hosts file on dial-in server nubian in Figure 23-1 would have the following entries.

   # Internet host table # 127.0.0.1 localhost loghost 192.41.43.10 nubian-ppp 192.41.40.45 nubian

3. For configurations where the server's physical network does not use a name service:

   1. Add entries to the server's /etc/inet/hosts files for each remote host served.

   2. Add entries for the remote hosts to the /etc/inet/hosts files of every machine on the physical network permitted to communicate with the remote machines.

4. Add a new network number to the dial-in server's /etc/inet/networks file for the network that consists of the server and its remote hosts.

   Refer to "Assigning a Network Number to the PPP Link" for more information.

Editing UUCP Databases

Before a machine can dial out over the PPP link, you must edit these files in its UUCP database:

• /etc/uucp/Devices

• /etc/uucp/Dialers

• /etc/uucp/Systems

You must edit these files for remote hosts serving as PPP dial-out machines. Additionally, you must edit these files on the dial-in server if it is to dial out to the remote hosts (a requirement for multipoint dial-in servers). Chapter 25, Overview of UUCP describes these files in detail.

Modifying the /etc/passwd File

To configure a dial-in server, you must also edit the /etc/passwd and /etc/shadow files.

You must add entries to the /etc/passwd file on the dial-in server for each user on a remote host authorized to log in to the server. When a remote host calls the dial-in server, it reads its UUCP databases and passes the server a user name or user ID for the host initiating the call. The server then verifies this user information in its /etc/passwd file.

If the user's password is authenticated, the server then logs the user in to a special shell for PPP hosts, /usr/sbin/aspppls. The server gets this information from the login shell entry in its /etc/passwd file. Using the example in Figure 23-1, dial-in server nubian might have the following entries in its /etc/passwd file:

root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:37:4:Network Admin:/usr/net/nls:
nomada:x:121:99:R. Burton:/:/usr/sbin/aspppls
nomadb:x:122:99:T. Sherpa:/:/usr/sbin/aspppls
nomadc:x:123:99:S. Scarlett:/:/usr/sbin/aspppls

Refer to System Administration Guide, Volume 1 for information about the /etc/passwd file.

In addition to the information in the /etc/passwd file, you update the /etc/shadow file with the passwords for the login names used by each endpoint machine permitted to dial in to the server. For more information, refer to System Administration Guide, Volume 1.

Editing the /etc/asppp.cf Configuration File

The /etc/asppp.cf configuration file provides the PPP link manager on one endpoint machine with information about the machine on the other end of the link--or the machines on the other end of a multipoint (or dynamic point-to-point) link. When the machine boots, the link manager uses this information to establish and maintain communication with a remote endpoint.

Editing the Configuration File

When editing asppp.cf:

• Separate keywords in the configuration file by white space (blanks, tabs, and new lines).

• Use a # sign before all character strings meant as comments. All characters placed between a # sign and the next new line are considered comments and ignored.

No other format requirements apply for the placement of the keywords in the file.

How to Edit the asppp.cf Configuration File

1. Become superuser on one endpoint machine.

2. Change to the /etc directory.

3. Edit the generic asppp.cf file to add the information defining the PPP link for this machine.

4. Save the file, making sure the permissions are set to 600.

5. Change to the /etc directories on the remaining endpoints and repeat Steps 2 and 3.

Turning Off RIP

You can disable RIP on a point-to-point link through the file /etc/gateways. This file does not come with your operating system: you must create it with a text editor.

How to Turn Off RIP

1. Become superuser.

2. Edit /etc/gateways and add the following entry:

   norip ipdptpn

   where ipdptpn represents the device name of the point-to-point PPP interface used.

   For more information, refer to the in.routed(1M) man page.

Adding PPP Security

After you have completed installing PPP on every machine involved in your configuration, you can add either PAP or CHAP levels of security for the PPP link by modifying the asppp.cf file. Refer to "Editing asppp.cf for PAP/CHAP Security".

Configuring Dynamically Allocated PPP Links

A dial-in server with a dynamic point-to-point link gives your site all the advantages of point-to-point communications. Chapter 21, Overview of PPP introduces this configuration type. It consists of remote hosts communicating with at least one dial-in server that dynamically allocates point-to-point links on an as-needed basis. The following sample configuration is used throughout this section.

Figure 23-2 Network of Remote Hosts and Dynamic Link Dial-In Servers

Each remote host communicates with the dial-in server using a standard point-to-point link. However, unlike the multipoint dial-in server in Figure 23-1, dial-in server mojave connects to a calling host over a dynamic point-to-point link. The server allocates an available link whenever a remote host attempts to establish a connection.

The idea behind a dynamic link is that the server provides the client with an IP address each time a connection is established. When the connection is established, the server allocates an available IP interface to the client. The remote IP address of the interface then becomes the client's IP address for the duration of the connection. When the connection is terminated, the IP interface is returned to the pool of available interfaces, ready to be used for another connection.

You use the same generic procedures for configuring dynamic links as you do for the remote host-to-multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the dynamic point-to-point link has its own set of issues and requires slightly different modifications to the files involved in configuration.

How to Update a Remote Host

When configuring the hosts databases on the remote machines, do the following:

1. Become superuser.

2. Add to the /etc/inet/hosts file the IP address and host name of the primary network interface for each dial-in server on the other end of the link.

   For example, in Figure 23-2, the /etc/inet/hosts file for nomada, nomadb, and nomadc should each include the IP address of the primary network interface of the dial-in server mojave.

3. Add the dummy IP address.

   This IP address is used only when PPP is started.

   The /etc/inet/hosts file on nomadc might look like:

   # Internet host table # 127.0.0.1 localhost loghost 192.41.40.55 mojave 1.2.3.4 dummy

4. Add to the /etc/inet/hosts file the IP addresses of all machines on the dial-in server`s physical network that the remote host can remotely log in to.

5. Update the databases on any name server on the physical network with the host names and IP addresses of the remote hosts.

How to Update the Dial-In Server

You do not have to add any PPP-specific address to the hosts database for the dial-in server. The dynamically allocated link must use the server's primary network interface. Therefore, when configuring the hosts database for the dial-in server, do the following:

1. Become superuser.

2. Add entries to the server's /etc/inet/hosts files for each remote host served.

3. Add to the /etc/inet/hosts files of every machine on the physical network the entries for any remote hosts they are permitted to communicate with.

Editing asppp.cf for PAP/CHAP Security

You can edit the asppp.cf file to establish security and to specify whether parts of the link will respond to Password Authentication Protocol (PAP), or Challenge-Handshake Authentication Protocol (CHAP), as described in "PPP Security". The asppp.cf file is edited by adding a series of keywords. In this section, authenticator is the system starting the link or challenge, and is frequently the server. Peer is the other end of the link, and is often the client.

The keywords to be added are require_authentication and will_do_authentication. The authenticator or server generally require authentication and the peer or client generally does authentication.

How to Install PAP/CHAP

1. Become superuser on the server.

2. Edit the /etc/asppp.cf file.

3. Add the require_authentication keyword for each machine on the link to use either CHAP or PAP security.

   1. For each pap keyword add an associated pap_peer_id and pap_peer_password string.

   2. For each chap keyword add an associated chap_peer_secret and chap_peer_name string.

      You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 24-1 to see what each keyword specifies. Examples can be found in Example 23-1.

4. On each remote host on the link to use either PAP or CHAP security, add an entry in the remote host's /etc/asppp.cf file with the will_do_authentication keyword.

   1. For each pap keyword entry add an associated pap_id and pap_password string.

   2. For each chap keyword entry add an associated chap_secret and chap_name string.

PAP/CHAP Examples

The example below shows the asppp.cf file for the server mojave with PAP and CHAP authentication required. The peers are nomada (PAP) and nomadb (CHAP).

Example 23-1 Code Example for Server mojave

ifconfig ipdptp0 plumb mojave nomada up
ifconfig ipdptp1 plumb mojave nomanb up
path
      peer_system_name tamerlane
      require_authentication pap  #tells nomada that mojave
                                  #requires pap authentication
      pap_peer_id desert
      pap_peer_password oasis
path
      peer_system_name lawrence
      require_authentication chap  #tells nomadb that mojave
                                   #requires chap authentication
      chap_peer_name another\sdesert
      chap_peer_secret secret\soasis\swith\007bell

The next sample shows mojave's remote host nomada offering to do both PAP and CHAP authentication.

Example 23-2 Code Example for Remote Host nomada

ifconfig ipdptp0 plumb tamerlane mojave up
path
      interface ipdptp0
      peer_system_name mojave
      will_do_authentication chap pap #nomada tells mojave
                                      #that it will do chap and
                                      #pap authentication
      pap_id desert
      pap_password oasis
      chap_name desert\srain
      chap_secret %$#@7&*(+|`P'12

The next example shows mojave's remote host nomadb offering to do CHAP authentication.

Example 23-3 Code Example for Remote Host nomadb

ifconfig ipdptp0 plumb nomadb mojave private up
path
     interface ipdptp0
     peer_system_name mojave
     will_do_authentication chap   #nomadb tells mojave that it
                                   #will do chap authentication
     chap_name another\sdesert
     chap_secret secret\soasis\swith\007bell

Ideally, both CHAP and PAP are included in the configuration file, with the server requiring authentication and the remote host willing to do authentication. However this is reversible so that either side can require authentication. CHAP secrets need to be delivered by secure means. This generally involves manually releasing them.

Starting Up and Stopping Your New PPP Link

You can start PPP either automatically, at boot time, or manually from the command line.

How to Manually Start PPP

You can start PPP manually, although this is not normally required.

1. Become superuser.

2. Type:

   # /etc/init.d/asppp start

How to Verify That PPP Is Running

1. Become superuser.

2. Run the ps command:

   # ps -e | grep asppp

   The resulting output from grep should list the aspppd daemon, indicating that PPP is running.

3. If you do get results, verify that you can reach the remote PPP link by typing:

   # ping remote-host 300

   This version of ping sets a timeout value of 5 minutes (300 seconds). You should receive output similar to remote-host is alive. If you receive a different notice, such as remote-host unreachable, route configuration has failed.

4. Check for errors in the configuration process by examining the log file.

   # tail /var/adm/log/asppp.log

   The asppp.log contains error messages if any errors were encountered during configuration.

See "Common Check" for information on troubleshooting and problem solving.

How to Stop PPP

To stop PPP operations on your network:

1. Become superuser.

2. Type:

   # /etc/init.d/asppp stop

Common Check

The following section contains some common checks that you might need to perform to verify the operation of your PPP setup.

You must become superuser to perform these checks.

Checking Hardware

Make sure that all modem and power cables are tightly seated. If you are having problems with PPP, always check the modems, cables, serial card, and phone lines first.

How to Check Interface Status

After PPP is started, you can use ifconfig to monitor the current state of the line, using only the PPP interface name as an argument. Example 23-4 shows sample output from ifconfig for PPP links that are running.

If a user is privileged (root), and issues an ifconfig command, machine addresses are displayed in the output as shown in the following example.

1. Become superuser.

2. Type:

   ifconfig ipdptp0

Example 23-4 ifconfig Output for Point-to-Point Link

nomadb# ifconfig ipdptp0

ipdptp0: flags=28d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,UNNUMBERED> mtu 1500
        inet 129.144.111.26 --> 129.144.116.157 netmask ffff0000
        ether 0:0:0:0:0:0 

You receive output similar to that in Example 23-5 for both standard and dynamic point-to-point links.

Example 23-5 ifconfig Output for Multipoint Link

nubian# ifconfig ipd0

ipd0: flags=c1<UP,RUNNING,NOARP> mtu 1500
        inet 129.144.201.191 netmask ffffff00
        ether 0:0:0:0:0:0

If ifconfig does not display UP and RUNNING, you did not configure PPP correctly. For more information on ifconfig, see "ifconfig Command" and the ifconfig(1M) man page.

How to Check Connectivity

Use the ping command to verify that the connection is up or can be established. For example, consider the following simple round-trip test:

1. Become superuser.

2. Type:

   # ping elvis

   where elvis is the name of the PPP interface on the remote host. If the resulting display is

   elvis is alive

   then packets can be sent to and received from elvis. If not, a routing problem exists at some point between the local and remote hosts. For more information on ping, refer to "ping Command" and the ping(1M) man page.

How to Check Interface Activity

Use the netstat command as follows to check that packets are being sent and received correctly:

1. Become superuser.

2. Type:

   # netstat -i

Refer to "netstat Command" and the netstat(1M) man page.

How to Check the Local Routing Tables

Use the netstat command to display the local routing tables:

1. Become superuser.

2. Type:

   # netstat -r

The following is sample output:

Routing tables
Destination     Gateway    Flags  Ref    Use    Interface
------------- ------------ ----- ------ ------- ----------
sahara        deserted     UGH    0           0  ie1
karakum       labia        UGH    0           0  ie1
frodo         bilbo        UGH    1       12897  ipdptp0
route7        route7       UGH    0           0  ie0
eastgate      route71      UGH    0         158  ie0
backbone      pitstopbb    U      1       16087  ie1
dresdenpc     route1       UG     0           0  ie1
loopback      localhost    U      2      113436  lo0
swan-bb       pitstop      U      406    146044  ie0
dallas2       route7       UG     0           0  ie0
trainingpc    route62      UG     0           0  ie1

Make sure a routing table entry exists for each possible destination network. In particular, PPP devices, listed under Interface, should be matched with the appropriate host names listed under Gateway. The Gateway entry should, in turn, be matched with the correct entry under Destination.

Otherwise, if you are using static routing, add the appropriate static routes.

How to Add Routes Using in.routed

If you are using dynamic routing with in.routed:

1. Become superuser.

2. Verify that in.routed is running by typing:

   # ps -e | grep route

   If the routing tables still don't look correct, become superuser and continue with the next steps.

3. Kill in.routed by typing the process ID you got from ps -e as the argument to kill. For example, if 1384 was the process ID, you would type:

   # kill 1384

4. Flush the routing tables as follows:

   # /usr/sbin/route -f

5. Restart in.routed:

   # /usr/sbin/in.routed

Checking Permissions

If you attempt to use rsh and receive the message Permission denied, the remote system's /etc/hosts.equiv or /.rhosts file does not contain the sending system's host name or does not contain the line +.

Checking Packet Flow

Check the packet flow next. Use the snoop command to observe packets from the network and their contents. The example below shows some sample output from snoop.

Example 23-6 Sample Output From snoop

# snoop -d ipdptp0
Using device ipdptp0 (promiscuous mode)
corey -> pacifica7    RLOGIN C port=1019
       hugo -> ponc3         RPC R XID=22456455 Success
       ponc3 -> hugo         NFS C WRITE FH=1B29 at 32768

    commlab3 -> commlab4     TELNET R port=34148
    commlab4 -> commlab3     IP  D=129.144.88.3 S=129.144.88.4 LEN=46, ID=41925
    commlab3 -> commlab4     TELNET R port=34148
    commlab4 -> commlab3     ICMP Echo request
    commlab3 -> commlab4     ICMP Echo reply
    commlab4 -> commlab3     FTP C port=34149
    commlab4 -> commlab3     FTP C port=34149
    commlab3 -> commlab4     FTP R port=34149
    commlab4 -> commlab3     FTP C port=34149

The ipdptp0 device name mentioned in the first line of the output Using device ipdptp0 indicates a point-to-point connection.

You need to have the link up and some traffic generated in order to use snoop to check the line status.

snoop captures packets from the network and displays their contents. It uses both the network packet filter and streams buffer modules to provide efficient capture of packets from the network. Captured packets can be displayed as they are received or saved to a file for later viewing.

snoop can display packets in a single-line summary form or in verbose multiline forms. In summary form, only the data pertaining to the highest-level protocol is displayed. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if either of the verbose options is chosen.

For more information about the snoop command, refer to the snoop(1M) man page.

Using PPP Diagnostics for Troubleshooting

If you have problems with a link after successfully establishing modem connections, you can use PPP-level diagnostics for troubleshooting. PPP-level diagnostics report detailed information about the activities of a link to help you determine where it is failing.

To obtain diagnostic information, add the line debug_level 8 to the path section of the asppp.cf file. (If you are very knowledgeable about data communications, you might want to use debug level 9, which provides very detailed information.) Here is a sample configuration file that invokes PPP diagnostics.

ifconfig ipdptp0 plumb nomada nubian-ppp up
path
   interface ipdptp0
   peer_system_name nubian-ppp   #The name in the /etc/uucp/Systems file
   inactivity_timeout 300        #Allow five minutes before timing out
   debug_level 8                 #Start up PPP diagnostics for this link

For complete details about the aspppd.conf file, refer to "Editing the /etc/asppp.cf Configuration File".

How to Set Diagnostics for Your Machine

Set diagnostics on the host you want to monitor as follows:

1. Become superuser.

2. Change to the /etc directory.

3. Edit the current asppp.cf file and add the following to the path section: debug_level 8.

4. Save the file, making sure the permissions are set to 600.

5. Kill the current aspppd daemon and restart it.

   # kill PID # aspppd

   where PID is the process ID for aspppd.

   PPP reports diagnostic information in /var/adm/log/asppp.log.