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:
This section shows the various task maps for configuring PPP, maintaining PPP once it is installed, and troubleshooting problems with PPP
Table 23-1 PPP Configuration Task Map
Task... |
Description |
For Instructions, Go To ... |
---|---|---|
Verify that PPP is installed on all machines |
Use pkginfo to check that PPP is installed on all machines involved in the PPP link | |
Configure the remote machine's hosts database |
Configure the remote machine's host database by adding the IP address and host name to the /etc/inet/hosts file | |
Configure the dial-in server's hosts database |
Configure the dial-in server's hosts database by adding entries to /etc/hosts and /etc/inet/networks files. | |
Edit the /etc/asppp.cf file to add entries so that they are recognized at boot time. |
Add information necessary to establish and maintain communications with a remote endpoint to the /etc/asppp.cf file. | |
Turn off RIP. |
Add norip to the /etc/gateways file to turn off RIP. | |
Update remote host |
Add the IP address and host name to the /etc/inet/hosts file to update a remote host. | |
Update the dial-in server |
Update the /etc/inet/hosts file to add entries for each remote host served. | |
Add PAP/CHAP support |
Add require_authentication and will_do_authentication keywords to the /etc/asppp file to establish security as to whether parts of the link respond to PAP or CHAP. |
Table 23-2 PPP Maintenance Task Map
Task... |
Description |
For Instructions, Go To ... |
---|---|---|
Manually start PPP |
Use the /etc/init.d/asppp start command to start PPP. Normally, PPP is started automatically and you do not need to use this command. | |
Verify that PPP is running |
Use the ps and ping commands to see if PPP is running. | |
Stop PPP |
Use the /etc/init.d/asppp stop command to stop PPP. | |
Check interface status |
Use the ifconfig command to monitor the current state of the line. | |
Check connectivity |
Use the ping command to verify that the connection is up. | |
Check interface activity |
Use the netstat command to verify that packets are being sent and received. | |
Check local routing tables |
Use the netstat command to display local routing tables. | |
Add routes using in.routed |
Use the in.routed command to add routes when running dynamic routing. |
Table 23-3 PPP Troubleshooting Task Map
Task... |
Description |
For Instructions, Go To ... |
---|---|---|
Set up diagnostics |
How to set up PPP diagnostics for troubleshooting. |
You have completed the preinstallation activities noted in Chapter 22, Planning for PPP. Now you can begin PPP configuration.
PPP requires that you:
Install the PPP software, if it isn't already installed.
Edit the /etc/inet/hosts files on all machines involved.
Edit the UUCP database files for all dial-out machines.
Edit the /etc/passwd and /etc/shadow files for the dial-in machine.
Edit the /etc/asppp.cf file on each machine on the link.
Start the link manager aspppd on each machine on a link.
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.
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.
Before proceeding further, you must check that the Solaris version of PPP is installed on all machines to be involved in the PPP link.
Become superuser.
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) |
If PPP is not installed on an endpoint system, install it using either the pkgadd program or admintool software manager.
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.
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.
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.
Become superuser.
Edit the /etc/inet/hosts file to do the following:
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.
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 |
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 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.
Become superuser.
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 |
For configurations where the server's physical network does not use a name service:
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.
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.
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.
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.
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.
Become superuser on one endpoint machine.
Change to the /etc directory.
Edit the generic asppp.cf file to add the information defining the PPP link for this machine.
Save the file, making sure the permissions are set to 600.
Change to the /etc directories on the remaining endpoints and repeat Steps 2 and 3.
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.
Become superuser.
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.
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".
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.
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.
When configuring the hosts databases on the remote machines, do the following:
Become superuser.
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.
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 |
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.
Update the databases on any name server on the physical network with the host names and IP addresses of the remote hosts.
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:
Become superuser.
Add entries to the server's /etc/inet/hosts files for each remote host served.
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.
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.
Table 23-4 Authenticator Keywords and Associated Strings
require_authentication chap |
|
---|---|
chap_peer_secret |
|
chap_peer_name |
Table 23-5 Peer Keywords and Associated Strings
will_do_authentication chap |
|
---|---|
chap_secret |
|
chap_name |
Become superuser on the server.
Add the require_authentication keyword for each machine on the link to use either CHAP or PAP security.
For each pap keyword add an associated pap_peer_id and pap_peer_password string.
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.
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.
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).
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.
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.
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.
You can start PPP either automatically, at boot time, or manually from the command line.
You can start PPP manually, although this is not normally required.
Become superuser.
# ps -e | grep asppp |
The resulting output from grep should list the aspppd daemon, indicating that PPP is running.
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.
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.
To stop PPP operations on your network:
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.
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.
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.
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.
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.
Use the ping command to verify that the connection is up or can be established. For example, consider the following simple round-trip test:
Become superuser.
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.
Use the netstat command as follows to check that packets are being sent and received correctly:
Refer to "netstat Command" and the netstat(1M) man page.
Use the netstat command to display the local routing tables:
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.
If you are using dynamic routing with in.routed:
Become superuser.
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.
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 |
Flush the routing tables as follows:
# /usr/sbin/route -f |
# /usr/sbin/in.routed |
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 +.
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.
# 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.
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".
Set diagnostics on the host you want to monitor as follows:
Become superuser.
Change to the /etc directory.
Edit the current asppp.cf file and add the following to the path section: debug_level 8.
Save the file, making sure the permissions are set to 600.
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.