Part 2 explains how to set up and administer asynchronous PPP communications links on the network. The text assumes that you are an experienced network administrator who is familiar with TCP/IP.
This chapter presents an overview of Solaris PPP, a data-link protocol included in the TCP/IP protocol suite. The text includes product specifications, introductions to the most typical PPP configurations, and definitions of the terms related to PPP.
PPP enables you to connect computers and networks at separate physical locations by using modems and telephone lines. With PPP, users with computers at home or in remote offices can connect to your site's network. You can also use the combination of PPP software, a modem, and telephone lines as a router connecting networks in different places. PPP offers strategies for configuring these machines and networks, which are introduced in this chapter.
Solaris PPP is an asynchronous implementation of the standard data-link level Point-to-Point Protocol (PPP) included in the TCP/IP protocol suite and provided by a number of router system vendors and terminal concentrators. It includes a standard encapsulation protocol, making datagram transmission transparent to network layer protocols.
The major characteristics of the Solaris PPP protocol are:
Implements the Internet Point-to-Point Protocol, as defined in RFC 1331
Provides error detection through CRC
Supports full duplex transmission
The major functions of the protocol are:
Interface for IP to forward packets over asynchronous serial lines
Connection establishment on demand
Configurable options negotiation
Connection termination (automatic hang-up)
PPP supports interfaces to RS-232-C (V.24) facilities through the CPU serial ports included on most machines running the Solaris software. In addition, PPP runs over optional asynchronous serial ports supplied or supported by many manufacturers of machines that run the Solaris software. PPP supports the maximum data rates that your machine's serial ports can achieve. Consult the manufacturer of your computer system for more details on the speeds supported by your machine's serial hardware.
Machines of the x86 architecture require UARTs that run above a certain speed. See the for details.
PPP, and the routing functions in the Solaris software, use industry-standard conventions for performing their tasks. These conventions support:
Forwarding of IP datagrams
Reception of packets for forwarding from any IP-compatible networked system
Delivery of packets to any IP-compatible networked system on local-area network media, such as Ethernet, Token Ring, and FDDI
Use of standard routing protocols, enabling users to exchange packets with equipment that supports the PPP protocol from many manufacturers
PPP enables asynchronous devices, such as modems, to become network interfaces. Solaris PPP enables you to configure two types of virtual network interfaces, ipdptpn and ipdn. (The letter n represents the device number you assign to the interface.)
PPP network interfaces are considered virtual network interfaces because they do not involve network hardware, as does, for example, an Ethernet interface. Moreover, they are not associated with any particular serial port. The PPP network interfaces reside in the /devices directories along with the physical network interfaces. (For information on physical network interfaces, see "Network Interfaces".)
The type of network interface you use depends on the PPP communications link you want to set up. The ipdptp interface supports point-to-point PPP links; the ipd interface supports point-to-multipoint links (called "multipoint links").
This section introduces PPP-related communications concepts used. It also explains the most typical PPP configurations that you are likely to set up.
The most common use of Solaris PPP is to set up a point-to-point communications link. A generic point-to-point communications configuration consists of two endpoints connected by a communications link. In a generic configuration, an endpoint system could be a computer or terminal, either in an isolated location or physically connected to a network. The term communications link refers to the hardware and software connecting these endpoint systems. Figure 7-1 illustrates these concepts.
When an endpoint system wants to communicate with the end point on the other side of the communications link, it begins a dial-out operation. For example, to communicate with endpoint B, a user at its peer host, endpoint A, types rlogin end-point-B. This causes endpoint A to dial out over the communications link. In this instance, endpoint A functions as a dial-out machine. The rlogin command causes its modem to dial the phone number of endpoint B. The action it starts and information it passes are considered outbound communications.
When the data travels over the link to endpoint B, this system receives incoming data and sends an acknowledgment signal to endpoint A to establish communications. In this instance, endpoint B functions as a dial-in machine, since it permits other systems to dial in to it. The information passed to the communications recipient and the actions the recipient takes are considered inbound communications.
Solaris PPP supports four types of point-to-point configurations:
Host in one location connected to a host at another physical location, as shown in Figure 7-1
Dial-in servers with dynamic point-to-point links to remote hosts, as shown in Figure 7-2
Network connected to another physically distant network, as shown in Figure 7-3
Computers connected to a multipoint dial-in server physically attached to a distant network, as shown in Figure 7-4
These PPP links provide essentially the same type of connectivity provided by a local area network but without broadcast capability. The sections below summarize the configuration types; Chapter 8, Preparing Your PPP Configuration, gives information for setting up each configuration type.
PPP enables you to set up a point-to-point link to connect two standalone machines in separate locations, effectively creating a network consisting solely of these two machines. This is the simplest point-to-point configuration because it involves only the two endpoints. The generic configuration shown in Figure 7-1 also uses the host-to-host configuration.
In the past, standard dial-up or temporary connections permitted only ASCII terminals to connect to a network. With Solaris PPP, an individual machine can become part of a physically distant network by configuring it as one endpoint of the PPP link. The advantage of this nomadic connection is particularly apparent if your network includes users who travel frequently or work from home.
Figure 7-2 shows nomadic computers, each with a point-to-point link to an endpoint system on the network. The endpoint on the network is a dial-in server.
The endpoint machine on the network shown in Figure 7-2 functions as a dial-in server with dynamic point-to-point links. It is called a dial-in server because remote machines can dial in to it to reach the network. When the server receives a request to dial in from a machine, the server allocates the PPP link to the machine on an as-needed basis.
A dial-in server can communicate with the remote hosts through a dynamic point-to-point link or through a multipoint link, as explained in "Multipoint Communications Links". The dynamic point-to-point link has the advantages of point-to-point communications: RIP can run over the link, and broadcasting is enabled. Perhaps most importantly, more than one machine on the physical network can function as the dial-in server. This allows you to configure backup servers, thus enabling redundancy and easier administration. Although the machines in Figure 7-2 can directly communicate with the network endpoint, they cannot directly communicate with each other. They must pass information to each other through the dial-in server endpoint.
You can use PPP to connect two separate networks through a point-to-point link, with one system on each network serving as an endpoint. These endpoints communicate through modems and phone lines, essentially in the same fashion as shown in Figure 7-1. But in this setup, the endpoints, modems, and PPP software become routers for their physical networks. Using this type of configuration scheme, you can create an internetwork with wide geographic reach.
Figure 7-3 shows two networks in different locations connected by a point-to-point link.
In this example, endpoints A and B, their modems, public telephone lines, and the PPP software act as a router between the networks. These networks may have other hosts serving as routers between physical networks. Sometimes, the host functioning as the PPP router may have an additional network interface board, thus also serving as a router for a physical network.
You can use Solaris PPP to set up a multipoint communications link. In this type of configuration, an individual machine functions as one endpoint on the communications link. At the other end of the link may be several endpoint machines. This differs from point-to-point configurations, with a single endpoint system at either side of the communications link.
Two types of multipoint links you can configure with PPP are:
Dial-in server with multipoint connections to remote machines, as shown in Figure 7-4
Logical, or virtual, network consisting of three or more nomadic computers, as shown in Figure 7-5
The sections below summarize these configurations; Chapter 8, Preparing Your PPP Configuration, explains how to set up the configuration.
Figure 7-4 shows three geographically isolated computers communicating through a point-to-point link to an endpoint machine on a network. However, the network endpoint machine can communicate with the nomadic computers through a multipoint link, thus making it a multipoint dial-in server. (You can also set up a dial-in server with dynamic point-to-point connections, as explained in "Dial-in Server With Dynamic Point-to-Point Link".)
The dial-in server can communicate with all the machines on the other end of its multipoint PPP link. Though the machines in Figure 7-4 can directly communicate with the multipoint dial-in server, they cannot communicate directly with each other. They must pass information to each other through the dial-in server.
You can use PPP to set up a virtual network wherein the modems, PPP software, and telephone wires become the "virtual" network media. In a physical network, such as Ethernet or Token Ring, computers are directly cabled to the network media. In a virtual network, no true network media exist.
Machines become peer hosts on the virtual network when you configure each with a multipoint communications link. Then each host can dial out through its modem over phone lines to reach another endpoint machine. Each computer also functions as a dial-in machine, permitting its peer hosts on the virtual network to dial in to it.
Figure 7-5 depicts a virtual network consisting of nomadic computers connected to each other through modems and telephone lines.
Each machine exists in a different office, perhaps in a different town from other members of the virtual network. However, each machine can establish communications with its peer hosts over its multipoint communications links.
The PPP component software includes:
Link manager (/usr/sbin/aspppd)
Log in service (/usr/sbin/aspppls)
Configuration file (/etc/asppp.cf)
Log file (/var/adm/log/asppp.log)
FIFO file (/tmp/.asppp.fifo)
After you install the PPP software, you will find the /etc/init.d/asppp file, which is the run-control script for PPP. It is linked to several other files in the run-control directories.
Figure 7-6 shows the software components of PPP and how they interact.
The /usr/sbin/aspppd link manager is a user-level daemon that automates the process of connecting to a remote host when PPP service is required. This automated process starts whenever any activity that generates IP traffic takes place (for example, a user logs in to a remote machine, accesses an NFS-mounted file, and so on). If a remote host tries to establish a connection, the link manager on the local host will complete the connection.
Refer to the aspppd(1M) man page for specific information about the link manager.
The /usr/sbin/aspppls login service is invoked as a login shell that starts PPP after you dial up and log in. Its function is similar to the /usr/lib/uucp/uucico command described in "Software Comprising UUCP". When configuring a machine as a dial-in server, you must specify aspppls as the login shell in the /etc/passwd file in the entries for every nomadic computer allowed to dial in to the local host.
The asppp.cf file provides the link manager with information about each remote endpoint with which the local host will communicate. You define this information in a section of the configuration file called a path. The path section also defines the PPP interface to be used and, optionally, other attributes determining how communications will take place, including security issues. "Parts of Basic Configuration File" explains the sections of the asppp.cf file in detail. Example 7-1 shows an unmodified asppp.cf file.
#ident "@(#)asppp.cf 10 93/07/07 SMI" # # Copyright (c) 1993 by Sun Microsystems, Inc. # # Sample asynchronous PPP /etc/asppp.cf file # # ifconfig ipdptp0 plumb mojave gobi private up path inactivity_timeout 120 # Approx. 2 minutes interface ipdptp0 peer_system_name Pgobi # The name this system logs in with when # it dials this server # *OR* the entry we look up in # /etc/uucp/Systems when we dial out. |
The link manager produces messages and logs them in the log file /var/adm/log/asppp.log. The level of detail reported into the file is controlled by the -d option of aspppd or the debug_level keyword in the configuration file. See "Configuration Keywords" and the aspppd(1M) man page for more information.
The PPP FIFO file /tmp/.asppp.fifo is a named pipe used to communicate between aspppd and aspppls. This file must be present in /tmp for the PPP login service to connect to the link manager. The /tmp/.asppp.fifo file is created, managed, and deleted by the link manager.
Besides its component software, Solaris PPP uses information in three UUCP files, /etc/uucp/Systems, /etc/uucp/Dialers, and /etc/uucp/Devices, to help it establish the communications link. You must modify these files to enable a host to dial out over the PPP link. Alternatively, you can use the file /etc/uucp/Sysfiles to specify different names for the Systems, Devices, and Dialers files.
Refer to Chapter 12, UUCP Databases and Programs, for full descriptions of these UUCP files.
This section describes how the components of PPP function for outbound and inbound connections.
Outbound communications begin when a user on one endpoint host initiates an activity involving the peer host on the other end of the PPP link. The following activities take place when a user types an rcp command to copy a file from a host on the other side of the link
rcp sends the data through the levels of the TCP/IP protocol stack.
A virtual network interface (ipdn or ipdptpn) receives the data in the form of IP packets.
The interface sends the aspppd link manager a connection request that initiates an outbound connection.
The link manager then:
Verifies that the connection request corresponds to a configured path in the /etc/asppp.cf configuration file.
Consults the UUCP database files (/etc/uucp/Systems, /etc/uucp/Devices, and /etc/uucp/Dialers) for specific information about the modem and destination system.
Places a phone call to the destination host or attaches to the appropriate hardwired serial line.
The physical link to the peer host is established.
The link manager configures and initiates PPP.
The data-link layer is established, and the PPP modules on the peer hosts start communicating.
The link manager enables IP over the link.
The link manager then monitors the connection until an even, such as an idle time out, line disconnect, or error condition, occurs. When any of these events occur, the link manager disconnects from the peer host and returns to the idle state.
The host initiating the inbound communication logs in, which invokes the /usr/sbin/aspppls login service. Then the following events occur:
The login service connects to the link manager through the /tmp/.asppp.fifo file.
The login service provides the link manager with information such as the login name used by the endpoint at the other end of the link.
The link manager uses this login name to find a corresponding configured path in the configuration file.
The link manager then configures and initiates PPP.
The data-link layer is established, and the PPP modules on the peer hosts start communicating.
The link manager enables IP over the link.
The link manager then monitors the connection until an event occurs such as an idle time out, line disconnect, or error condition. When any of these events occur, the link manager disconnects from the peer and returns to the idle state.
After you have completed installing PPP on every machine involved in your configuration, you can add either one or two levels of security for the PPP link.
The first level, Password Authentication Protocol (PAP), is the least secure. A password is sent over the circuit "in the clear" until authentication is acknowledged or the connection terminated.
The second level of security, Challenge-Handshake Authentication Protocol (CHAP), periodically verifies the identity of the peer--the other end of the point-to-point link. A challenge message is sent to the peer by the authenticator--the system starting the link or challenge. The response is checked against a "secret" not sent over the link, and if the values match, authentication is acknowledged. Otherwise, the link is terminated. The process of adding PPP security is described in "Editing asppp.cf for PAP/CHAP Security".
Before configuring the PPP software, you need to prepare the hardware and software involved and gather some information that is needed during the configuration process. This chapter explains the tasks you have to perform prior to configuration, such as:
Determining your network addressing scheme
Ensuring that your hardware meets the requirements for PPP
Preparing your software to meet the requirements for PPP
The chapter concludes with a checklist to help you organize this information before you configure your PPP link.
Solaris PPP supports many configuration options, including:
Remote computer-to-network over a point-to-point link
Remote computer-to-remote computer over a point-to-point link
Network-to-network over a point-to-point link
Dial-in server-to-multiple remote computers through one or more dynamic point-to-point links
Dial-in server-to-multiple remote computers through a multipoint link
Multiple remote computers comprising a virtual network, all communicating through multipoint links
These configurations are introduced in "Extending Your Network With PPP" in Chapter 7, Understanding PPP.
This section describes the information you need to gather and tasks you have to perform for each configuration type before beginning the configuration process. Read the section that describes the configuration you want to set up.
Areas you need to consider are:
Network interface
Addressing method
Name service used, if any
Dial-in as well as dial-out support
Routing requirements
The remote computer-to-network is the most common asynchronous PPP configuration. Use it to configure machines in remote offices or user's homes that dial out over a point-to-point PPP link to a dial-in server on a network.
Network interface - This point-to-point link uses the ipdptpn virtual network interface. You need to specify it in the configuration files of all remote machines that dial out to a network.
Addressing method - The configuration file must include the host names or IP addresses of the machines that communicates over the link. For remote hosts, you should use existing host names and IP addresses. Refer to "Determining IP Addressing for Your PPP Link" for complete details.
Name service - NIS and NIS+ name services are not recommended for remote hosts. These services generate a great deal of network traffic, often at unexpected times. The DNS name service is more efficient for this type of configuration. You might want to set up DNS, as described in Solaris Naming Administration Guide, on each remote host. If you don't use DNS, PPP accesses /etc/inet/hosts file on the remote machine.
Dial-in and dial-out support - Remote hosts usually implement dial-out communications only. They do not allow other machines to dial in to them directly. Therefore, you must update the UUCP files on each to support dial-out communications, as explained in "Editing UUCP Databases".
Routing requirements - Because RIP is part of the Solaris TCP/IP protocol stack, it runs by default on remote hosts. Turn off RIP to improve performance, if necessary, and instead use static routing. See "To Select Static Routing on a Host" and "Turning Off RIP" for details.
Use the host-to-host configuration to establish point-to-point communications between two remote hosts in different physical locations. This configuration is useful for two standalone machines in remote offices that need to exchange information. No physical network is involved.
Network interface - This basic point-to-point link uses the ipdptpn virtual network interface. You must specify the interface in the configuration files of both endpoints.
Addressing method - The configuration file must include the host names or IP addresses of the machines that can communicate over the link. Use the existing host names and the IP addresses assigned to the primary network interface, if they already exist. Otherwise, create IP addresses for the endpoints. Refer to "Determining IP Addressing for Your PPP Link" for complete details.
Name service - Because only two peer hosts are involved, you don't need a true name service. The /etc/inet/hosts files on both peer hosts are used for address resolution.
Dial-in and Dial-out support - Both machines need to perform dial-in and dial-out operations. You must modify the UUCP databases and /etc/passwd on both endpoints.
Routing requirements - Because RIP is part of the Solaris TCP/IP protocol stack, it runs by default on remote hosts. Turn off RIP to improve performance, if necessary, and instead use static routing. See "To Select Static Routing on a Host" and "Turning Off RIP" for details.
Use the network-to-network PPP configuration to create an internetwork joining two networks in physically separate locations. In this case, modems and PPP software function as the router connecting the networks.
Network interface - The point-to-point link uses the ipdptpn virtual network interface. You must specify ipdptpn in the configuration files for both endpoint machines joining the two networks.
Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Two possible addressing scenarios exist for this type of configuration; they are explained in "Determining IP Addressing for Your PPP Link".
Name service - NIS and NIS+ name services can function over this type of PPP link; however, each network should be a separate domain. If you use DNS, both networks can be part of a single domain. Refer to Solaris Naming Administration Guide for details. If you use local files for name service, the /etc/inet/hosts files on both endpoint machines are used for address resolution. They must contain the host names and IP addresses of every host on each network that can communicate over the link.
Dial-in and Dial-out support - Both network endpoint machines need to perform dial-in and dial-out operations, so you should update their UUCP and /etc/passwd files.
Routing requirements - The endpoints in a network-to-network link usually run RIP in order to exchange routing information. Do not disable RIP for this configuration.
A dynamic point-to-point link is one of two types of configurations that you can use for a dial-in server functioning as the network endpoint that remote hosts access. In this configuration scheme, the server connects to its remote hosts over a dynamically allocated point-to-point link. The dial-in server uses its dynamic links on an as-needed basis to establish communications with the remote hosts it serves.
Network interface - The dynamic point-to-point link uses the ipdptp* virtual network interface with an asterisk wildcard character. The asterisk enables the link to be allocated dynamically. You must specify this interface in the configuration file.
Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Refer to "Determining IP Addressing for Your PPP Link" for complete details.
Name service - Although NIS and NIS+ are not recommended for remote hosts, the dial-in server in a remote host-to-network configuration can be an NIS client on the network to which it is physically connected. If NIS is on the server's physical network, make sure that the NIS maps are updated with the host names and IP addresses of the remote hosts. You can use DNS on the dial-in server and its remote hosts. For more information regarding DNS and name services in general, refer to Solaris Naming Administration Guide. If you use local files for name service, PPP access the /etc/inet/hosts file on the dial-in server for address resolution.
Dial-in support - You must update the /etc/passwd file on the dynamic point-to-point dial-in server. The dynamic link server does not directly dial out to the remote hosts.
Routing requirements - Because RIP is part of the Solaris TCP/IP protocol stack, it runs by default on remote hosts. Turn off RIP to improve performance, if necessary, and instead use static routing. See "To Select Static Routing on a Host" and "Turning Off RIP" for details.
A multipoint link is one of two types of configurations that you can use for a dial-in server functioning as the network endpoint that remote machines can access. In this configuration scheme, the dial-in server connects to multiple remote hosts over the same multipoint link. The remote hosts always connect to the dial-in server over a point-to-point link, as explained in "Remote Computer-to-Network Configuration".
Use this configuration when you want to define a separate network of remote hosts and their dial-in server.
Network interface - The multipoint link uses the ipdn virtual network interface. You must specify this interface in the configuration file for the dial-in server.
Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Refer to "Determining IP Addressing for Your PPP Link" for complete details. You must create a separate network for the machines on the multipoint link. See "Assigning a Network Number to the PPP Link" for more information.
Name service - Although NIS and NIS+ are not recommended for remote hosts, the dial-in server in a remote host-to-network configuration can be an NIS client on the physical network to which it is connected. If NIS is on the server's physical network, make sure that the NIS maps are updated with the host names and IP addresses of the remote hosts. You can use DNS on the dial-in server and its remote hosts. For more information regarding DNS and name services in general, refer to Solaris Naming Administration Guide. If you use local files for name service, PPP uses the /etc/inet/hosts file on the dial-in server for address resolution.
Dial-in and dial-out support - The multipoint dial-in server functions as a network router between its PPP virtual network and the physical network to which it is connected. It dials out to its remote hosts whenever it receives IP traffic from the physical network destined for its PPP network. Therefore, you must configure the multipoint dial-in server for both dial-in and dial-out support, and update its UUCP and /etc/passwd files.
Routing requirements - The ipdn interface does not support RIP; there is no need to disable it.
Use a virtual network configuration to connect three or more physically separated computers into a virtual network of phone lines, modems, and PPP software.
Network interface - This type of configuration requires a multipoint link, which uses the ipdn virtual network interface. This interface connects each endpoint system with the other endpoints on the virtual network.
Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Refer to "Determining IP Addressing for Your PPP Link" for more information. You must assign a network number to the virtual network. Refer to "Creating a Unique IP Address and Host Name" for complete details.
Name Service - You can run NIS and NIS+ for the virtual network; however, this can affect the performance of the link. DNS is a better alternative. Refer to Solaris Naming Administration Guide for instructions on setting up these name services. If you use files for name service, be sure to update /etc/inet/hosts on each machine with the host names and IP addresses of all machines on the virtual network.
Dial-in and dial-out support - All machines in the virtual network must be configured for both dial-in and dial-out operations, so you should update their UUCP and /etc/passwd files.
Routing requirements - The ipdn interface does not support RIP; you do not need to disable it.
To enable communications over the PPP link, the machine at one end of the link must know the host name and IP address of the peer host on the other end of the link. The PPP configurations often require a particular addressing scheme. This section explains the addressing schemes and where each should be used.
On each endpoint machine, you specify addressing information in these places:
/etc/asppp.cf configuration file
/etc/inet/hosts file
NIS+, NIS, or DNS databases, if applicable
When you edit the local machine's asppp.cf file, you must provide the host names and, in certain cases, the IP addresses for each endpoint machine to be on the link. For example, you must type either the IP addresses or host names for each endpoint as arguments in the ifconfig section in the configuration file:
ifconfig ipdptp0 plumb 192.99.44.01 192.99.44.02 up |
See Chapter 9, Configuring PPP, for information regarding the format of /etc/asppp.cf.
Additionally, to enable communications, you must add the IP address and host name of the remote endpoints to the hosts database on the local end point by editing /etc/inet/hosts. This process is explained in "Configuring Network Clients".
You have a choice of several addressing schemes for PPP, depending on your configuration type. Before you edit the asppp.cf file and hosts database, you must decide on the appropriate addressing scheme for your configuration. These schemes include:
Using the same IP addresses for the PPP endpoints as is assigned to their primary network interface in their local /etc/inet/hosts files
Assigning a unique IP address for each PPP endpoint
Assigning a new network number for the network created by the PPP link
This addressing scheme is appropriate for point-to-point links only. In this scheme, you specify the addresses of the primary network interface for each endpoint. (See Chapter 1, Overview of Network Administration, for more information about the primary network interface.) These endpoints might be:
Two standalone machines communicating over the PPP link (if they have existing IP addresses)
Two network endpoints communicating over the PPP link
Remote host connecting to a network dial-in server through a point-to-point link
Dial-in server connecting to remote hosts through a dynamically allocated point-to-point link
When you edit the /etc/inet/hosts file on a local endpoint, supply the IP address of its primary network interface and host name and the IP address of the peer host on the other end of the link.
In this method, you assign a unique host name and IP address to the PPP network interface. (You might want to call the interface hostname-ppp.) Use this addressing scheme fo:
Endpoint machines on a network used as a multipoint dial-in server
Machines on a virtual network
Remote host that uses a dedicated IP address for communicating with a dial-in server over a dynamically allocated PPP link. (Note that this is not a requirement for the dynamic link configuration.)
Machine that is also configured as a router for a physical network, such as Ethernet or Token Ring
Machine in a standalone-to-standalone configuration that does not have an existing IP address. (The PPP interface becomes the primary network interface.)
You must specify the unique address and host name for the PPP network interface in the asppp.cf configuration file.
To create the new host name and IP address, add it to the /etc/inet/hosts file on the endpoint machines, as described in "hosts Database".
You create a new network number for the PPP configuration when it involves:
Virtual networks of computers communicating through PPP multipoint links (required)
A multipoint dial-in server and its remote hosts (required)
The PPP link between two networks, particularly when one or both of the network endpoint machines are also routers for a physical network (optional)
(See Chapter 3, Planning Your Network, for information on network numbers.)
The PPP link becomes a virtual network, since it does not involve any physical network media. You need to type its network number in the networks database on all endpoint machines, along with the network numbers of the networks being linked.
Example 8-1 shows a sample /etc/inet/networks file for an internetwork with PPP:
kalahari 192.9.253 negev 192.9.201 nubian-ppp 192.29.15 |
In the sample file, kalahari and negev are two local area networks, and nubian-ppp is the name of the PPP link.
The RIP routing protocol runs on Solaris TCP/IP networks by default. In most cases, you should leave RIP running on point-to-point links. However, if you are having performance problems with the link, you might want to disable RIP on the point-to-point link.
RIP is not started on multipoint links. Therefore, you must set up static routing for the multipoint link. Refer to "To Select Static Routing on a Host" for instructions.
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.
To turn off RIP, /etc/gateways must have 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.
The basic PPP configuration involves a computer, a modem, and RS-232 telephone lines. However, before you configure, you need to verify whether the hardware you selected can support PPP. This section describes the hardware requirements for PPP.
Modem requirements - To run PPP, each endpoint machine must have a modem that supports at least 9600 bps or faster bidirectional connections. Such a modem implements the V.32 or V.32bis specification.
Serial port selection (for dial-in servers only) - You can configure either serial port A or serial port B on most CPUs for PPP usage. Use the Solaris Serial Port Manager to initialize the ports on the dial-in server. System Administration Guide contains instructions for selecting the appropriate port. If you have additional serial cards installed, you can also use their serial ports for PPP connections.
Disk space - You must have 300 Kbytes of free space in /usr to install PPP.
You need sufficient space in the following directories for the PPP software:
/usr
/usr/kernel/drv
/usr/kernel/strmod
/usr/sbin
PPP occupies approximately 243 Kbytes in /usr and 4 Kbytes in / (root).
Use this checklist to prepare for configuring PPP. It lists the information you need to gather and the tasks you need to do before starting the configuration process.
Do you have 300 Kbytes of free space available in /usr? ___________
Do you have 4 Kbytes of free space available in / (root)? ___________
Do the modems for each endpoint support V.32 or V.32bis or higher? ___________
Have you used the Serial Port Manager on the dial-in server to designate the serial port for the modem? ___________
Have you ensured that Solaris PPP is installed on each endpoint machine? (If PPP hasn't been installed, you can use the pkgadd program or admintool software manager to install it. Refer to Solaris Advanced Installation Guide for instructions.) ___________
Have you ensured that there are no other versions of PPP running on each endpoint. (If there are, disable them, as explained in their documentation.) ___________
Have you determined which IP addresses to use for all computers involved in the PPP link? __________
List the host names and IP addresses of these machines here. ___________ ___________ ___________ ___________
Write the name and IP address of the dial-in server (if applicable). ___________
Write the name of the network interface that you need to use. ___________
This chapter contains procedures and information for configuring PPP. The example used in the text is for the configuration with both types of PPP links-- remote hosts and their multipoint dial-in server. Chapter 11, Tailoring Your PPP Link, contains information for setting up other PPP configuration types.
You have completed the preinstallation activities noted in Chapter 8, Preparing Your PPP Configuration. 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. On each endpoint involved in the link, type:
# pkginfo | grep ppp |
If PPP is installed, the following package names are displayed:
SUNWpppk # Contains kernel modules SUNWapppu # Contains the link manager and login service SUNWappp # Contains configuration files |
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 in the preceding screen box.
Refer to System Administration Guide 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 9-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 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 and prepare to edit the /etc/inet/hosts file.
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 9-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.
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 9-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 12, UUCP Databases and Programs, describes these files in detail.
The /etc/uucp/Devices file must contain entries for every communications device that a particular host uses or must know about. For example, if a machine uses a US Robotics V.32bis modem as part of the PPP link, you should ensure that /etc/uucp/Devices has an entry similar to the following:
# Use these if you have a USrobotics V.32bis modem on Port B. ACUEC cua/b - 9600 usrv32bis-ec ACUEC cua/b - 19200 usrv32bis-ec ACUEC cua/b - 38400 usrv32bis-ec |
Be sure that the Devices file on each PPP endpoint machine has an entry describing its modem. For more information about /etc/uucp/Devices, refer to "/etc/uucp/Devices File".
The /etc/uucp/Dialers file must have an entry describing the conversation with the modem attached to your PPP endpoint machine. Here is a sample entry for a US Robotics V.32bis modem that is part of a PPP link:
usrv32bis-ec =,-, "" \dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2\r\c OK\r \EATDT\T\r\c CONNECT\s14400/ARQ STTY=crtscts |
The first parameter in the entry, usrv32bis, corresponds to the last parameter in the /etc/uucp/Devices file, linking them together. The remainder of the entry describes the characters that the modem sends, those that it expects to receive, and so on. Table 12-6 defines the control codes used in the Dialers file.
Be sure that an entry is in the Dialers file for the modem attached to each dial-out endpoint on your link. If you are unsure of the correct conversation for a particular modem, refer to the System Administration Guide and the operating manual for the modem.
The /etc/uucp/Systems file contains entries for every machine to which the local host can dial out. Information in an entry might include the remote host's phone number, the line speed, and so on. Here is an example that host nomadb in Figure 9-1 might have for its dial-in server:.
nubian-ppp Any ACUEC 38400 5551212 "" P_ZERO "" \r\n\c login:-\r\n\c-login:-\r\n\c-login:- EOT-login: bnomad password: Secret-Password |
The first field gives the server's host name, nubian-ppp, a value used by the asppp.cf file keyword peer_system_name. ACUEC and 38400 refer to the device and speed, and are used to select an entry from the /etc/uucp/Devices file. The remaining information includes the phone number of the machine that nomadb wants to dial in to, the login name that nomadb is using to log in, and so on. "/etc/uucp/Systems File" fully defines the parameters you need to supply to the Systems file.
On each remote host in your configuration, you must add an entry for its dial-in server. You can have additional entries in the /etc/uucp/Systems file for other machines to which the host can dial out for UUCP communications and for other PPP dial-in servers.
If the dial-in server also directly dials out to remote hosts, you must add entries to its Systems file describing each of these remote hosts.
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 9-1, dial-in server nubian might have the following entries in its /etc/passwd file:
bin:x:2:2::/bin: sys:x:3:3::/bin: uucp:x:5:5::/usr/lib/uucp: nuucp:x:9:9::/var/spool/uucppublic:/usr/lib/uucp/uucico news:x:6:6::/var/spool/news:/bin/csh sundiag:x:0:1:System Diagnostic:/usr/diag/sundiag:/usr/diag/sundiag/sundiag lily:x:20:99:Dial-in Operator:/home/nubian/lily:/bin/csh nomada:x:21:99:R. Burton:/:/usr/sbin/aspppls nomadb:x:22:99:T. Sherpa:/:/usr/sbin/aspppls nomadc:x:23:99:S. Scarlett:/:/usr/sbin/aspppls |
Refer to System Administration Guide 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.
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.
The basic asppp.cf configuration file must contain at least two main sections: an ifconfig line and at least one path section. It can also contain a defaults section, which you use when you want to set the default values for an endpoint. (Refer to Chapter 11, Tailoring Your PPP Link, for a description of keywords used in the defaults section.)
Example 9-1 shows a basic configuration file such as you would create for a remote host to establish a point-to-point link with a dial-in server.
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 |
The asppp.cf file must contain an ifconfig section with this syntax:
ifconfig interface-number plumb local-machine remote-machine up
Here is a description of the fields:
ifconfig - Tells the link manager to run the ifconfig command and begin configuring the PPP interface.
interface-number - Identifies the PPP interface ipdptpn for a point-to-point link or ipdn for a multipoint link. (Replace the n with the number of the interface.)
plumb - Option of ifconfig that enables IP to recognize the interface.
local-machine - Gives the name of the local endpoint, which can be the local host name or IP address.
remote-machine - Gives the name of the remote endpoint, which can be the remote host name or IP address.
up - Option of ifconfig that marks the interface just described as "up".
The link manager first runs the ifconfig command on the local machine to configure the ipdptp0 point-to-point interface. The zero in ipdptp0 gives the device number of the interface. The plumb option performs various activities necessary for IP to recognize the ipdptp0 interface. nomada is the name of the local host. nubian-ppp is the name of the dial-in server to which nomada connects through the point-to-point link. The ifconfig option up marks the ipdptp0 interface as up.
For more information about ifconfig, see Chapter 10, Troubleshooting PPP, and the ifconfig(1M) man page.
The path section of the configuration file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. At a minimum the path section should contain the following lines:
path interface interface-number peer_system_name endpoint-name |
This keyword defines the PPP interface (either ipdptpn or ipdn). In Example 9-1, the following information appears in the path section:
interface ipdptp0 peer_system_name nubian-ppp |
The interface keyword identifies ipdptp0 as the point-to-point interface that local endpoint nomada uses to communicate with the remote endpoint in the manner described in this path section. It associates the peer_system_name with the interface.
On a dial-out machine such as a remote host, the peer_system_name keyword takes the host name of the remote endpoint as its argument. This is the name of the remote endpoint given in /etc/uucp/Systems. The name need not be the same as the host name on the corresponding ifconfig line.
The argument to the peer_system_name keyword for a dial-in server has a different value. See "Configuration File for Multipoint Dial-in Server" for details.
In Example 9-1, peer_system_name identifies dial-in server nubian-ppp as the remote endpoint at the other end of this link. When the link manager reads the asppp.cf file, it then looks for the entry for nubian-ppp in the /etc/uucp/Systems file. (Recall that the Systems file contains information about how to set up communications with the remote endpoint, including that machine's telephone number. Refer to "Updating /etc/uucp/Systems for PPP".)
The inactivity_timeout keyword is optional. It tells the link manager that the link can remain inactive for the interval designated. When that interval is passed, the link manager knows to automatically disconnect the link. The default interval is two minutes; you do not have to use inactivity_timeout unless you require a different inactivity interval.
You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate. Chapter 11, Tailoring Your PPP Link, has complete information about these keywords.
The asppp.cf configuration file for a multipoint dial-in server contains the same basic sections as that for a point-to-point link: an ifconfig section, at least one path section, and, if desired, a defaults section.
Example 9-2 shows a configuration file for the dial-in server nubian introduced in Figure 9-1.
ifconfig ipd0 plumb nubian-ppp up path interface ipd0 peer_system_name tamerlane # The user name this remote # machine logs in with when it # dials this server peer_ip_address nomada # nomada is a remote machine that # dials in to this server # nomadb is another remote machine that dials in to nubian path interface ipd0 peer_system_name lawrence peer_ip_address nomadb # nomadc is another remote machine that dials in to nubian path interface ipd0 peer_system_name azziz peer_ip_address nomadc |
The ifconfig section for a multipoint dial-in server has a slightly different syntax than that for a point-to-point link. This syntax is:
ifconfig ipdn plumb server-name up
The major difference is that no destination end points are listed as arguments to ifconfig. Instead, the link manager picks up this information from the path section of the asppp.cf file.
In Example 9-2, the link manager first runs the ifconfig command on the dial-in server to configure multipoint interface ipd0. The zero in ipd0 gives the device number of the interface. The option plumb performs various activities necessary for IP to recognize the ipd0 interface. The ifconfig option up marks interface ipd0 as up.
You may have to supply a netmask + parameter on the ifconfig line if you use subnetting.
The path section of the asppp.cf file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. However, on a multipoint dial-in server, you can include more than one path section. Additionally, some of the arguments to the keywords are used differently with multipoint links.
path interface interface-number peer_system_name endpoint-username peer_ip_address endpoint-hostname |
You need to define a path section for each nomadic endpoint with which the dial-in server can establish connections.
For a multipoint dial-in server, the interface keyword defines the PPP interface ipdn. You must specify the same PPP interface in the path section for every endpoint that communicates with the server through this interface.
The peer_system_name keyword takes a slightly different argument for a dial-in machine than a dial-out machine. For a dial-in server, this argument is the login name used by the remote host when it tries to establish communications with the server. This user name must already be present in the server's /etc/passwd file. When the login service reads this name, it verifies the user name in the /etc/passwd and /etc/shadow files enabling communications.
In this excerpt from Example 9-2:
path interface ipd0 peer_system_name scarlett peer_ip_address nomadc |
the argument to peer_system_name is scarlett, indicating that when nomadc logs in to nubian-ppp, it uses the login name scarlett.
The peer_ip_address keyword is required for multipoint links. It takes the host name or IP address of the remote endpoint as its argument. The example above uses the host name nomads as the argument to keyword peer_ip_address.
You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate. Refer to Chapter 11, Tailoring Your PPP Link, for a complete list of keywords.
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.
There are no other format requirements for the placement of the keywords in the file.
Become superuser on one endpoint machine and 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.
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".
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.
# 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 Chapter 10, Troubleshooting PPP, for information on troubleshooting and problem solving.
This chapter is organized as a series of checks to make after you have configured PPP on your network. Thereafter, whenever you have trouble communicating over the PPP link, you can use PPP diagnostics to help troubleshoot problems.
In summary, you should do these checks in the following order:
Hardware
Interface status
Connectivity
Network interface activity
Local routing tables
Permissions
Packet flow
If PPP passes all the tests, you should be able to use TCP and UDP services such as rlogin, telnet, and ftp over the link. If the link still fails, turn on PPP diagnostics for assistance in troubleshooting.
The next sections describe these checks in detail.
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 10-1 shows sample output from ifconfig for PPP links that are running.
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 10-1 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:
# 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 follow, to check that packets are being sent and received correctly:
# netstat -i |
Refer to "netstat Command" and the netstat(1M) man page.
Use the netstat command to display the local routing tables:
# netstat -r |
The following is sample output:
Routing tables Destination Gateway Flags Refcnt 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 there is a routing table entry 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:
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 observe their contents. Example 10-3 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 and 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.
When a PPP link runs correctly, the asppp.log file includes diagnostic information in addition to its normal output. This section explains what the diagnostic messages mean. If your output is different, refer to RFC 1331.
This section contains messages that occur as the local host sends configuration information to the modem, and then as the modem tries to dial the remote host. These initial activities are actually handled by the UUCP daemon. You might think of them as the UUCP portion of asynchronous PPP communications. (Refer to Chapter 12, UUCP Databases and Programs, for complete details on UUCP.)
The two messages below should always appear at the beginning of the session. They indicate that the aspppd daemon has started successfully.
11:53:33 Link manager (1057) started 04/14/94 11:53:33 parse_config_file: Successful configuration |
The next line indicates that a packet was routed to the ipdptp0 interface on the local host. It helps you to determine if a dial-out is occurring correctly. For example, if you tried to ping the remote machine and this message isn't in asppp.log, the packet was lost, probably due to a routing problem.
Next, UUCP looks for an entry that matches Ppac7 in a chat script in the /etc/uucp/Systems file. It then reports that it found an entry that had a device type ACUTEC. (For more information on the Systems file, refer to "/etc/uucp/Systems File".)
11:53:46 process_ipd_msg: ipdptp0 needs connection conn(Ppac7) Trying entry from '/etc/uucp/Systems' - device type ACUTEC. |
UUCP then finds the dialing information for an ACUTEC dialer in the /etc/uucp/Devices file. When it finds the information, it opens the appropriate serial port on the local host and sets it with a speed of 9600. (For more information on /etc/uucp/Devices, see "/etc/uucp/Devices File".)
Device Type ACUTEC wanted Trying device entry 'cua/a' from '/etc/uucp/Devices'. processdev: calling setdevcfg(ppp, ACUTEC) fd_mklock: ok fixline(8, 9600) gdial(tb9600-ec) calle |
UUCP looks for the entry tb9600 in the /etc/uucp/Dialers file and then sends out these messages.
Trying caller script 'tb9600-ec' from '/etc/uucp/Dialers' expect: ("") |
The host waits a couple of seconds and then sets the registers on the modem. The information shown in the log below is modem-specific. It comes from the /etc/uucp/Dialers file.
got it sendthem (DELAY) APAUSE APAUSE APAUSE T&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M<NO CR>) |
The next lines are the dialog between the modem and the host machine. expect (OK^M) means that the host expects the modem to send an "okay." The words got it at the end of the second line indicate that the host got the "okay" message from the modem.
expect: (OK^M) AAAT&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M^M^JOK^Mgot it |
Next, the host sends the string below to the modem, which does the actual dialing. The phone number in the second line is retrieved from the entry for the remote host in the /etc/uucp/Systems file.
sendthem (ECHO CHECK ON A^JATTDDTT99003300887744^M^M<NO CR>) |
The line beginning with expect indicates that the local host expects to get a response from the modem at a speed of 9600 bps. The next line indicates that the modem responded.
expect: (CONNECT 9600) ^M^JCONNECT 9600got it |
This line indicates that hardware flow control has started on the link. The host obtains flow control information from the /etc/uucp/Dialers file.
STTY crtscts |
In the next series of messages, the local host waits for the remote host to send it a standard UNIX login prompt.
getty ret 8 expect: ("") got it sandiest (^J^M) expect: (login:) |
The next messages indicate that the local host has received the login prompt from the remote. It then retrieves the appropriate login sequence from the chat script in the /etc/uucp/Systems entry for the remote host. This sequence is Ppong^M, which is required for login by the remote host.
^M^J^M^Jlogin:got it sendthem (Ppong^M) |
In these messages, the local host waits for the ssword prompt from the remote host. Upon receipt of the prompt, the local host sends the password retrieved from the chat script in the /etc/uucp/Systems entry for the remote host.
expect: (ssword:) login: Ppong^M^JPassword:got it |
The following messages indicate that dialing and modem connection completed successfully.
sendthem (ppptest1^M) call cleanup(0)^M |
At this point, PPP communications start, as the link between local and remote hosts is now established.
The first lines in this part of the session constitute a configuration request (Config-Req). This is the first PPP packet sent to the remote host. The configuration request is one example of a Link Control Protocol (LCP) packet. It requests that configuration be set up and then sets up the PPP link between endpoint machines. Example 10-4 shows a sample configuration request.
11:54:20 004298 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4c LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
Here is a description of the configuration request shown in Example 10-4.
11:54:20 - Time stamp field, indicating the time when the packet was sent
004298 - Number of the packet
ipdptp0 - Network interface used
SEND PPP ASYNC - Indicates that the modem is sending asynchronous PPP
29 Octets - Amount of data the host sent
LCP - Packet type to send
ID=4c - Identifier associated with the packet; it is actually part of the packet
LEN=24 - Length of the LCP part of the packet
The remaining items are a list of options to be negotiated between hosts.
MRU=1500 - Maximum Receive Unit (MRU), the largest packet size the calling host can receive from the remote host
ACCM=00000000 - Asynchronous Character Map (ACCM), the mask sent to the remote host that tells what control characters to escape on transmission
MAG#=69f4f5b2 - Magic number field; used for loopback detection mechanism
ProtFCOMP AddrCCOMP - Asks for the remote host to compress certain parts of the frame header (protocol field, address field).
The next lines are reporting invalid PPP packets. They come from the remote host, which is sending out UNIX text. This does not indicate a problem with PPP.
11:54:20 004299 ipdptp0 RECEIVE {Invalid ppp packet}PPP ASYNC 7 Octets [BAD FCS] {Unrecognized protocol: 1} 11:54:20 004299 ipdptp0 RECEIVE PPP ASYNC 73 Octets [BAD FCS] {Unrecognized protocol: 880a} |
In these packets, the local host receives the remote host's request for configuration, then sends out another configuration request. The packets are identical except for their ID fields. The ID field helps to distinguish between the two packets.
11:54:21 004301 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004302 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
In this packet, the local host acknowledges the remote request by sending it a configuration acknowledgment (Config-ACK).
11:54:21 004303 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
The local host receives a configuration request (Config-Req) from the remote host.
11:54:21 004304 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
In these packets, the local host acknowledges the second packet sent by the remote host and receives the remote host's acknowledgment.
11:54:21 004305 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004306 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- ACK ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
Here the local host negotiates parameters about IP transmission. LEN=16 gives the packet size. VJCOMP indicates Van Jacobsen header compression. IPADDR is followed by the calling host's IP address.
11:54:21 004307 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- Req ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
This packet indicates that the local host has received IP configuration from the remote host, including its IP address.
11:54:22 004308 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-Req ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 |
The local host sends this ACK to the remote host and receives an ACK from the remote host.
11:54:22 004309 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- ACK ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 11:54:22 004310 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-ACK ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
The first message below indicates that IP has started on the link. The next message indicates that the local host is sending IP traffic over the link.
11:54:22 start_ip: IP up on interface ipdptp0, timeout set for 120 seconds 11:54:24 004311 ipdptp0 SEND PPP ASYNC 89 Octets IP_PROTO |
In the first message below the local host receives IP traffic from the remote host. The subsequent messages indicate that the interface was disconnected because of an idle time-out.
11:54:25 004312 ipdptp0 RECEIVE PPP ASYNC 89 Octets IP_PROTO 11:56:25 process_ipd_msg: interface ipdptp0 has disconnected 11:56:25 disconnect: disconnected connection from ipdptp0 |
The next messages begin the termination sequence. The first message indicates that the remote host has sent a packet to terminate the IP layer. The second is the local host's acknowledgment of the request to terminate.
11:56:25 004313 ipdptp0 RECEIVE PPP ASYNC 9 Octets IP_NCP Term- REQ ID=38 LEN=4 11:56:25 004314 ipdptp0 SEND PPP ASYNC 9 Octets IP_NCP Term-ACK ID=38 LEN=4 |
The local host receives a request to terminate the LCP layer. The second message is an acknowledgment of the request, causing a graceful shutdown.
11:56:25 004315 ipdptp0 RECEIVE PPP ASYNC 9 Octets LCP Term-REQ ID=39 LEN=4 11:56:25 004316 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-ACK ID=39 LEN=4 |
This message indicates that the link has closed.
11:56:29 004317 ipdptp0 PPP DIAG CLOSE |
This chapter contains information you need to configure PPP links less commonly used than the basic links described in Chapter 9, Configuring PPP. The text includes instructions for configuring two types of PPP links: the dial-in server with dynamic point-to-point links and the virtual network, which uses multipoint links. The chapter concludes with tables listing all available keywords for the asppp.cf configuration file.
A dial-in server with a dynamic point-to-point link gives your site all the advantages of point-to-point communications. Chapter 7, Understanding 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 sample configuration shown in Figure 11-1 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 9-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.
You must add host information to the /etc/inet/hosts file for each machine that use the dynamically allocated PPP link. The IP addresses for the PPP endpoints should follow these conventions:
For the dial-in server, you must use the IP address of the server's primary network interface (for example le0 or smc0) as the address of the dynamic link.
For a dynamic link, you don't need to assign an IP address to each remote host (as you would for a static link), but you do need to assign a remote IP address to each point-to-point IP interface on the server. The number of IP interfaces you can use is equal to the number of modems your server is connected to. For example, if you have three modems, you need three point-to-point IP interfaces and three IP addresses
You must include a dummy IP address for the ifconfig command to work properly on the client. This address acts as a placeholder for the local IP address assigned to the client IP interface when PPP is started.
There are no restrictions on the remote IP addresses that can be assigned to the IP interfaces, but, for clarity, it is probably best to include only IP addresses belonging to the same subnet.
You must update the hosts database on all machines involved in the dynamic-link configuration.
When configuring the hosts databases on the remote machines, do the following:
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 11-1, 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:
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 entries for any remote hosts they are permitted to communicate with.
The next steps in the configuration process involve editing the /etc/passwd file and the /etc/shadow file. Edit these files for the dynamic-link configurations just as you would for the remote host-to-multipoint dial-in server configuration. Refer to "Modifying the /etc/passwd File" for information regarding the /etc/passwd and /etc/shadow files.
The asppp.cf configuration file for a dynamic-link configuration must contain information about remote hosts and the interfaces to use for the PPP link. After the dial-in server boots, its link manager uses this information to establish communications whenever the server is called by a remote endpoint.
The asppp.cf configuration file for a remote host is the same as the one described in "Parts of Basic Configuration File", except for the addition of the parameter negotiate_address:
ifconfig ipdptp0 plumb dummy mojave up path interface ipdptp0 peer_system_name mojave-ppp connectivity_timeout 300 negotiate_address on |
The negotiate_address parameter indicates whether or not local IP address assignment is obtained through negotiation and assigned dynamically. If set to on, the IP address supplied by the server is used as the client's local address for the duration of the connection.
When the dial-in server receives an incoming packet, the link manager reads the path sections of its configuration file to identify the remote endpoint and determine the interface to use. The configuration file shown in Example 11-1 does not contain an interface keyword. Instead, the link manager uses interface information established in the defaults section.
The asppp.cf configuration file for a dial-in server with dynamically allocated links might resemble Example 11-1:
ifconfig ipdptp0 plumb mojave clienta down ifconfig ipdptp1 plumb mojave clientb down ifconfig ipdptp2 plumb mojave clientc down # This means grab whatever interface is available (not in use) defaults interface ipdptp* # Each path specifies a machine that might dial up / log # in to this server path peer_system_name tamerlane # nomada uses the login name # tamerlane path peer_system_name lawrence # nomadb uses the name lawrence # for login path peer_system_name nomadc |
The ifconfig section for a dial-in server with a dynamically allocated link has the syntax:
ifconfig ipdptpn plumb server-name client-address down
Example 11-1 contains three ifconfig lines, each initializing a point-to-point interface.
ifconfig ipdptp0 plumb mojave clienta down ifconfig ipdptp1 plumb mojave clientb down ifconfig ipdptp2 plumb mojave clientc down |
When you configure a dynamically allocated link, you might want to include a defaults section in the asppp.cf file. This section sets the defaults for the value replacing keyword, wherever keyword subsequently appears in the asppp.cf file. The syntax for the defaults section is:
default keyword |
Example 11-1 uses the keyword interface to define the interface as ipdptp*, indicating a dynamic link. The asterisk wildcard tells the link manager to use any available ipdptp interface defined in the ifconfig section. Thus the link manager on server mojave uses either ipdptp0, ipdptp1, or ipdptp2--whichever is the first interface configured "down" that it finds.
The configuration file for the server with dynamic links must contain path sections for every remote host permitted to establish connections with the server. The path section has the following syntax: .
path peer_system_name endpoint-username |
No interface keyword has been defined in the path section because this value is defined in the defaults section.The peer_system_name keyword has the same meaning here as it does in the configuration file for the multipoint server. See "path Section for Multipoint Dial-in Server" for more information.
You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate, including the use of security keywords as explained in "Configuration Keywords".
Virtual networks consist of a group of standalone computers, each in an isolated location, that can connect to each other through PPP multipoint links. "Virtual Networks" introduces virtual network concepts. This section explains how to configure a virtual network.
The network shown in Figure 11-2 consists of three isolated computers. Each member of the network connects to the other members of the network through a multipoint PPP link. Therefore, to create such a network, you (and perhaps other network administrators at the remote location) have to configure a multipoint PPP link on each participating host.
You use the same generic process for configuring multipoint links as you do for configuring a multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the virtual network has its own set of issues and requires you to configure each host in the network accordingly.
You must add host information to the /etc/hosts file for each machine in the virtual network. When typing the IP addresses used for the PPP endpoints:
Designate a PPP-specific IP address for its point-to-point link. Note that if the machine was not previously configured in a physical network, you must create an IP address for the PPP link. This address becomes the host's primary network interface.
Create a network number for the virtual network. See "Assigning a Network Number to the PPP Link" for more information.
The first step in the configuration process involves updating the hosts and networks databases with information about your virtual network.
The /etc/inet/hosts file on each machine must contain the addressing information for every member of the network that this host has permission to access. For example, each host in the network in Figure 11-2 would have this information:
# Internet host table # 127.0.0.1 localhost loghost 192.41.47.15 nomada 192.41.47.20 nomadb 192.41.47.12 nomadc |
Since the virtual network requires a unique IP address, you must type this address in the networks database. For example, the network shown in Figure 11-2 has the number 192.41.47. Moreover, if the hosts on the network need to communicate with other networks, you should register the network with the InterNIC addressing authority. See Chapter 4, Configuring TCP/IP on the Network, for information on editing the networks database.
Each host on the virtual network must have an entry with the network's address in the /etc/inet/networks file. For example, each host on network 192.41.47 might have the following in /etc/inet/networks:
# Internet networks # # arpanet 10 arpa # ucb-ether 46 ucbether # # local networks loopback 127 ppp 192.41.47 #remote sales offices |
The next steps in the configuration process involve editing the UUCP databases, the /etc/passwd file, and the /etc/shadow file. You edit these files for the machines in the virtual network just as you would for the multipoint dial-in server configuration. Refer to "Editing UUCP Databases" for UUCP-related information and "Modifying the /etc/passwd File" for information regarding the passwd file.
The configuration file for a local machine on a virtual network must contain information about all remote hosts on the network that the local host can access. Moreover, each machine on the virtual network must be configured for both dial-in and dial-out functions. After the local machine boots, its link manager reads the asppp.cf file to establish communications.
Example 11-2 shows a configuration file such as you would set up for nomada on a virtual network 192.41.47.
# /etc/asppp.cf for hosta ifconfig ipd0 plumb nomada netmask + up defaults interface ipd0 path peer_ip_address nomadb peer_system_name lawrence # name machine logs in with path peer_ip_address nomadc peer_system_name azziz |
Example 11-3 shows a configuration file such as you would set up for nomadb on virtual network 192.41.47.
# /etc/asppp.cf for nomadb ifconfig ipd0 plumb nomadb netmask + up defaults interface ipd0 path peer_ip_address nomada peer_system_name tamerlane # name the machine logs in with path peer_ip_address nomadc peer_system_name azziz |
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 do authentication.
Table 11-1 Authenticator Keywords and Associated Strings
require_authentication chap |
|
---|---|
chap_peer_secret |
|
chap_peer_name |
Table 11-2 Peer Keywords and Associated Strings
will_do_authentication chap |
|
---|---|
chap_secret |
|
chap_name |
On the server, become superuser and prepare to edit the /etc/asppp.cf file.
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 11-3 to see what each keyword specifies. Examples can be found in Example 11-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.
You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 11-3 to see what each keyword specifies. Examples can be found starting with Example 11-4.
Either server or client can require authentication or offer to do authentication.
If PAP and CHAP are both present, the authenticator first tries CHAP. If that fails, the link is terminated. The authenticator will not try PAP.
The default value for PAP and CHAP authentication keywords is off. The syntax for keywords is:
require_authentication off | pap[chap] | chap[pap] will_do_authentication off | pap[chap] | chap[pap] |
If you fail to specify pap_id and pap_password or pap_peer_id and pap_peer_password keywords and values for the associated path, the corresponding values are set to the NULL string.
You must specify chap_name,chap_secret, chap_peer_secret and chap_peer_name keywords and values for that path.
Example 11-4 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 |
Example 11-5 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 |
Example 11-6 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 handing them over in person.
This section describes the configuration keywords available for the asppp.cf configuration file and the values you must define for them. Most of these keywords are optional. The required ones are indicated. For further explanations of the keywords, refer to RFCs 1331, 1332, 1333, and 1334.
Table 11-4 lists required keywords that must appear in all asppp.cf configuration files.
Table 11-4 Required Keywords for asppp.cf
Keywords |
Value Definitions |
---|---|
Tells the link manager to run the ifconfig command with the values supplied by parameters. See "ifconfig Section of the asppp.cf File", "ifconfig Section for Multipoint Dial-in Server", and the ifconfig(1M) man page for more information. |
|
Specifies the beginning of the token sequences that are grouped together as attributes of this (current) path. The collection of attributes comprising the current path are terminated by the occurrence of a subsequent path keyword, defaults keyword, or by the end-of-file character. |
|
Specifies either an ipdptp (static point-to-point), ipdptp* (dynamic point-to-point), or ipd (multipoint) device for each interface in your network. For ipdptpn and ipdn, this keyword associates the specific interface defined by n with the current path. n must be a non-negative integer. It matches the interface defined in the path section with the interface stated in the ifconfig section.
For the ipdptp* interface, the * indicates that the interface will match any point-to-point interface that is configured as "down." |
|
On dial-out machines, specifies the hostname of the remote endpoint that the local machine wants to call. This is the same as the system name in the /etc/uucp/Systems file. Associates the remote system name with the current path. This name is used to look up modem- and peer-specific information for outbound connections in the /etc/uucp/Systems file. On dial-in machines, this specifies the username that remote machines use when logging in to the dial-in machine. The appropriate path is determined by matching username with the login name that was used to obtain the connection. |
|
Specifies the destination host address. It is required only for multipoint links. This address is associated with the current path. The value is ignored if the path specifies a point-to-point interface. The address format can be dotted decimal, hexadecimal, or symbolic. |
Table 11-5 contains optional keywords for asppp.cf that you can use to further define your PPP configuration.
Table 11-5 Optional Keywords for asppp.cf