System Administration Guide: Network Services

Part V Serial Networking Topics

This section about serial networking provides overview, task, and reference information for PPP and UUCP.

Chapter 15 Solaris PPP 4.0 (Overview)

This section covers serial networking topics. Serial networking refers to the use of a serial interface, such as an RS-232 or V.35 port, to connect two or more computers for data transfer. Unlike LAN interfaces, such as Ethernet, these serial interfaces are used to connect systems that are separated by large distances. PPP (Point-to-Point Protocol) and UUCP (UNIX-to-UNIX CoPy) are distinct technologies that can be used to implement serial networking. When a serial interface is configured for networking, it is made available for multiple users, in much the same way as any other network interface, such as Ethernet.

This chapter introduces Solaris PPP 4.0. This version of PPP enables two computers in different physical locations to communicate with each other by using PPP over a variety of media. Starting with the Solaris 9 release, Solaris PPP 4.0 is included as part of the base installation.

The following topics are discussed:

Solaris PPP 4.0 Basics

Solaris PPP 4.0 implements the Point-to-Point Protocol (PPP), a data link protocol, which is a member of the TCP/IP protocol suite. PPP describes how data is transmitted between two endpoint machines, over communications media such as telephone lines.

Since the early 1990s, PPP has been a widely used Internet standard for sending datagrams over a communications link. The PPP standard is described in RFC 1661 by the Point-to-Point Working Group of the Internet Engineering Task Force (IETF). PPP is commonly used when remote computers call an Internet service provider (ISP) or a corporate server that is configured to receive incoming calls.

Solaris PPP 4.0 is based on the publicly available Australian National University (ANU) PPP–2.4 and implements the PPP standard. Both asynchronous and synchronous PPP links are supported.

Solaris PPP 4.0 Compatibility

Various versions of standard PPP are available and in wide use throughout the Internet community. ANU PPP-2.4 is a popular choice for Linux, Tru64 UNIX,and all three major BSD variants:

FreeBSD
OpenBSD
NetBSD

Solaris PPP 4.0 brings the highly configurable features of ANU PPP-2.4 to machines that run the Solaris operating system. Machines that run Solaris PPP 4.0 can easily set up PPP links to any machine that runs an implementation of standard PPP.

Some non-ANU-based PPP implementations that successfully interoperate with Solaris PPP 4.0 include the following:

Solaris PPP, also known as asppp, available with the Solaris 2.4 through Solaris 8 releases
Solstice^TM PPP 3.0.1
Microsoft Windows 98 DUN
Cisco IOS 12.0 (synchronous)

Which Version of Solaris PPP to Use

Starting with the Solaris 9 release, Solaris PPP 4.0 is the PPP implementation that is supported. The Solaris 9 release and the Solaris 10 release do not include the earlier Asynchronous Solaris PPP (asppp) software. For more information, refer to the following:

Chapter 23, Migrating From Asynchronous Solaris PPP to Solaris PPP 4.0 (Tasks)
Solaris 8 System Administrator Collection at http://docs.sun.com

Why Use Solaris PPP 4.0?

If you currently use asppp, consider migrating to Solaris PPP 4.0. Note the following differences between the two Solaris PPP technologies:

Transfer modes

asppp supports asynchronous communications only. Solaris PPP 4.0 supports both asynchronous communications and synchronous communications.
Configuration process

Setting up asppp requires configuring the asppp.cf configuration file, three UUCP files, and the ifconfig command. Moreover, you have to preconfigure interfaces for all users who might log in to a machine.

Setting up Solaris PPP 4.0 requires defining options for the PPP configuration files, or issuing the pppd command with options. You can also use a combination of both the configuration file and command-line methods. Solaris PPP dynamically creates and removes interfaces. You do not have to directly configure PPP interfaces for each user.
Solaris PPP 4.0 features not available from asppp
- MS-CHAPv1 and MS-CHAPv2 authentication
- PPP over Ethernet (PPPoE), to support ADSL bridges
- PAM authentication
- Plug-in modules
- IPv6 addressing
- Data compression that uses Deflate or BSD compress
- Microsoft client-side callback support

Solaris PPP 4.0 Upgrade Path

If you are converting an existing asppp configuration to Solaris PPP 4.0, you can use the translation script that is provided with this release. For complete instructions, refer to How to Convert From asppp to Solaris PPP 4.0.

Where to Go for More Information About PPP

Many resources with information about PPP can be found in print and online. The following subsections give some suggestions.

Professional Reference Books About PPP

For more information about widely used PPP implementations, including ANU PPP, refer to the following books:

Carlson, James. PPP Design, Implementation, and Debugging. 2nd ed. Addison-Wesley, 2000.
Sun, Andrew. Using and Managing PPP. O'Reilly & Associates, 1999.

Web Sites About PPP

Go to the following web sites for general information about PPP:

For technical information, FAQs, discussions about Solaris system administration, and earlier versions of PPP, go to Sun Microsystems' system administrators' resource, http://www.sun.com/bigadmin/home/index.html.
For modem configuration and advice about many different implementations of PPP, refer to Stokely Consulting's Web Project Management & Software Development web site: http://www.stokely.com/unix.serial.port.resources/ppp.slip.html.

Requests for Comments (RFCs) About PPP

Some useful Internet RFCs about PPP include the following:

1661 and 1662, which describe the major features of PPP
1334, which describes authentication protocols, such as Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP)
1332, an informational RFC that describes PPP over Ethernet (PPPoE)

To obtain copies of PPP RFCs, specify the number of the RFC on the IETF RFC web page at http://www.ietf.org/rfc.html.

Man Pages About PPP

For technical details about the Solaris PPP 4.0 implementation, refer to the following man pages:

Also, see the man page for pppdump(1M). You can find the PPP-related man pages by using the man command.

PPP Configurations and Terminology

This section introduces PPP configurations. The section also defines terms that are used in this guide.

Solaris PPP 4.0 supports a number of configurations.

Switched-access, or dial-up, configurations
Hardwired, or leased-line configurations

Figure 15–1 Parts of the PPP Link

The diagram shows the parts of a basic PPP link, which
is further described in the following context.

The previous figure shows a basic PPP link. The link has the following parts:

Two machines, usually in separate physical locations, called peers. A peer could be a personal computer, engineering workstation, large server, or even a commercial router, depending on a site's requirements.
Serial interface on each peer. On Solaris machines, this interface could be cua, hihp, or other interface, depending on whether you configure asynchronous or synchronous PPP.
Physical link, such as a serial cable, a modem connection, or a leased line from a network provider, such as a T1 or T3 line.

Dial-up PPP Overview

The most commonly used PPP configuration is the dial-up link. In a dial-up link, the local peer dials up the remote peer to establish the connection and run PPP. In the dial-up process, the local peer calls the remote peer's telephone number to initiate the link.

A common dial-up scenario includes a home computer that calls a peer at an ISP, configured to receive incoming calls. Another scenario is a corporate site where a local machine transmits data over a PPP link to a peer in another building.

In this guide, the local peer that initiates the dial-up connection is referred to as the dial-out machine. The peer that receives the incoming call is referred to as the dial-in server. This machine is actually the target peer of the dial-out machine and might or might not be a true server.

PPP is not a client-server protocol. Some PPP documents use the terms “client” and “server” to refer to telephone call establishment. A dial-in server is not a true server like a file server or name server. Dial-in server is a widely used PPP term because dial-in machines often “serve” network accessibility to more than one dial-out machine. Nevertheless, the dial-in server is the target peer of the dial-out machine.

Parts of the Dial-up PPP Link

See the following figure.

Figure 15–2 Basic Analog Dial-up PPP Link

The graphic shows a basic dial-up link between Locations
1 and 2, which is described in the following context.

The configuration for Location 1, the dial-out side of the link, is composed of the following elements:

Dial-out machine, typically a personal computer or workstation in an individual's home.
Serial interface on the dial-out machine. /dev/cua/a or /dev/cua/b is the standard serial interface for outgoing calls on machines that run Solaris software.
Asynchronous modem or ISDN terminal adapter (TA) that is connected to a telephone jack.
Telephone lines and services of a telephone company.

The configuration for Location 2, the dial-in side of the link, is composed of the following elements:

Telephone jack or similar connector, which is connected to the telephone network
Asynchronous modem or ISDN TA
Serial interface on the dial-in server, either ttya or ttyb for incoming calls
Dial-in server, which is connected to a network, such as a corporate intranet, or, in the instance of an ISP, the global Internet

Using ISDN Terminal Adapters With a Dial-out Machine

External ISDN TAs have faster speeds than modems, but you configure TAs in basically the same way. The major difference in configuring an ISDN TA is in the chat script, which requires commands specific to the TA's manufacturer. Refer to Chat Script for External ISDN TA for information about chat scripts for ISDN TAs.

What Happens During Dial-up Communications

PPP configuration files on both the dial-out and dial-in peers contain instructions for setting up the link. The following process occurs as the dial-up link is initiated.

User or process on the dial-out machine runs the pppd command to start the link.
Dial-out machine reads its PPP configuration files. The dial-out machine then sends instructions over the serial line to its modem, including the phone number of the dial-in server.
Modem dials the phone number to establish a telephone connection with the modem on the dial-in server.

The series of text strings that the dial-out machine sends to the modem and dial-in server are contained in a file called a chat script. If necessary, the dial-out machine sends commands to the dial-in server to invoke PPP on the server.
Modem attached to the dial-in server begins link negotiation with the modem on the dial-out machine.
When modem-to-modem negotiation is completed, the modem on the dial-out machine reports “CONNECT.”
PPP on both peers enters Establish phase, where Link Control Protocol (LCP) negotiates basic link parameters and the use of authentication.
If necessary, the peers authenticate each other.
PPP's Network Control Protocols (NCPs) negotiate the use of network protocols, such as IPv4 or IPv6.

The dial-out machine can then run telnet or a similar command to a host that is reachable through the dial-in server.

Leased-Line PPP Overview

A hardwired, leased-line PPP configuration involves two peers that are connected by a link. This link consists of a switched or an unswitched digital service leased from a provider. Solaris PPP 4.0 works over any full-duplex, point-to-point leased-line medium. Typically, a company rents a hardwired link from a network provider to connect to an ISP or other remote site.

Comparison of Dial-up and Leased-Line Links

Both dial-up and leased-line links involve two peers that are connected by a communications medium. The next table summarizes the differences between the link types.

Leased Line	Dial-up Line
Always connected, unless a system administrator or power failure takes the leased-line down.	Initiated on demand, when a user tries to call a remote peer.
Uses synchronous and asynchronous communications. For asynchronous communications, a long-haul modem is often used.	Uses asynchronous communications.
Rented from a provider.	Uses existing telephone lines.
Requires synchronous units.	Uses less costly modems.
Requires synchronous ports, which are common on most SPARC systems. However, synchronous ports are not common on x86 systems and newer SPARC systems.	Uses standard serial interfaces that are included on most computers.

Parts of a Leased-Line PPP Link

See the following figure.

Figure 15–3 Basic Leased-Line Configuration

The graphic shows the parts of a leased-line-link, which
are described in the following context.

The leased-line link contains the following parts:

Two peers, each peer at one end of the link. Each peer might be a workstation or server. Often the peer functions as a router between its network or the Internet, and the opposite peer.
Synchronous interface on each peer. Some machines that run Solaris software require you to purchase a synchronous interface card, such as HSI/P, to connect to a leased line. Other machines, such as UltraSPARC® workstations, have built-in synchronous interfaces.
CSU/DSU synchronous digital unit on each peer, which connects the synchronous port to the leased line.

A CSU might be built-in to the DSU, or owned by you, or leased from a provider, depending on your locale. The DSU gives the Solaris machine a standard synchronous serial interface. With Frame Relay, the Frame Relay Access Device (FRAD) performs the serial interface adaptation.
Leased line, providing switched or unswitched digital services. Some examples are SONET/SDH, Frame Relay PVC, and T1.

What Happens During Leased-Line Communications

On most types of leased lines, peers do not actually dial each other. Rather, a company purchases a leased-line service to connect explicitly between two fixed locations. Sometimes the two peers at either end of the leased line are at different physical locations of the same company. Another scenario is a company that sets up a router on a leased line that is connected to an ISP.

Leased lines are less commonly used than dial-up links, though the hardwired links are easier to set up. Hardwired links do not require chat scripts. Authentication is often not used because both peers are known to each other when a line is leased. After the two peers initiate PPP over the link, the link stays active. A leased-line link remains active unless the line fails, or either peer explicitly terminates the link.

A peer on a leased line that runs Solaris PPP 4.0 uses most of the same configuration files that define a dial-up link.

The following process occurs to initiate communication over the leased line:

Each peer machine runs the pppd command as part of the booting process or another administrative script.
The peers read their PPP configuration files.
The peers negotiate communications parameters.
An IP link is established.

PPP Authentication

Authentication is the process of verifying that a user is who he or she claims to be. The UNIX login sequence is a simple form of authentication:

The login command prompts the user for a name and password.
login then attempts to authenticate the user by looking up the typed user name and password in the password database.
If the database contains the user name and password, then the user is authenticated and given access to the system. If the database does not contain the user name and password, the user is denied access to the system.

By default, Solaris PPP 4.0 does not demand authentication on machines that do not have a default route specified. Thus, a local machine without a default route does not authenticate remote callers. Conversely, if a machine does have a default route defined, the machine always authenticates remote callers.

You might use PPP authentication protocols to verify the identity of callers who are trying to set up a PPP link to your machine. Conversely, you must configure PPP authentication information if your local machine must call peers that authenticate callers.

Authenticators and Authenticatees

The calling machine on a PPP link is considered the authenticatee because the caller must prove its identity to the remote peer. The peer is considered the authenticator. The authenticator looks up the caller's identity in the appropriate PPP files for the security protocol and authenticates or does not authenticate the caller.

You typically configure PPP authentication for a dial-up link. When the call begins, the dial-out machine is the authenticatee. The dial-in server is the authenticator. The server has a database in the form of a secrets file. This file lists all users who are granted permission to set up a PPP link to the server. Think of these users as trusted callers.

Some dial-out machines require remote peers to provide authentication information when responding to the dial-out machine's call. Then their roles are reversed: the remote peer becomes the authenticatee and the dial-out machine the authenticator.

Note –

PPP 4.0 does not prevent authentication by leased-line peers, but authentication is not often used in leased-line links. The nature of leased-line contracts usually means that both participants on the ends of the line are known to each other. Both participants often are trusted. However, because PPP authentication is not that difficult to administer, you should seriously consider implementing authentication for leased lines.

PPP Authentication Protocols

The PPP authentication protocols are Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP). Each protocol uses a secrets database that contains identification information, or security credentials, for each caller that is permitted to link to the local machine. For a detailed explanation of PAP, see Password Authentication Protocol (PAP). For a CHAP explanation, see Challenge-Handshake Authentication Protocol (CHAP).

Why Use PPP Authentication?

Providing authentication on a PPP link is optional. Moreover, though authentication does verify that a peer is to be trusted, PPP authentication does not provide confidentiality of data. For confidentiality, use encryption software, such as IPsec, PGP, SSL, Kerberos, and the Solaris Secure Shell.

Note –

Solaris PPP 4.0 does not implement the PPP Encryption Control Protocol (ECP), which is described in RFC 1968.

Consider implementing PPP authentication in the following situations:

Your company accepts incoming calls from users over the public, switched telephone network.
Your corporate security policy requires remote users to provide authentication credentials when accessing your network through a corporate firewall or when engaging in secure transactions.
You want to authenticate callers against a standard UNIX password database, such as /etc/passwd, NIS, LDAP, or PAM. Use PAP authentication for this scenario.
Your company's dial-in servers also provide the network's Internet connection. Use PAP authentication for this scenario.
The serial line is less secure than the password database on the machine or networks at either end of the link. Use CHAP authentication for this scenario.

Support for DSL Users Through PPPoE

Many network providers and individuals who are working at home use Digital Subscriber Line (DSL) technology to provide fast network access. To support DSL users, Solaris PPP 4.0 includes the PPP over Ethernet (PPPoE) feature. PPPoE technology enables multiple hosts to run PPP sessions over one Ethernet link to one or more destinations.

If one of the following factors applies to your situation, you should use PPPoE:

You support DSL users, possibly including yourself. Your DSL service provider might require users to configure a PPPoE tunnel to receive services over the DSL line.
Your site is an ISP that intends to offer PPPoE to customers.

This section introduces terms that are associated with PPPoE and an overview of a basic PPPoE topology.

PPPoE Overview

PPPoE is a proprietary protocol from RedBack Networks. PPPoE is a discovery protocol, rather than another version of standard PPP. In a PPPoE scenario, a machine that initiates PPP communications first must locate, or discover, a peer that runs PPPoE. The PPPoE protocol uses Ethernet broadcast packets to locate the peer.

After the discovery process, PPPoE sets up an Ethernet-based tunnel from the initiating host, or PPPoE client, to the peer, the PPPoE access server. Tunneling is the practice of running one protocol on top of another protocol. Using PPPoE, Solaris PPP 4.0 tunnels PPP over Ethernet IEEE 802.2, both of which are data link protocols. The resulting PPP connection behaves like a dedicated link between the PPPoE client and the access server. For detailed information about PPPoE, see Creating PPPoE Tunnels for DSL Support.

Parts of a PPPoE Configuration

Three participants are involved in a PPPoE configuration: a consumer, a telephone company, and a service provider, as the following figure shows.

Figure 15–4 Participants in a PPPoE Tunnel

The figure shows how PPPoE is implemented at an enterprise,
a telephone company, and a service provider.

PPPoE Consumers

As system administrator, you might assist consumers with their PPPoE configurations. One common type of PPPoE consumer is an individual who needs to run PPPoE over a DSL line. Another PPPoE consumer is a company that purchases a DSL line through which employees can run PPPoE tunnels, as illustrated in the previous figure.

The main reason for a corporate consumer to use PPPoE is to offer PPP communications through a high-speed DSL device to a number of hosts. Often, a single PPPoE client has an individual DSL modem. Or, a group of clients on a hub might share a DSL modem that is also connected to the hub by an Ethernet line.

Note –

DSL devices are technically bridges, not modems. However, because common practice is to refer to these devices as modems, this guide uses the term “DSL modem.”

PPPoE runs PPP over a tunnel on the Ethernet line that is connected to the DSL modem. That line is connected to a splitter, which, in turn connects to a telephone line.

PPPoE at a Telephone Company

The telephone company is the middle layer of the PPPoE scenario. The telephone company splits the signal that is received over the phone line by using a device that is called a Digital Subscriber Line Access Multiplexer (DSLAM). The DSLAM breaks out the signals onto separate wires, analog wires for telephone service, and digital wires for PPPoE. From the DSLAM, the digital wires extend the tunnel over an ATM data network to the ISP.

PPPoE at a Service Provider

The ISP receives the PPPoE transmission from the ATM data network over a bridge. At the ISP, an access server that runs PPPoE functions as the peer for the PPP link. The access server is very similar in function to the dial-in server that was introduced in Figure 15–2, but the access server does not use modems. The access server converts the individual PPPoE sessions into regular IP traffic, for example Internet access.

If you are a system administrator for an ISP, you might be responsible for configuring and maintaining an access server.

Security on a PPPoE Tunnel

The PPPoE tunnel is inherently insecure. You can use PAP or CHAP to provide user authentication for the PPP link that is running over the tunnel.

Chapter 16 Planning for the PPP Link (Tasks)

Setting up a PPP link involves a set of discrete tasks, which includes planning tasks and other activities that are not related to PPP. This chapter explains how to plan for the most common PPP links, for authentication, and for PPPoE.

The task chapters that follow Chapter 16, Planning for the PPP Link (Tasks) use sample configurations to illustrate how to set up a particular link. These sample configurations are introduced in this chapter.

Topics that are covered include the following:

Overall PPP Planning (Task Map)

PPP requires planning tasks before you actually can set up the link. Moreover, if you want to use a PPPoE tunneling, you first have to set up the PPP link and then provide tunneling. The following task map lists the large planning tasks that are discussed in this chapter. You might need to use only the general task for the link type to be configured. Or you might require the task for the link, authentication, and perhaps PPPoE.

Table 16–1 Task Map for PPP Planning


Task	Description	For Instructions
Plan for a dial-up PPP link	Gather information that is required to set up a dial-out machine or a dial-in server	Planning a Dial-up PPP Link
Plan for a leased-line link	Gather information that is required to set up a client on a leased line	Planning a Leased-Line Link
Plan for authentication on the PPP link	Gather information that is required to configure PAP or CHAP authentication on the PPP link	Planning for Authentication on a Link
Plan for a PPPoE tunnel	Gather information that is required to set up a PPPoE tunnel over which a PPP link can run	Planning for DSL Support Over a PPPoE Tunnel

Planning a Dial-up PPP Link

Dial-up links are the most commonly used PPP links. This section includes the following information:

Planning information for a dial-up link
Explanation of the sample link to be used in Chapter 17, Setting Up a Dial-up PPP Link (Tasks)

Typically, you only configure the machine at one end of the dial-up PPP link, the dial-out machine, or the dial-in server. For an introduction to dial-up PPP, refer to Dial-up PPP Overview.

Before You Set Up the Dial-out Machine

Before you configure a dial-out machine, gather the information that is listed in the following table.

Note –

The planning information in this section does not include information to be gathered about authentication or PPPoE. For details about authentication planning, refer to Planning for Authentication on a Link. For PPPoE planning, refer to Planning for DSL Support Over a PPPoE Tunnel.

Table 16–2 Information for a Dial-out Machine


Information	Action
Maximum modem speed	Refer to documentation that was provided by the modem manufacturer.
Modem connection commands (AT commands)	Refer to documentation that was provided by the modem manufacturer.
Name to use for dial-in server at the other end of the link	Create any name that helps you identify the dial-in server.
Login sequence that was required by dial-in server	Contact the dial-in server's administrator or ISP documentation if dial-in server is at the ISP.

Before You Set Up the Dial-in Server

Before you configure a dial-in server, gather the information that is listed in the following table.

Note –

Table 16–3 Information for a Dial-in Server


Information	Action
Maximum modem speed	Refer to documentation that was provided by the modem manufacturer.
User names of people who are permitted to call the dial-in server	Obtain the names of the prospective users before you set up their home directories, as discussed in How to Configure Users of the Dial-in Server.
Dedicated IP address for PPP communications	Obtain an address from the individual at your company who is responsible for delegating IP addresses.

Example of a Configuration for Dial-up PPP

The tasks to be introduced in Chapter 17, Setting Up a Dial-up PPP Link (Tasks) execute a small company's requirement to let employees work at home a few days a week. Some employees require the Solaris OS on their home machines. These workers also need to log in remotely to their work machines on the corporate Intranet.

The tasks set up a basic dial-up link with the following features:

The dial-out machines are at the houses of employees who need to call the corporate intranet.
The dial-in server is a machine on the corporate intranet that is configured to receive incoming calls from employees.
UNIX-style login is used to authenticate the dial-out machine. Stronger Solaris PPP 4.0 authentication methods are not required by the company`s security policy.

The next figure shows the link that is set up in Chapter 17, Setting Up a Dial-up PPP Link (Tasks).

Figure 16–1 Sample Dial-up Link

Figure shows
the sample link to be used in dial-up
tasks. The following context describes
the sample link.

In this figure, a remote host dials out through its modem over telephone lines to Big Company's Intranet. Another host is configured to dial out to Big Company but currently is inactive. The calls from remote users are answered in the order received by the modem that is attached to the dial-in server at Big Company. A PPP connection is established between the peers. The dial-out machine can then remotely log in to a host machine on the Intranet.

Where to Go for More Information About Dial-up PPP

Refer to the following:

To set up a dial-out machine, see Table 17–2.
To set up a dial-in machine, see Table 17–3.
To get an overview of dial-up links, see Dial-up PPP Overview.
To get detailed information about PPP files and commands, see Using PPP Options in Files and on the Command Line.

Planning a Leased-Line Link

Setting up a leased-line link involves configuring the peer at one end of a switched or unswitched service that is leased from a provider.

This section includes the following information:

Planning information for a leased-line link
Explanation of the sample link that is shown in Figure 16–2

For an introduction to leased-line links, refer to Leased-Line PPP Overview. For tasks about setting up the leased line, see Chapter 18, Setting Up a Leased-Line PPP Link (Tasks).

Before You Set Up the Leased-Line Link

When your company rents a leased-line link from a network provider, you typically configure only the system at your end of the link. The peer at the other end of the link is maintained by another administrator. This individual might be a system administrator at a remote location in your company or a system administrator at an ISP.

Hardware That Is Needed for a Leased-Line Link

In addition to the link media, your end of the link requires the following hardware:

Synchronous interface for your system
Synchronous unit (CSU/DSU)
Your system

Some network providers include a router, synchronous interface, and a CSU/DSU as part of the customer premises equipment (CPE). However, necessary equipment varies, based on the provider and any governmental restrictions in your locale. The network provider can give you information about the unit that is needed, if this equipment is not provided with the leased line.

Information to Be Gathered for the Leased-Line Link

Before you configure the local peer, you might need to gather the items that are listed in the next table.

Table 16–4 Planning for a Leased-Line Link


Information	Action
Device name of the interface	Refer to the interface card documentation.
Configuration instructions for the synchronous interface card	Refer to the interface card documentation. You need this information to configure the HSI/P interface. You might not need to configure other types of interface cards.
(Optional) IP address of the remote peer	Refer to the service provider documentation. Alternatively, contact the system administrator of the remote peer. This information is needed only if the IP address is not negotiated between the two peers.
(Optional) Name of the remote peer	Refer to the service provider documentation. Alternatively, you can contact the system administrator of the remote peer.
(Optional) Speed of the link	Refer to the service provider documentation. Alternatively, you can contact the system administrator of the remote peer.
(Optional) Compression that is used by the remote peer	Refer to the service provider documentation. Alternatively, you can contact the system administrator of the remote peer.

Example of a Configuration for a Leased-Line Link

The tasks in Chapter 18, Setting Up a Leased-Line PPP Link (Tasks) show how to implement the goal of a medium-sized organization (LocalCorp) to provide Internet access for its employees. Currently, the employees' computers are connected on a private corporate intranet.

LocalCorp requires speedy transactions and access to the many resources on the Internet. The organization signs a contract with Far ISP, a service provider, which allows LocalCorp to set up its own leased line to Far ISP. Then, LocalCorp leases a T1 line from Phone East, a telephone company. Phone East puts in the leased line between LocalCorp and Far ISP. Then, Phone East provides a CSU/DSU that is already configured to LocalCorp.

The tasks set up a leased-line link with the following characteristics.

LocalCorp has set up a system as a gateway router, which forwards packets over the leased line to hosts on the Internet.
Far ISP also has set up a peer as a router to which leased lines from customers are attached.

Figure 16–2 Example of a Leased-Line Configuration

Figure shows
an example of a link to be used in
leased-line tasks. The following context
describes the sample link.

In the figure, a router is set up for PPP at LocalCorp. The router connects to the corporate Intranet through its hme0 interface. The second connection is through the machine's HSI/P interface (hihp1) to the CSU/DSU digital unit. The CSU/DSU then connects to the installed leased line. The administrator at LocalCorp configures the HSI/P interface and PPP files. The administrator then types /etc/init.d/pppd to initiate the link between LocalCorp and Far ISP.

Where to Go for More Information About Leased Lines

Refer to the following:

Planning for Authentication on a Link

This section contains planning information for providing authentication on the PPP link. Chapter 19, Setting Up PPP Authentication (Tasks) contains tasks for implementing PPP authentication at your site.

PPP offers two types of authentication, PAP, which is described in detail in Password Authentication Protocol (PAP) and CHAP, which is described in Challenge-Handshake Authentication Protocol (CHAP).

Before you set up authentication on a link, you must choose which authentication protocol best meets your site's security policy. Then, you set up the secrets file and PPP configuration files for the dial-in machines, or callers' dial-out machines, or both types of machines. For information about choosing the appropriate authentication protocol for your site, see Why Use PPP Authentication?.

This section includes the following information:

Planning information for both PAP and CHAP authentication
Explanations of the sample authentication scenarios that are shown in Figure 16–3 and Figure 16–4

For tasks about setting up authentication, see Chapter 19, Setting Up PPP Authentication (Tasks).

Before You Set Up PPP Authentication

Setting up authentication at your site should be an integral part of your overall PPP strategy. Before implementing authentication, you should assemble the hardware, configure the software, and test the link.

Table 16–5 Prerequisites Before Configuring Authentication


Information	For Instructions
Tasks for configuring a dial-up link	Chapter 17, Setting Up a Dial-up PPP Link (Tasks).
Tasks for testing the link	Chapter 21, Fixing Common PPP Problems (Tasks).
Security requirements for your site	Your corporate security policy. If you do not have a policy, setting up PPP authentication gives you an opportunity to create a security policy.
Suggestions about whether to use PAP or CHAP at your site	Why Use PPP Authentication?. For more detailed information about these protocols, refer to Authenticating Callers on a Link.

Examples of PPP Authentication Configurations

This section contains examples of authentication scenarios to be used in the procedures in Chapter 19, Setting Up PPP Authentication (Tasks).

Example of a Configuration Using PAP Authentication

The tasks in Configuring PAP Authentication show how to set up PAP authentication over the PPP link. The procedures use as an example a PAP scenario that was created for the fictitious “Big Company” in Example of a Configuration for Dial-up PPP.

Big Company wants to enable its users to work from home. The system administrators want a secure solution for the serial lines to the dial-in server. UNIX-style login that uses the NIS password databases has served Big Company's network well in the past. The system administrators want a UNIX-like authentication scheme for calls that come in to the network over the PPP link. So, the administrators implement the following scenario that uses PAP authentication.

Figure 16–3 Example of a PAP Authentication Scenario (Working From Home)

The graphic shows
an example PAP authentication scenario
for tasks, as explained in the next
context.

The system administrators create a dedicated dial-in DMZ that is separated from the rest of the corporate network by a router. The term DMZ comes from the military term “demilitarized zone.” The DMZ is an isolated network that is set up for security purposes. The DMZ typically contains resources that a company offers to the public, such as web servers, anonymous FTP servers, databases, and modem servers. Network designers often place the DMZ between a firewall and a company's Internet connection.

The only occupants of the DMZ that is pictured in Figure 16–3 are the dial-in server myserver and the router. The dial-in server requires callers to provide PAP credentials, including user names and passwords, when setting up the link. Furthermore, the dial-in server uses the login option of PAP. Therefore, the callers' PAP user names and passwords must correspond exactly to their UNIX user names and passwords in the dial-in server's password database.

After the PPP link is established, the caller's packets are forwarded to the router. The router forwards the transmission to its destination on the corporate network or on the Internet.

Example of a Configuration Using CHAP Authentication

The tasks in Configuring CHAP Authentication show how to set up CHAP authentication. The procedures use as an example a CHAP scenario to be created for the fictitious LocalCorp that was introduced in Example of a Configuration for a Leased-Line Link.

LocalCorp provides connectivity to the Internet over a leased line to an ISP. The Technical Support department within LocalCorp generates heavy network traffic. Therefore, Technical Support requires its own, isolated private network. The department's field technicians travel extensively and need to access the Technical Support network from remote locations for problem-solving information. To protect sensitive information in the private network's database, remote callers must be authenticated in order to be granted permission to log in.

Therefore, the system administrators implement the following CHAP authentication scenario for a dial-up PPP configuration.

Figure 16–4 Example of a CHAP Authentication Scenario (Calling a Private Network)

The graphic shows
an example CHAP authentication scenario
for tasks, as explained in the previous
and following context.

The only link from the Technical Support network to the outside world is the serial line to the dial-in server's end of the link. The system administrators configure the laptop computer of each field service representative for PPP with CHAP security, including a CHAP secret. The chap-secrets database on the dial-in server contains the CHAP credentials for all machines that are allowed to call in to the Technical Support network.

Where to Go for More Information About Authentication

Choose from the following:

See Configuring PAP Authentication.
See Configuring CHAP Authentication.
See Authenticating Callers on a Link and the pppd(1M) man page.

Planning for DSL Support Over a PPPoE Tunnel

Some DSL providers require you to set up PPPoE tunneling for your site in order to run PPP over the providers' DSL lines and high-speed digital networks. For an overview of PPPoE, see Support for DSL Users Through PPPoE.

A PPPoE tunnel involves three participants: a consumer, a telephone company, and an ISP. You either configure PPPoE for consumers, such as PPPoE clients at your company or consumers in their homes, or you configure PPPoE on a server at an ISP.

This section contains planning information for running PPPoE on both clients and access servers. The following topics are covered:

Planning information for the PPPoE host and access server
Explanation of the PPPoE scenario that is introduced in Example of a Configuration for a PPPoE Tunnel

For tasks about setting up a PPPoE tunnel, see Chapter 20, Setting Up a PPPoE Tunnel (Tasks).

Before You Set Up a PPPoE Tunnel

Your preconfiguration activities depend on whether you configure the client side or server side of the tunnel. In either instance, you or your organization must contract with a telephone company. The telephone company provides the DSL lines for clients, and some form of bridging and possibly an ATM pipe for access servers. In most contracts, the telephone company assembles its equipment at your site.

Before Configuring a PPPoE Client

PPPoE client implementations usually consist of the following equipment:

Personal computer or other system that is used by an individual
DSL modem, which is usually installed by the telephone company or Internet access provider
(Optional) A hub, if more than one client is involved, as is true for corporate DSL consumers
(Optional) A splitter, usually installed by the provider

Many different DSL configurations are possible, which depend on the user or corporation's needs and the services that are offered by the provider.

Table 16–6 Planning for PPPoE Clients


Information	Action
If setting up a home PPPoE client for an individual or yourself, get any setup information that is outside the scope of PPPoE.	Ask the telephone company or ISP for any required setup procedures.
If setting up PPPoE clients at a corporate site, gather the names of users who are being assigned PPPoE client systems. If you configure remote PPPoE clients, you might be responsible for giving users information about adding home DSL equipment.	Ask management at your company for a list of authorized users.
Find out which interfaces are available on the PPPoE client.	Run the `ifconfig -a` command on each machine for interface names.
(Optional) Obtain the password for the PPPoE client.	Ask users for their preferred passwords. Or, assign passwords to the users. Note that this password is used for link authentication, not for UNIX login.

Before Configuring a PPPoE Server

Planning for a PPPoE access server involves working with the telephone company that provides your connection to its data service network. The telephone company installs its lines, often ATM pipes, at your site, and provides some sort of bridging into your access server. You need to configure the Ethernet interfaces that access the services that your company provides. For example, you need to configure interfaces for Internet access, as well as the Ethernet interfaces from the telephone company's bridge.

Table 16–7 Planning for a PPPoE Access Server


Information	Action
Interfaces that are used for lines from data service network	Run the `ifconfig -a` command to identify interfaces.
Types of services to provide from the PPPoE server	Ask management and network planners for their requirements and suggestions.
(Optional) Types of services to provide to the consumers	Ask management and network planners for their requirements and suggestions.
(Optional) Host names and passwords for remote clients	Ask network planners and other individuals at your site who are responsible for contract negotiations. The host names and passwords are used for PAP or CHAP authentication, not for UNIX login.

Example of a Configuration for a PPPoE Tunnel

This section contains an example of a PPPoE tunnel, which is used as an illustration for the tasks in Chapter 20, Setting Up a PPPoE Tunnel (Tasks). Though the illustration shows all participants in the tunnel, you only administer one end, either the client side or server side.

Figure 16–5 Example of a PPPoE Tunnel

The graphic shows
an example of a PPPoE tunnel to be
used in tasks, as explained in the
next context.

In the sample, MiddleCo wants to provide its employees with high-speed Internet access. MiddleCo buys a DSL package from Phone East, which, in turn, contracts with service provider Far ISP. Far ISP offers Internet and other IP services to customers who buy DSL from Phone East.

Example of a PPPoE Client Configuration

MiddleCo buys a package from Phone East that provides one DSL line for the site. The package includes a dedicated, authenticated connection to the ISP for MiddleCo's PPPoE clients. The system administrator cables the prospective PPPoE clients to a hub. Technicians from Phone East cable the hub to their DSL equipment.

Example of a PPPoE Server Configuration

To implement the business arrangement FarISP has with Phone East, the system administrator at FarISP configures the access server dslserve. This server has the following four interfaces:

eri0 – Primary network interface that connects to the local network
hme0 – Interface through which FarISP provides Internet service for its customers
hme1 – Interface contracted by MiddleCo for authenticated PPPoE tunnels
hme2 – Interface contracted by other customers for their PPPoE tunnels

Where to Get More Information About PPPoE

Choose from the following:

See Setting Up the PPPoE Client.
See Setting Up a PPPoE Access Server.
See Creating PPPoE Tunnels for DSL Support, and the pppoed(1M), pppoec(1M), and sppptun(1M) man pages.

Chapter 17 Setting Up a Dial-up PPP Link (Tasks)

This chapter explains the tasks for configuring the most common PPP link, the dial-up link. Major topics include the following:

Major Tasks for Setting Up the Dial-up PPP Link (Task Map)

You set up the dial-up PPP link by configuring modems, modifying network database files, and modifying the PPP configuration files that are described in Table 22–1.

The next table lists the major tasks to configure both sides of a dial-up PPP link. Typically, you configure only one end of the link, either the dial-out machine or dial-in server.

Table 17–1 Task Map for Setting Up the Dial-up PPP Link


Task	Description	For Instructions
1. Gather preconfiguration information	Gather data that is needed prior to setting up the link, such as peer host names, target phone numbers, and modem speed.	Planning a Dial-up PPP Link
2. Configure the dial-out machine	Set up PPP on the machine that makes the call over the link.	Table 17–2
3. Configure the dial-in server	Set up PPP on the machine that receives incoming calls.	Table 17–3
4. Call the dial-in server	Type the `pppd` command to initiate communications.	How to Call the Dial-in Server

Configuring the Dial-out Machine

The tasks in this section explain how to configure a dial-out machine. The tasks use as an example the dial- in-from-home scenario that was introduced in Figure 16–1. You can perform the tasks at your company before passing on the machine to a prospective user. Alternatively, you can instruct experienced users in the setup of their home machines. Anyone setting up a dial-out machine must have root permission for that machine.

Tasks for Configuring the Dial-out Machine (Task Map)

Table 17–2 Task Map for Setting Up the Dial-out Machine


Task	Description	For Instructions
1. Gather preconfiguration information	Gather data that is needed prior to setting up the link, such as peer host names, target phone numbers, and modem speed.	Planning a Dial-up PPP Link
2. Configure the modem and serial port	Set up the modem and serial port.	How to Configure the Modem and Serial Port (Dial-out Machine)
3. Configure the serial-line communication	Configure the characteristics of the transmission across the serial line.	How to Define Communications Over the Serial Line
4. Define the conversation between the dial-out machine and the peer	Gather communications data for use when you create the chat script.	How to Create the Instructions for Calling a Peer
5. Configure information about a particular peer	Configure PPP options to call an individual dial-in server.	How to Define the Connection With an Individual Peer
6. Call the peer	Type the `pppd` command to initiate communications.	How to Call the Dial-in Server

Dial-up PPP Template Files

Solaris PPP 4.0 provides template files. Each template contains common options for a particular PPP configuration file. The next table lists the sample templates that can be used for setting up a dial-up link, and their equivalent Solaris PPP 4.0 files.

Template File	PPP Configuration File	For Instructions
`/etc/ppp/options.tmpl`	`/etc/ppp/options`	`/etc/ppp/options.tmpl` Template
`/etc/ppp/options.ttya.tmpl`	`/etc/ppp/options.ttyname`	`options.ttya.tmpl` Template File
`/etc/ppp/myisp-chat.tmpl`	File with the name of your choice to contain the chat script	`/etc/ppp/myisp-chat.tmpl` Chat Script Template
`/etc/ppp/peers/myisp.tmpl`	`/etc/ppp/peers/peer-name`	`/etc/ppp/peers/myisp.tmpl` Template File

If you decide to use one of the template files, be sure to rename the template to its equivalent PPP configuration file. The one exception is the chat file template /etc/ppp/myisp-chat.tmpl. You can choose any name for your chat script.

Configuring Devices on the Dial-out Machine

The first task for setting up a dial-out PPP machine is to configure the devices on the serial line: the modem and serial port.

Note –

Tasks that apply to a modem usually apply to an ISDN TA.

Before performing the next procedure, you must have done the following.

Installed the Solaris 9 release or Solaris 10 release on the dial-out machine
Determined the optimum modem speed
Decided which serial port to use on the dial-out machine
Obtained the root password for the dial-out machine

For planning information, see Table 16–2.

How to Configure the Modem and Serial Port (Dial-out Machine)

Program the modem.

Even though a variety of modem types is available, most modems are shipped with the correct settings for Solaris PPP 4.0. The following list shows the basic parameter settings for modems that use Solaris PPP 4.0.
- DCD – Follow carrier instructions
- DTR – Set low so that the modem hangs up and puts the modem on-hook
- Flow Control – Set to RTS/CTS for full-duplex hardware flow control
- Attention Sequences – Disable
If you have problems setting up the link and suspect that the modem is at fault, first consult the modem manufacturer's documentation. Also, a number of web sites offer help with modem programming. Finally, you can find some suggestions for clearing modem problems in How to Diagnose Modem Problems.

Attach the modem cables to the serial port on the dial-out machine and to the telephone jack.

Become superuser on the dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Run the /usr/sadm/bin/smc command, as explained in Setting Up Terminals and Modems With Serial Ports Tool (Overview) in System Administration Guide: Advanced Administration. This command opens the Solaris Management Console.

Use the Solaris Management Console to do the following.
1. Select the port where you have attached the modem.
2. Specify modem direction as dial-out only.
  
  You can set up the modem as bidirectional. However, the dial-out-only choice is more secure against possible intruders.
Note –
You can set the baud rate and timeout from /usr/sadm/bin/smc. However, the pppd daemon ignores these settings.

Click Okay to convey the changes.

Configuring Communications on the Dial-out Machine

The procedures in this section show how to configure communications over the serial line of the dial-out machine. Before you can use these procedures, you must have configured the modem and serial port, as described in How to Configure the Modem and Serial Port (Dial-out Machine).

The next tasks show how to enable the dial-out machine to successfully initiate communications with the dial-in server. Communications are initiated as defined in the options in the PPP configuration files. You need to create the following files:

/etc/ppp/options
/etc/ppp/options.ttyname
Chat script
/etc/ppp/peers/peer-name

Solaris PPP 4.0 provides templates for the PPP configuration files, which you can customize to accommodate your needs. Refer to Dial-up PPP Template Files for detailed information about these files.

How to Define Communications Over the Serial Line

Become superuser on the dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Create a file that is called /etc/ppp/options with the following entry:
lock
The /etc/ppp/options file is used for defining global parameters that apply to all communications by the local machine. The lock option enables UUCP-style locking of the form /var/spool/locks/LK.xxx.yyy.zzz.

Note –
If the dial-out machine does not have an /etc/ppp/options file, only the superuser can run the pppd command. However, the /etc/ppp/options can be empty.

For a complete description of /etc/ppp/options, refer to /etc/ppp/options Configuration File.

(Optional) Create a file that is called /etc/ppp/options.ttyname for defining how communications should be initiated from a specific serial port.

The next example shows an /etc/ppp/options.ttyname file for the port with the device name /dev/cua/a.
# cat /etc/ppp/options.cua.a crtscts
The PPP option crtscts tells the pppd daemon to turn on hardware flow control for serial port a.

For more information about the /etc/ppp/options.ttyname file, go to /etc/ppp/options.ttyname Configuration File.

Set the modem speed, as described in How to Set the Modem Speed.

How to Create the Instructions for Calling a Peer

Before the dial-out machine can initiate a PPP link, you must collect information about the dial-in server that is to become the peer. Then, you use this information to create the chat script, which describes the actual conversation between the dial-out machine and the peer.

Determine the speed at which the dial-out machine's modem needs to run.

For more information, see Configuring Modem Speed for a Dial-up Link.

Obtain the following information from the dial-in server's site.
- Server's telephone number
- Authentication protocol that is used, if appropriate
- Login sequence that is required by the peer for the chat script

Obtain the names and IP addresses of name servers at the dial-in server's site.

In a chat script, provide instructions for initiating calls to the particular peer.

For example, you might create the following chat script, /etc/ppp/mychat, to call the dial-in server myserver.

SAY "Calling the peer\n"
        TIMEOUT 10
        ABORT BUSY
        ABORT 'NO CARRIER'
        ABORT ERROR
        REPORT CONNECT
        "" AT&F1&M5S2=255
        TIMEOUT 60
        OK ATDT1-123-555-1234 
        CONNECT \c
        SAY "Connected; logging in.\n"
        TIMEOUT 5
        ogin:--ogin: pppuser
        TIMEOUT 20
        ABORT 'ogin incorrect'
        ssword: \qmypassword
        "% " \c
        SAY "Logged in.  Starting PPP on peer system.\n" 
        ABORT 'not found'
        "" "exec pppd"
        ~ \c

The script contains instructions for calling a Solaris dial-in server that requires a login sequence. For a description of each instruction, refer to Basic Chat Script Enhanced for a UNIX-Style Login. For complete details about creating a chat script, read the section Defining the Conversation on the Dial-up Link.

Note –

You do not invoke the chat script directly. Rather, you use the file name of the chat script as an argument to the chat command, which invokes the script.

If a peer runs Solaris or a similar operating system, consider using the previous chat script as a template for your dial-out machines.

How to Define the Connection With an Individual Peer

Become superuser on the dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Update DNS databases by creating the following /etc/resolv.conf file:
domain bigcompany.com nameserver 10.10.111.15 nameserver 10.10.130.8
domain bigcompany.com

Specifies that the peer's DNS domain is bigcompany.com.

nameserver 10.10.111.15 and nameserver 10.10.130.8

Lists the IP addresses of name servers at bigcompany.com.

Edit the /etc/nsswitch.conf file to have the DNS database searched first for host information.
hosts: dns [NOTFOUND=return] files

Create a file for the peer.

For example, you would create the following file to define the dial-in server myserver:
# cat /etc/ppp/peers/myserver /dev/cua/a 57600 noipdefault defaultroute idle 120 noauth connect "chat -U 'mypassword' -T 1-123-555-1213 -f /etc/ppp/mychat"
/dev/cua/a

Specifies that the device /dev/cua/a should be used as the serial interface for calls to myserver.

57600

Defines the speed of the link.

noipdefault

Specifies that for transactions with peer myserver, the dial-out machine initially has an IP address of 0.0.0.0. myserver assigns an IP address to the dial-out machine for every dial-up session.

idle 120

Indicates that the link must time out after an idle period of 120 seconds.

noauth

Specifies that the peer myserver does not need to provide authentication credentials when negotiating the connection with the dial-out machine.

connect "chat -U 'mypassword' -T 1-123-555-1213 -f /etc/ppp/mychat"

Specifies the connect option and its arguments, including the phone number of the peer, and the chat script /etc/ppp/mychat with calling instructions.

Configuring the Dial-in Server

The tasks in this section are for configuring the dial-in server. The dial-in server is a peer machine that receives the call over the PPP link from the dial-out machine. The tasks show how to configure the dial-in server myserver that was introduced in Figure 16–1.

Tasks for Configuring the Dial-in Server (Task Map)

Table 17–3 Task Map for Setting Up the Dial-in Server


Task	Description	For Instructions
1. Gather preconfiguration information	Gather data that is needed prior to setting up the link, such as peer host names, target phone numbers, and modem speed.	Planning a Dial-up PPP Link
2. Configure the modem and serial port	Set up the modem and serial port.	How to Configure the Modem and Serial Port (Dial-in Server)
3. Configure calling peer information	Set up the user environments and PPP options for every dial-out machine that is permitted to call the dial-in server.	How to Configure Users of the Dial-in Server
4. Configure the serial-line communication	Configure the characteristics of the transmission across the serial line.	How to Define Communications Over the Serial Line (Dial-in Server)

Configuring Devices on the Dial-in Server

The following procedure explains how to configure the modem and serial port on the dial-in server.

Before you do the next procedure, you must have completed the following activities on the peer dial-in server:

Installed the Solaris 9 release or Solaris 10 release
Determined the optimum modem speed
Decided which serial port to use

How to Configure the Modem and Serial Port (Dial-in Server)

Program the modem, as instructed in the modem manufacturer's documentation.

For other suggestions, refer to How to Configure the Modem and Serial Port (Dial-out Machine).

Attach the modem to the serial port on the dial-in server.

Become superuser on the dial-in server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Configure the serial port by using the /usr/sadm/bin/smc command for the Solaris Management Console, as described in Setting Up Terminals and Modems With Serial Ports Tool (Overview) in System Administration Guide: Advanced Administration.

Use the Solaris Management Console to do the following:
1. Select the serial port where you have attached the modem.
2. Specify modem direction as dial-in only.
  
  Note –
  Solaris PPP 4.0 does support bidirectional communications for a modem.
3. Click Okay to convey the changes.

How to Set the Modem Speed

The next procedure explains how to set the modem speed for a dial-in server. For suggestions about speeds to use with Sun Microsystems' computers, see Configuring Modem Speed for a Dial-up Link.

Use the tip command to reach the modem.

Instructions for using tip to set the modem speed are in the tip(1) man page.

Configure the modem for a fixed DTE rate.

Lock the serial port to that rate, using ttymon or /usr/sadm/bin/smc, as discussed in Setting Up Terminals and Modems With Serial Ports Tool (Overview) in System Administration Guide: Advanced Administration.

Setting Up Users of the Dial-in Server

Part of the process of setting up a dial-in server involves configuring information about each known remote caller.

Before starting the procedures in this section, you must have done the following:

Obtained the UNIX user names for all users who are permitted to log in from remote dial-out machines.
Set up the modem and serial line, as described in How to Configure the Modem and Serial Port (Dial-in Server).
Dedicated an IP address to be assigned to incoming calls from remote users. Consider creating a dedicated incoming IP address if the number of potential callers exceeds the number of modems and serial ports on the dial-in server. For complete information about creating dedicated IP addresses, go to Creating an IP Addressing Scheme for Callers.

How to Configure Users of the Dial-in Server

Become superuser on the dial-in server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Create a new account on the dial-in server for each remote PPP user.

You can use the Solaris Management Console to create a new user. The /usr/sadm/bin/smc command opens the Solaris Management Console. For instructions about creating a new user through Solaris Management Console, see Setting Up User Accounts (Task Map) in System Administration Guide: Basic Administration.

Use Solaris Management Console to assign parameters for the new user.

For example, the following table shows the parameters for an account that is called pppuser for user1 on the dial-out machine myhome.

Parameter	Value	Definition
User Name	`pppuser`	The user account name for the remote user. This account name should correspond to the account name that is given in the login sequence of the chat script. For example, `pppuser` is the account name that is found in the chat script in How to Create the Instructions for Calling a Peer.
Login Shell	`/usr/bin/pppd`	The default login shell for the remote user. The login shell `/usr/bin/pppd` initially restricts the caller to a dedicated PPP environment.
Create Home Dir Path	`/export/home/pppuser`	The home directory `/export/home/pppuser` is set when the caller successfully logs in to the dial-in server.

Create for each caller a $HOME/.ppprc file that contains various options that are specific to the user's PPP session.

For example, you might create the following .ppprc file for pppuser.
# cat /export/home/pppuser/.ppprc noccp
noccp turns off compression control on the link.

Configuring Communications Over the Dial-in Server

The next task shows how to enable the dial-in server to open communications with any dial-out machine. The options that are defined in the following PPP configuration files determine how communications are established.

/etc/ppp/options
/etc/ppp/options.ttyname

For detailed information about these files, refer to Using PPP Options in Files and on the Command Line.

Before you proceed, you should have done the following:

Configured the serial port and modem on the dial-in server, as described in How to Configure the Modem and Serial Port (Dial-in Server).
Configured information about the prospective users of the dial-in server, as described in How to Configure Users of the Dial-in Server.

How to Define Communications Over the Serial Line (Dial-in Server)

Become superuser on the dial-in server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Create the /etc/ppp/options file with the following entry.
nodefaultroute
nodefaultroute indicates that no pppd session on the local system can establish a default route without root privileges.

Note –
If the dial-in server does not have an /etc/ppp/options file, only the superuser can run the pppd command. However, the /etc/ppp/options file can be empty.

Create the file /etc/options.ttyname to define how calls that are received over serial port ttyname should be handled.

The following /etc/options.ttya file defines how the dial-in server's serial port /dev/ttya should handle incoming calls.
:10.0.0.80 xonxoff
:10.0.0.80

Assigns the IP address 10.0.0.80 to all peers that are calling in over serial port ttya

xonxoff

Allows the serial line to handle communications from modems with software flow control enabled

Calling the Dial-in Server

You establish a dial-up PPP link by having the dial-out machine call the dial-in server. You can instruct the dial-out machine to call the server by specifying the demand option in the local PPP configuration files. However, the most common method for establishing the link is for the user to run the pppd command on the dial-out machine.

Before you proceed to the next task, you should have done either or both of the following:

Set up the dial-out machine, as described in Configuring the Dial-out Machine
Set up the dial-in server, as described in Configuring the Dial-in Server

How to Call the Dial-in Server

Call the dial-in server by running the pppd command.

For example, the following command initiates a link between the dial-out machine and dial-in server myserver:
% pppd 57600 call myserver
pppd

Starts the call by invoking the pppd daemon

57600

Sets the speed of the line between host and modem

call myserver

Invokes the call option of pppd. pppd then reads options in the file /etc/ppp/peers/myserver, which was created in How to Define the Connection With an Individual Peer

Contact a host on the server's network, for example, the host lindyhop that is shown in Figure 16–1:
ping lindyhop
If the link is not working correctly, refer to Chapter 21, Fixing Common PPP Problems (Tasks).

Terminate the PPP session:
% pkill -x pppd

Chapter 18 Setting Up a Leased-Line PPP Link (Tasks)

This chapter explains how to configure a PPP link that uses a leased line between peers. Major sections include the following:

Setting Up a Leased Line (Task Map)

Leased-line links are relatively easy to set up, in comparison with dial-up links. In most instances, you do not have to configure the CSU/DSU, dialing services, or authentication. If you do need to configure the CSU/DSU, refer to the manufacturer's documentation for aid with this complex task.

The task map in the next table describes all the tasks that are involved in setting up the basic leased-line link.

Note –

Some types of leased lines do require the CSU/DSU to “dial” the address of the opposite peer. For example, Frame Relay uses Switched Virtual Circuits (SVCs) or Switched 56 service.

Table 18–1 Task Map for Setting Up the Leased-Line Link


Task	Description	For Instructions
1. Gather preconfiguration information	Gather data that is needed prior to setting up the link.	Table 16–4
2. Set up the leased-line hardware	Assemble the CSU/DSU and synchronous interface card.	How to Configure Synchronous Devices
3. Configure the interface card, if required	Configure the interface script to be used when the leased line is initiated.	How to Configure Synchronous Devices
4. Configure information about the remote peer	Define how communications between your local machine and the remote peer should work.	How to Configure a Machine on a Leased Line
5. Start up the leased line	Configure your machine to start up PPP over the leased line as part of the booting process.	How to Configure a Machine on a Leased Line

Configuring Synchronous Devices on the Leased Line

The task in this section involves configuring equipment that is required by the leased-line topology that is introduced in Example of a Configuration for a Leased-Line Link. The synchronous devices that are required to connect to the leased line include the interface and modem.

Prerequisites for Synchronous Devices Setup

Before you perform the next procedure, you must have the following items:

Working leased line that is installed at your site by the provider
Synchronous unit (CSU/DSU)
Solaris 9 release or Solaris 10 release installed on your system
Synchronous interface card of the type that is required by your system

How to Configure Synchronous Devices

Physically install the interface card into the local machine, if necessary.

Follow the instructions in the manufacturer's documentation.

Connect the cables from the CSU/DSU to the interface.

If necessary, connect cables from the CSU/DSU to the leased-line jack or similar connector.

Configure the CSU/DSU, as instructed in the documentation from the manufacturer or network provider.

Note –
The provider from whom you rented the leased line might supply and configure the CSU/DSU for your link.

Configure the interface card, if necessary, as instructed in the interface documentation.

The configuration of the interface card involves the creation of a startup script for the interface. The router at LocalCorp in the leased-line configuration that is shown in Figure 16–2 uses an HSI/P interface card.

The following script, hsi-conf, starts the HSI/P interface.
#!/bin/ksh /opt/SUNWconn/bin/hsip_init hihp1 speed=1536000 mode=fdx loopback=no \ nrzi=no txc=txc rxc=rxc txd=txd rxd=rxd signal=no 2>&1 > /dev/null
hihp1

Indicates that HSI/P is the synchronous port used

speed=1536000

Set to indicate the speed of the CSU/DSU

Configuring a Machine on the Leased Line

The task in this section explains how to set up a router to function as the local peer on your end of a leased line. The task uses the leased line that was introduced in Example of a Configuration for a Leased-Line Link as an example.

Prerequisites for Configuring the Local Machine on a Leased Line

Before you perform the next procedure, you must have completed the following:

Set up and configure the synchronous devices for the link, as described in Configuring Synchronous Devices on the Leased Line
Obtained the root password for the local machine on the leased line
Set up the local machine to run as a router on the network or networks to use the services of the leased-line provider

How to Configure a Machine on a Leased Line

Become superuser on the local machine (router) or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Add an entry for the remote peer in the router's /etc/hosts file.
# cat /etc/hosts # # Internet host table # 127.0.0.1 localhost 192.168.130.10 local2-peer loghost 192.168.130.11 local1-net 10.0.0.25 farISP
The example /etc/hosts file is for the local router at the fictitious LocalCorp. Note the IP address and host name for the remote peer farISP at the service provider.

Create the file /etc/ppp/peers/peer-name to hold information about the provider's peer.

For this example leased-line link, you create the file /etc/ppp/peers/farISP.

# cat /etc/ppp/peers/farISP
init '/etc/ppp/conf_hsi'
local
/dev/hihp1
sync
noauth
192.168.130.10:10.0.0.25
passive
persist
noccp
nopcomp
novj
noaccomp

The following table explains the options and parameters that are used in /etc/ppp/peers/farISP.

Option	Definition
`init '/etc/ppp/conf_hsi'`	Starts the link. `init` then configures the HSI interface by using the parameters in the script `/etc/ppp/conf_hsi`.
`local`	Tells the `pppd` daemon not to change the state of the Data Terminal Ready (DTR) signal. Also tells `pppd` to ignore the Data Carrier Detect (DCD) input signal.
`/dev/hihp1`	Gives the device name of synchronous interface.
`sync`	Establishes synchronous encoding for the link.
`noauth`	Establishes that the local system does not need to demand authentication from the peer. However, the peer could still demand authentication.
`192.168.130.10:10.0.0.25`	Defines the IP addresses of the local peer and the remote peer, separated by a colon.
`passive`	Tells the `pppd` daemon on the local machine to go quiet after issuing maximum number of LCP Configure-Requests and to wait for the peer to start.
`persist`	Tells the `pppd` daemon to try to restart the link after a connection ends.
`noccp, nopcomp, novj, noaccomp`	Disables the Compression Control Protocol (CCP), Protocol Field compression, Van Jacobson compression, and address and control field compression, respectively. These forms of compression accelerate transmissions on a dial-up link but could slow down a leased line.

Create an initialization script that is called demand, which creates the PPP link as part of the booting process.

# cat /etc/ppp/demand
#!/bin/sh
if [ -f /var/run/ppp-demand.pid ] &&
   /usr/bin/kill -s 0 `/bin/cat /var/run/ppp-demand.pid`
then
        :
else
        /usr/bin/pppd call farISP
fi

The demand script contains the pppd command for establishing a leased-line link. The following table explains the content of $PPPDIR/demand.

Code Sample	Explanation
if [ -f /var/run/ppp-demand.pid ] && /usr/bin/kill -s 0 `/bin/cat /var/run/ppp-demand.pid`	These lines check to see if `pppd` is running. If `pppd` is running, it does not need to be started.
`/usr/bin/pppd call farISP`	This line launches `pppd`. `pppd` reads the options from `/etc/ppp/options`. The `call farISP` option on the command line causes it to read `/etc/ppp/peers/farISP`, also.

The Solaris PPP 4.0 startup script /etc/rc2.d/S47pppd invokes the demand script as part of the Solaris booting process. The following lines in /etc/rc2.dS47pppd search for the presence of a file that is called $PPPDIR/demand.

    if [ -f $PPPDIR/demand ]; then
                . $PPPDIR/demand
        fi

If found, $PPPDIR/demand is executed. During the course of executing $PPPDIR/demand, the link is established.

Note –

To reach machines outside the local network, have users run telnet, ftp, rsh, or similar commands.

Chapter 19 Setting Up PPP Authentication (Tasks)

This chapter contains tasks for setting up PPP authentication. Subjects that are covered include the following:

The procedures show how to implement authentication over a dial-up link because dial-up links are more likely to be configured for authentication than leased-line links. You can configure authentication over leased lines if authentication is required by your corporate security policy. For leased-line authentication, use the tasks in this chapter as guidelines.

If you want to use PPP authentication but are not sure which protocol to use, review the section Why Use PPP Authentication?. More detailed information about PPP authentication is in the pppd(1M) man page and in Authenticating Callers on a Link.

Configuring PPP Authentication (Task Map)

This section contains task maps to help you quickly access procedures for PPP authentication.

Table 19–1 Task Map for General PPP Authentication


Task	Description	For Instructions
Configure PAP authentication	Use these procedures to enable PAP authentication on a dial-in server and a dial-out machine.	Setting Up PAP Authentication (Task Maps)
Configure CHAP authentication	Use these procedures to enable CHAP authentication on a dial-in server and a dial-out machine.	Setting Up CHAP Authentication (Task Maps)

Configuring PAP Authentication

The tasks in this section explain how to implement authentication on a PPP link by using the Password Authentication Protocol (PAP). The tasks use the example that is shown in Examples of PPP Authentication Configurations to illustrate a working PAP scenario for a dial-up link. Use the instructions as the basis for implementing PAP authentication at your site.

Before you perform the next procedures, you must have done the following:

Set up and tested the dial-up link between the dial-in server and dial-out machines that belong to trusted callers
Ideally, for dial-in server authentication, obtained superuser permission for the machine where the network password database is administered, for example, in LDAP, NIS, or local files
Obtained superuser authority for the local machine, either dial-in server or dial-out machine

Setting Up PAP Authentication (Task Maps)

Use the next task maps to quickly access PAP-related tasks for the dial-in server and trusted callers on dial-out machines.

Table 19–2 Task Map for PAP Authentication (Dial-in Server)


Task	Description	For Instructions
1. Gather preconfiguration information	Collect user names and other data that is needed for authentication.	Planning for Authentication on a Link
2. Update the password database, if necessary	Ensure that all potential callers are in the server's password database.	How to Create a PAP Credentials Database (Dial-in Server)
3. Create the PAP database	Create security credentials for all prospective callers in `/etc/ppp/pap-secrets`.	How to Create a PAP Credentials Database (Dial-in Server)
4. Modify the PPP configuration files	Add options specific to PAP to the `/etc/ppp/options` and `/etc/ppp/peers/peer-name` files.	How to Add PAP Support to the PPP Configuration Files (Dial-in Server)

Table 19–3 Task Map for PAP Authentication (Dial-out Machine)


Task	Description	For Instructions
1. Gather preconfiguration information	Collect user names and other data that is needed for authentication.	Planning for Authentication on a Link
2. Create the PAP database for the trusted caller's machine	Create the security credentials for the trusted caller and, if necessary, security credentials for other users who call the dial-out machine, in `/etc/ppp/pap-secrets`.	How to Configure PAP Authentication Credentials for the Trusted Callers
3. Modify the PPP configuration files	Add options specific to PAP to the `/etc/ppp/options` and `/etc/ppp/peers/peer-name` files.	How to Add PAP Support to the PPP Configuration Files (Dial-out Machine)

Configuring PAP Authentication on the Dial-in Server

To set up PAP authentication, you must do the following:

Create a PAP credentials database
Modify PPP configuration files for PAP support

How to Create a PAP Credentials Database (Dial-in Server)

This procedure modifies the /etc/ppp/pap-secrets file, which contains the PAP security credentials that are used to authenticate callers on the link. /etc/ppp/pap-secrets must exist on both machines on a PPP link.

The sample PAP configuration that was introduced in Figure 16–3 uses the login option of PAP. If you plan to use this option, you might also need to update your network's password database. For more information about the login option, refer to Using the login Option With /etc/ppp/pap-secrets.

Assemble a list of all potential trusted callers. Trusted callers are people to be granted permission to call the dial-in server from their remote machines.

Verify that each trusted caller already has a UNIX user name and password in the dial-in server's password database.

Note –
Verification is particularly important for the sample PAP configuration, which uses the login option of PAP to authenticate callers. If you choose not to implement login for PAP, the callers' PAP user names do not have to correspond with their UNIX user names. For information about standard /etc/ppp/pap-secrets, refer to /etc/ppp/pap-secrets File.

Do the following if a potential trusted caller does not have a UNIX user name and password:
1. Confirm with their managers that callers whom you do not know personally have permission to access the dial-in server.
2. Create UNIX user names and passwords for these callers in the manner that is directed by your corporate security policy.

Become superuser on the dial-in server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Edit the /etc/ppp/pap-secrets file.

Solaris PPP 4.0 provides a pap-secrets file in /etc/ppp that contains comments about how to use PAP authentication but no options. You can add the following options at the end of the comments.
user1 myserver "" * user2 myserver "" * myserver user2 serverpass *
To use the login option of /etc/ppp/pap-secrets, you must type the UNIX user name of each trusted caller. Wherever a set of double quotes (““) appears in the third field, the password for the caller is looked up in the server's password database.

The entry myserver * serverpass * contains the PAP user name and password for the dial-in server. In Figure 16–3, the trusted caller user2 requires authentication from remote peers. Therefore, myserver's /etc/ppp/pap-secrets file contains PAP credentials for use when a link is established with user2.

Modifying the PPP Configuration Files for PAP (Dial-in Server)

The tasks in this section explain how to update any existing PPP configuration files to support PAP authentication on the dial-in server.

How to Add PAP Support to the PPP Configuration Files (Dial-in Server)

The procedure uses as examples the PPP configuration files that were introduced in How to Define Communications Over the Serial Line (Dial-in Server).

Log in as superuser on the dial-in server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Add authentication options to the /etc/ppp/options file.

For example, you would add the options in bold to an existing /etc/ppp/options file to implement PAP authentication:
lock auth login nodefaultroute proxyarp ms-dns 10.0.0.1 idle 120
auth

Specifies that the server must authenticate callers before establishing the link.

login

Specifies that the remote caller be authenticated by using the standard UNIX user authentication services.

nodefaultroute

Indicates that no pppd session on the local system can establish a default route without root privileges.

proxyarp

Adds an entry to the system's Address Resolution Protocol (ARP) table that specifies the IP address of the peer and the Ethernet address of the system. With this option the peer appears to be on the local Ethernet to other systems.

ms-dns 10.0.0.1

Enables pppd to supply a Domain Name Server (DNS) address, 10.0.0.1, for the client

idle 120

Specifies that idle users are disconnected after two minutes.

In the /etc/ppp/options.cua.a file, add the following address for the cua/a user.
:10.0.0.2

In the /etc/ppp/options.cua.b file, add the following address for the cua/b user.
:10.0.0.3

In the /etc/ppp/pap-secrets file, add the following entry.
* * "" *
Note –
The login option, as previously described, supplies the necessary user authentication. This entry in the /etc/ppp/pap-secrets file is the standard way of enabling PAP with the login option.

Configuring PAP Authentication for Trusted Callers (Dial-out Machines)

This section contains tasks for setting up PAP authentication on the dial-out machines of trusted callers. As system administrator, you can set up PAP authentication on the systems before distribution to prospective callers. Or, if the remote callers already have their machines, you can give these callers the tasks in this section.

Configuring PAP for trusted callers involves two tasks:

Configuring the callers' PAP security credentials
Configuring the callers' dial-out machines to support PAP authentication

How to Configure PAP Authentication Credentials for the Trusted Callers

This procedure shows how to set up PAP credentials for two trusted callers, one of which requires authentication credentials from remote peers. The steps in the procedure assume that you, the system administrator, are creating the PAP credentials on the trusted callers' dial-out machines.

Become superuser on a dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Using the sample PAP configuration that was introduced in Figure 16–3, assume that the dial-out machine belongs to user1.

Modify the pap-secrets database for the caller.

Solaris PPP 4.0 provides an /etc/ppp/pap-secrets file that contains helpful comments but no options. You can add the following options to this /etc/ppp/pap-secrets file.
user1 myserver pass1 *
Note that user1's password pass1 is passed in readable ASCII form over the link. myserver is caller user1's name for the peer.

Become superuser on another dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Using the PAP authentication example, assume that this dial-out machine belongs to the caller user2.

Modify the pap-secrets database for the caller.

You can add the next options to the end of the existing /etc/ppp/pap-secrets file.
user2 myserver pass2 * myserver user2 serverpass *
In this example, /etc/ppp/pap-secrets has two entries. The first entry contains the PAP security credentials that user2 passes to dial-in server myserver for authentication.

user2 requires PAP credentials from the dial-in server as part of link negotiation. Therefore, the /etc/ppp/pap-secrets also contains PAP credentials that are expected from myserver on the second line.

Note –
Because most ISPs do not supply authentication credentials, the previous scenario might be unrealistic for communications with an ISP.

Modifying PPP Configuration Files for PAP (Dial-out Machine)

The following tasks explain how to update existing PPP configuration files to support PAP authentication on the dial-out machines of trusted callers.

The procedure uses the following parameters to configure PAP authentication on the dial-out machine that belongs to user2, who was introduced in Figure 16–3. user2 requires incoming callers to authenticate, including calls from dial-in myserver.

How to Add PAP Support to the PPP Configuration Files (Dial-out Machine)

This procedure uses as examples the PPP configuration files that were introduced in How to Define Communications Over the Serial Line. The procedure configures the dial-out machine that belongs to user2, as shown in Figure 16–3.

Modify the /etc/ppp/options file.

The next /etc/ppp/options file contains options for PAP support, which are shown in bold.
# cat /etc/ppp/options lock name user2 auth require-pap
name user2

Sets user2 as the PAP name of the user on the local machine. If the login option is used, the PAP name must be the same as the user's UNIX user name in the password database.

auth

States that the dial-out machine must authenticate callers before establishing the link.

Note –
This dial-out machine demands authentication from its peers, even though most dial-out machines do not make this demand. Either way is acceptable.

require-pap

Demands PAP credentials from the peer.

Create an /etc/ppp/peers/peer-name file for the remote machine myserver.

The next example shows how to add PAP support to the existing /etc/ppp/peers/myserver file that was created in How to Define the Connection With an Individual Peer.
# cat /etc/ppp/peers/myserver /dev/cua/a 57600 noipdefault defaultroute idle 120 user user2 remotename myserver connect "chat -U 'mypassword' -f /etc/ppp/mychat"
The new options in bold add PAP requirements for peer myserver.

user user2

Defines user2 as the user name of the local machine

remotename myserver

Defines myserver as a peer that requires authentication credentials from the local machine

Configuring CHAP Authentication

The tasks in this section explain how to implement authentication on a PPP link by using the Challenge-Handshake Authentication Protocol (CHAP). The tasks use the example that is shown in Figure 16–4 to illustrate a working CHAP scenario for dialing up a private network. Use the instructions as the basis for implementing CHAP authentication at your site.

Before you perform the next procedures, you must have done the following:

Set up and tested the dial-up link between the dial-in server and dial-out machines that belong to trusted callers
Obtained superuser permission for the local machine, either dial-in server or dial-out machine

Setting Up CHAP Authentication (Task Maps)

Table 19–4 Task Map for CHAP Authentication (Dial-in Server)


Task	Description	For Instructions
1. Assign CHAP secrets to all trusted callers	Create, or have the callers create, their CHAP secrets.	How to Create a CHAP Credentials Database (Dial-in Server)
2. Create the chap-secrets database	Add the security credentials for all trusted callers to the `/etc/ppp/chap-secrets` file.	How to Create a CHAP Credentials Database (Dial-in Server)
3. Modify the PPP configuration files	Add options specific to CHAP to the `/etc/ppp/options` and `/etc/ppp/peers/peer-name` files.	How to Add CHAP Support to the PPP Configuration Files (Dial-in Server)

Table 19–5 Task Map for CHAP Authentication (Dial-out Machine)


Task	Description	For Instructions
1. Create the CHAP database for the trusted caller's machine	Create the security credentials for the trusted caller and, if necessary, security credentials for other users who call the dial-out machine, in `/etc/ppp/chap-secrets`.	How to Create a CHAP Credentials Database (Dial-in Server)
2. Modify the PPP configuration files	Add options specific to CHAP to the `/etc/ppp/options` file.	How to Add CHAP Support to the PPP Configuration Files (Dial-out Machine)

Configuring CHAP Authentication on the Dial-in Server

The first task in setting up CHAP authentication is modifying the /etc/ppp/chap-secrets file. This file contains the CHAP security credentials, including the CHAP secret, that are used to authenticate callers on the link.

Note –

UNIX or PAM authentication mechanisms do not work with CHAP. For example, you cannot use the PPP login option as described in How to Create a PAP Credentials Database (Dial-in Server). If your authentication scenario requires PAM or UNIX-style authentication, choose PAP instead.

The next procedure implements CHAP authentication for a dial-in server in a private network. The PPP link is the only connection to the outside world. The only callers who can access the network have been granted permission by managers of the network, possibly including the system administrator.

How to Create a CHAP Credentials Database (Dial-in Server)

Assemble a list that contains the user names of all trusted callers.

Trusted callers include all people who have been granted permission to call the private network.

Assign each user a CHAP secret.

Note –
Be sure to choose a good CHAP secret that is not easily guessed. No other restrictions are placed on the CHAP secret's contents.

The method for assigning CHAP secrets depends on your site's security policy. Either you have the responsibility for creating the secrets, or the callers must create their own secrets. If you are not responsible for CHAP secret assignment, be sure to get the CHAP secrets that were created by, or for, each trusted caller.

Become superuser on the dial-in server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Modify the /etc/ppp/chap-secrets file.

Solaris PPP 4.0 includes an /etc/ppp/chap-secrets file that contains helpful comments but no options. You can add the following options for the server CallServe at the end of the existing /etc/ppp/chap-secrets file.
account1 CallServe key123 * account2 CallServe key456 *
key123 is the CHAP secret for trusted caller account1.

key456 is the CHAP secret for trusted caller account2.

Modifying the PPP Configuration Files for CHAP (Dial-in Server)

The task in this section explains how to update existing PPP configuration files to support CHAP authentication on the dial-in server.

How to Add CHAP Support to the PPP Configuration Files (Dial-in Server)

Modify the /etc/ppp/options file.

Add the options that are shown in bold for CHAP support.
# cat /etc/ppp/options lock nodefaultroute name CallServe auth
name CallServe

Defines CallServe as the CHAP name of the user on the local machine, in this instance the dial-in server

auth

Makes the local machine authenticate callers before establishing the link

Create the remaining PPP configuration files to support the trusted callers.

See How to Configure Users of the Dial-in Server and How to Define Communications Over the Serial Line (Dial-in Server).

Configuring CHAP Authentication for Trusted Callers (Dial-out Machines)

This section contains tasks for setting up CHAP authentication on the dial-out machines of trusted callers. Depending on your site's security policy, either you or the trusted callers might be responsible for setting up CHAP authentication.

For remote callers to configure CHAP, ensure that the callers' local CHAP secrets match the callers' equivalent CHAP secrets in the dial-in server's /etc/ppp/chap-secrets file. Then give the callers the tasks in this section for configuring CHAP.

Configuring CHAP for trusted callers involves two tasks:

Creating the callers' CHAP security credentials
Configuring the callers' dial-out machines to support CHAP authentication

How to Configure CHAP Authentication Credentials for the Trusted Callers

This procedure shows how to set up CHAP credentials for two trusted callers. The steps in the procedure assume that you, the system administrator, are creating the CHAP credentials on the trusted callers' dial-out machines.

Become superuser on a dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Using the sample CHAP configuration in Example of a Configuration Using CHAP Authentication, assume that the dial-out machine belongs to trusted caller account1.

Modify the chap-secrets database for caller account1.

Solaris PPP 4.0 includes an /etc/ppp/chap-secrets file that has helpful comments but no options. You can add the following options to the existing /etc/ppp/chap-secrets file.
account1 CallServe key123 *
CallServe is the name for the peer that account1 is trying to reach. key123 is the CHAP secret to be used for links between account1 and CallServer.

Become superuser on another dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Assume that this machine belongs to caller account2.

Modify the /etc/ppp/chap-secrets database for caller account2.
account2 CallServe key456 *
Now, account2 has secret key456 as its CHAP credentials for use over links to peer CallServe.

Adding CHAP to the Configuration Files (Dial-out Machine)

To learn more about CHAP authentication, refer to Challenge-Handshake Authentication Protocol (CHAP). The next task configures the dial-out machine that belongs to caller account1, which is introduced in Example of a Configuration Using CHAP Authentication.

How to Add CHAP Support to the PPP Configuration Files (Dial-out Machine)

Ensure that the /etc/ppp/options file has the following options.
# cat /etc/ppp/options lock nodefaultroute

Create an /etc/ppp/peers/peer-name file for the remote machine CallServe.
# cat /etc/ppp/peers/CallServe /dev/cua/a 57600 noipdefault defaultroute idle 120 user account1 connect "chat -U 'mypassword' -f /etc/ppp/mychat"
The option user account1 sets account1 as the CHAP user name to be given to CallServe. For a description of the other options in the previous file, see the similar /etc/ppp/peers/myserver file in How to Define the Connection With an Individual Peer.

Chapter 20 Setting Up a PPPoE Tunnel (Tasks)

This chapter contains tasks for setting up the participants on either end of the PPPoE tunnel: the PPPoE client and PPPoE access server. Specific topics include the following:

The tasks use the scenario that was introduced in Planning for DSL Support Over a PPPoE Tunnel as an example. For an overview of PPPoE, refer to Support for DSL Users Through PPPoE.

Major Tasks for Setting Up a PPPoE Tunnel (Task Maps)

The following tables list the major tasks for configuring PPPoE clients and the PPPoE access server. To implement PPPoE at your site, you need to set up only your end of the PPPoE tunnel, either the client side or access-server side.

Table 20–1 Task Map for Setting Up a PPPoE Client


Task	Description	For Instructions
1. Configure an interface for PPPoE	Define the Ethernet interface to be used for the PPPoE tunnel.	How to Configure an Interface for a PPPoE Client
2. Configure information about the PPPoE access server	Define parameters for the access server at the service provider end of the PPPoE tunnel.	How to Define a PPPoE Access Server Peer
3. Set up the PPP configuration files	Define the PPP configuration files for the client, if you have not done so already.	How to Define Communications Over the Serial Line
4. Create the tunnel	Call the access server.	How to Define a PPPoE Access Server Peer

Table 20–2 Task Map for Setting Up a PPPoE Access Server


Task	Description	For Instructions
1. Set up a PPPoE access server	Define the Ethernet interface to be used for the PPPoE tunnel and define the services that the access server offers.	How to Set Up a PPPoE Access Server
2. Set up the PPP configuration files	Define the PPP configuration files for the client, if you have not done so already.	Configuring Communications Over the Dial-in Server
3. (Optional) Restrict use of an interface	Use PPPoE options and PAP authentication to restrict use of a particular Ethernet interface to certain clients.	How to Restrict the Use of an Interface to Particular Clients

Setting Up the PPPoE Client

To provide PPP to client systems over DSL, you must first configure PPPoE on the interface that is connected to the modem or hub. Then you need to change the PPP configuration files to define the access server on the opposite end of the PPPoE.

Prerequisites for Setting Up the PPPoE Client

Before you set up the PPPoE client, you must have done the following:

Installed Solaris 8 Update 6 release or subsequent releases on the client machines to use the PPPoE tunnel.
Contacted the service provider for information about its PPPoE access server.
Had the telephone company or service provider assemble the devices that are used by the client machines. These devices include, for example, the DSL modem and the splitter, which the telephone company rather than you might assemble.

How to Configure an Interface for a PPPoE Client

Use this procedure to define the Ethernet interface to be used for the PPPoE tunnel.

Become superuser on the PPPoE client or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Add the name of the Ethernet interface with the DSL connection to the /etc/ppp/pppoe.if file.

For example, you add the following entry to /etc/ppp/pppoe.if for a PPPoE client that uses hme0 as the network interface that is connected to the DSL modem.
hme0
For more information about /etc/ppp/pppoe.if, go to /etc/ppp/pppoe.if File.

Configure the interface for PPPoE use.
# /etc/init.d/pppd start

(Optional) Verify that the interface is now plumbed for PPPoE.
# /usr/sbin/sppptun query hme0:pppoe hme0:pppoed
You can also use the /usr/sbin/sppptun command to manually plumb interfaces for PPPoE. For instructions, refer to /usr/sbin/sppptun Command.

How to Define a PPPoE Access Server Peer

You define the access server in the /etc/ppp/peers/peer-name file. Many of the options that are used for the access server are also used to define the dial-in server in a dial-up scenario. For a detailed explanation of /etc/ppp/peers.peer-name, refer to /etc/ppp/peers/peer-name File.

Become superuser on the PPPoE client or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Define the service provider's PPPoE access server in the /etc/ppp/peers/peer-name file.

For example, the following file, /etc/ppp/peers/dslserve, defines the access server dslserve at Far ISP that is introduced in Example of a Configuration for a PPPoE Tunnel.
# cat /etc/ppp/peers/dslserve sppptun plugin pppoe.so connect "/usr/lib/inet/pppoec hme0" noccp noauth user Red password redsecret noipdefault defaultroute
For a definition of the options in this file, go to /etc/ppp/peers/peer-name File for Defining an Access Server Peer.

Modify the other PPP configuration files on the PPPoE client.
1. Configure /etc/ppp/options as described in the instructions for configuring a dial-out machine in Configuring the Dial-out Machine.
2. Create an /etc/ppp/options.sppptun file. /etc/ppp/options.sppptun defines PPP options for the serial port to which the interface that is plumbed for PPPoE is attached.
  
  You can use any options that are available for the /etc/ppp/options.ttyname file that is described in /etc/ppp/options.ttyname Configuration File. You must name the file /etc/ppp/options.sppptun because sppptun is the specified device name in the pppd configuration.

Ensure that all users can start PPP on the client.
# touch /etc/ppp/options

Test if PPP can run over the DSL line.
% pppd debug updetach call dslserve
dslserve is the name that is given to the access server at the ISP that is shown in Example of a Configuration for a PPPoE Tunnel. The debug updetach option causes debugging information to be displayed in a terminal window.

If PPP is running correctly, the terminal output shows the link becoming active. If PPP still does not run, try the following command to see if the servers are running correctly:
# /usr/lib/inet/pppoec -i hme0
Note –
Users of configured PPPoE clients can begin running PPP over a DSL line by typing the following:
% pppd call ISP-server-name
Then the users can run an application or a service.

Setting Up a PPPoE Access Server

If your company is a service provider, you can offer Internet and other services to clients that reach your site through DSL connections. The procedure involves determining which interfaces on the server to involve in the PPPoE tunnel and defining which services are made available to the users.

How to Set Up a PPPoE Access Server

Use this procedure to define the Ethernet interface to be used for the PPPoE tunnel and to configure the services that the access server offers.

Become superuser on the access server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Add the name of the Ethernet interfaces that are dedicated to the PPPoE tunnels to the /etc/ppp/pppoe.if file.

For example, you would use the following /etc/ppp/pppoe.if file for the access server dslserve that is shown in Example of a Configuration for a PPPoE Tunnel.
# cat /etc/ppp/pppoe.if hme1 hme2

Define global services that are provided by the access server in the /etc/ppp/pppoe file.

The following /etc/ppp/pppoe file lists the services that are provided by access server dslserve, which was shown in Figure 16–5.
device hme1,hme2 service internet pppd "proxyarp 192.168.1.1:" service debugging pppd "debug proxyarp 192.168.1.1:"
In the file example, Internet service is announced for dslserve's Ethernet interfaces hme1 and hme2. Debugging is turned on for PPP links on the Ethernet interfaces.

Set up the PPP configuration files in the same way that you would for a dial-in server.

For more information, refer to Creating an IP Addressing Scheme for Callers.

Start the pppoed daemon.
# /etc/init.d/pppd start
pppd also plumbs the interfaces that are listed in /etc/ppp/pppoe.if.

(Optional) Verify that the interfaces on the server are plumbed for PPPoE.
# /usr/sbin/sppptun query hme1:pppoe hme1:pppoed hme2:pppoe hme2:pppoed
The previous sample shows that interfaces hme1 and hme2 are currently plumbed for PPPoE. You can also use the /usr/sbin/sppptun command to manually plumb interfaces for PPPoE. For instructions, refer to /usr/sbin/sppptun Command.

How to Modify an Existing `/etc/ppp/pppoe` File

Become superuser on the access server or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Modify /etc/ppp/pppoe, as needed.

Cause the pppoed daemon to recognize the new services.
# pkill -HUP pppoed

How to Restrict the Use of an Interface to Particular Clients

The next procedure shows how to restrict an interface to a group of PPPoE clients. Before performing this task, you need to obtain the real Ethernet MAC addresses of the clients you are assigning to the interface.

Note –

Some systems allow you to change the MAC address on the Ethernet interface. You should view this ability as a convenience factor, not a security measure.

Using the example that is shown in Example of a Configuration for a PPPoE Tunnel, these steps show how to reserve one of dslserve's interfaces, hme1, for clients at MiddleCo.

Configure the access server's interfaces and define the services, as shown in How to Set Up a PPPoE Access Server.

Create entries for clients in the server's /etc/ethers database.

Here is a sample entry for clients Red, Blue, and Yellow.
8:0:20:1:40:30 redether 8:0:20:1:40:10 yellowether 8:0:20:1:40:25 blueether
The sample assigns the symbolic names redether, yellowether, and blueether to the Ethernet addresses of clients Red, Yellow, and Blue. The assignment of symbolic names to the MAC addresses is optional.

Restrict services that are provided on a specific interface by defining the following information in the /etc/ppp/pppoe.device file.

In this file, device is the name of the device to be defined.
# cat /etc/ppp/pppoe.hme1 service internet pppd "name dslserve-hme1" clients redether,yellowether,blueether
dslserve-hme1 is the access server's name, which is used in matching entries in the pap-secrets file. The clients option restricts the use of interface hme1 to clients with the symbolic Ethernet names redether, yellowether, and blueether.

If you did not define symbolic names for client's MAC addresses in /etc/ethers, you can use the numeric addresses as arguments for the clients option. Wildcards are allowed.

For example, you can specify the numeric address clients 8:0:20:*:*:*. By using wildcards, all matching addresses in /etc/ethers are accepted.

Create the /etc/ppp/pap-secrets file for the access server:
Red dslserve-hme1 redpasswd * Blue dslserve-hme1 bluepasswd * Yellow dslserve-hme1 yellowpassd *
The entries are the PAP names and passwords of clients that are allowed to run PPP over dslserve's hme1 interface.

For more information about PAP authentication, see Configuring PAP Authentication.

Chapter 21 Fixing Common PPP Problems (Tasks)

This chapter contains information for troubleshooting common problems that occur with Solaris PPP 4.0. The following topics are covered:

The sources PPP Design, Implementation, and Debugging by James Carlson and the Australian National University's web site also have detailed advice for PPP troubleshooting. For more information, see Professional Reference Books About PPP and Web Sites About PPP.

Solving PPP Problems (Task Map)

Use the following task map to quickly access advice and solutions for common PPP problems.

Table 21–1 Task Map for Troubleshooting PPP


Task	Definition	For Instructions
Obtain diagnostic information about the PPP link	Use PPP diagnostic tools to obtain output for troubleshooting.	How to Obtain Diagnostic Information From `pppd`
Obtain debugging information for the PPP link	Use the `pppd debug` command to generate output for troubleshooting.	How to Turn on PPP Debugging
Troubleshoot general problems with the network layer	Identify and fix PPP problems that are network-related by using a series of checks.	How to Diagnose Network Problems
Troubleshoot general communications problems	Identify and fix communications problems that affect the PPP link.	How to Diagnose and Fix Communications Problems
Troubleshoot configuration problems	Identify and fix problems in the PPP configuration files.	How to Diagnose Problems With the PPP Configuration
Troubleshoot modem-related problems	Identify and fix modem problems.	How to Diagnose Modem Problems
Troubleshoot chat script-related problems	Identify and fix chat script problems on a dial-out machine.	How to Obtain Debugging Information for Chat Scripts
Troubleshoot serial-line speed problems	Identify and fix line–speed problems on a dial-in server.	How to Diagnose and Fix Serial-Line Speed Problems
Troubleshoot common problems for leased lines	Identify and fix performance problems on a leased line.	Fixing Leased-Line Problems
Troubleshoot problems related to authentication	Identify and fix problems related to the authentication databases.	Diagnosing and Fixing Authentication Problems
Troubleshoot problem areas for PPPoE	Use PPP diagnostic tools to obtain output for identifying and fixing PPPoE problems.	How to Obtain Diagnostic Information for PPPoE

Tools for Troubleshooting PPP

PPP links generally have three major areas of failure:

Failure of the link to be established
Poor performance of the link during regular usage
Problems that can be traced to the networks on either side of the link

The easiest way to find out if PPP works is to run a command over the link. Run a command such as ping or traceroute to a host on the peer's network. Then observe the results. However, you should use PPP and UNIX debugging tools to monitor performance of an established link or to troubleshoot a problematic link.

This section explains how to obtain diagnostic information from pppd and its associated log files. The remaining sections in this chapter describe common problems with PPP that you can discover and fix with the aid of the PPP troubleshooting tools.

How to Obtain Diagnostic Information From `pppd`

The next procedure shows how to view the current operation of a link on the local machine.

Become superuser on the local machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Run pppd with the serial device configured for PPP as the argument:
# pppd cua/b debug updetach
The next examples show the resulting displays for a dial-up link and a leased-line link when pppd runs in the foreground. If you run pppd debug in the background, the output that is produced is sent to the /etc/ppp/connect-errors file.

Example 21–1 Output From a Properly Operating Dial-up Link

# pppd /dev/cua/b debug updetach
have route to 0.0.0.0/0.0.0.0 via 172.21.0.4
serial speed set to 230400 bps
Using interface sppp0
Connect: sppp0 <--> /dev/cua/b
sent [LCP ConfReq id=0x7b <asyncmap 0x0> <magic 0x73e981c8> <pcomp> <accomp>]
rcvd [LCP Ident id=0x79 magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct  6 
	2004 09:36:22)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct  6 2004 09:36:22)
	rcvd [LCP ConfRej id=0x7b <asyncmap 0x0>]
sent [LCP Ident id=0x7c magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Sep 15 
	2004 09:38:33)"
sent [LCP ConfReq id=0x7d <magic 0x73e981c8> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x7d <magic 0x73e981c8> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>]
sent [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>]
sent [LCP Ident id=0x7e magic=0x73e981c8 "ppp-2.4.0b1 (Sun Microsystems, Inc., 
	Sep 15 2004 09:38:33)"]
sent [IPCP ConfReq id=0x3d <addr 0.0.0.0> <compress VJ 0f 01>]
rcvd [LCP Ident id=0x7a magic=0xdd4ad820 "ppp-2.4.0b1 (Sun Microsystems, Inc., 
	Oct  6 2004 09:36:22)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct  6 2004 09:36:22)
rcvd [IPCP ConfReq id=0x92 <addr 10.0.0.1> <compress VJ 0f 01>
sent [IPCP ConfAck id=0x92 <addr 10.0.0.1> <compress VJ 0f 01>
rcvd [IPCP ConfNak id=0x3d <addr 10.0.0.2>]]
sent [IPCP ConfReq id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>]
rcvd [IPCP ConfAck id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>]
local  IP address 10.0.0.2
remote IP address 10.0.0.1

Example 21–2 Output From a Properly Operating Leased-Line Link

# pppd /dev/se_hdlc1 default-asyncmap debug updetach
pppd 2.4.0b1 (Sun Microsystems, Inc., Oct 24 2004 07:13:18) started by root, uid 0
synchronous speed appears to be 0 bps
init option: '/etc/ppp/peers/syncinit.sh' started (pid 105122)
Serial port initialized.
synchronous speed appears to be 64000 bps
Using interface sppp0
Connect: sppp0 <--> /dev/se_hdlc1
sent [LCP ConfReq id=0xe9 <magic 0x474283c6><pcomp> <accomp>]
rcvd [LCP ConfAck id=0xe9 <magic 0x474283c6><pcomp> <accomp>]
rcvd [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>]
sent [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>]
sent [LCP Ident id=0xea magic=0x474283c6 "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 
	22 2004 14:31:44)"]
sent [IPCP ConfReq id=0xf7 <addr 0.0.0.0> <compress VJ Of o1>]]
sent [CCP ConfReq id=0x3f <deflate 15> <deflate(old#) 15> <bsd v1 15>]
rcvd [LCP Ident id=0x23 magic=0x8e3a53ff "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 
	22 2004 14:31:44)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2004 14:31:44)
rcvd [IPCP ConfReq id=0x25 <addr 10.0.0.1> <compress VJ Of 01>]
sent [IPCP ConfAck id=0x25 <addr 10.0.0.1> <compress VJ Of 01>]
rcvd [CCP ConfReq id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>]
sent [CCP ConfAck id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>]
rcvd [IPCP ConfNak id=0xf8 <addr 10.0.0.2>]
rcvd [IPCP ConfReq id=0xf7 <addr 10.0.0.2> <compress VJ Of 01>]
rcvd [CCP ConfAck id=0x3f <deflate 15> <deflate(old#) 15 <bsd v1 15>]
Deflate (15) compression enabled
rcvd [IPCP ConfAck id=0xf8 <addr 10.0.0.2> <compress VJ Of 01>]
local  IP address 10.0.0.2
remote IP address 10.0.0.1

How to Turn on PPP Debugging

The next task shows how to use the pppd command to obtain debugging information.

Note –

You only need to perform step 1 through step 3 once for each host. Thereafter, you can proceed to step 4 to turn on debugging for the host.

Become superuser or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Create a log file to hold output from pppd.
# touch /var/log/pppdebug

Add the following syslog facilities for pppd in /etc/syslog.conf.
daemon.debug;local2.debug /var/log/pppdebug

Restart syslogd.
# pkill -HUP -x syslogd

Turn on debugging for calls to a particular peer by using the following syntax of pppd.
# pppd debug call peer-name
peer-name must be the name of a file in the /etc/ppp/peers directory.

View the contents of the log file.
# tail -f /var/log/pppdebug
For an example of a log file, see Step 3.

Solving PPP-Related and PPPoE-Related Problems

Refer to the following sections for information about how to resolve PPP-related and PPPoE-related problems.

How to Diagnose Network Problems

If the PPP link becomes active but few hosts on the remote network are reachable, a network problem could be indicated. The following procedure shows you how to isolate and fix network problems that affect a PPP link.

Become superuser on the local machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Shut down the problematic link.

Disable any optional protocols in the configuration files by adding the following options to your PPP configuration:
noccp novj nopcomp noaccomp default-asyncmap
These options provide the simplest uncompressed PPP that is available. Try to invoke these options as arguments to pppd on the command line. If you can reach the previously unreachable hosts, add the options in either of the following places.
- /etc/ppp/peers/peer-name, after the call option
- /etc/ppp/options, ensuring that the options apply globally

Call the remote peer. Then enable debugging features.
% pppd debug call peer-name

Obtain verbose logs from the chat program by using the -v option of chat.

For example, use the following format in any PPP configuration file:
connect 'chat -v -f /etc/ppp/chatfile'
/etc/ppp/chatfile represents the name of your chat file.

Try to re-create the problem by using Telnet or other applications to reach the remote hosts.

Observe the debugging logs. If you still cannot reach remote hosts, the PPP problem might be network-related.

Verify that the IP addresses of the remote hosts are registered Internet addresses.

Some organizations assign internal IP addresses that are known within the local network but cannot be routed to the Internet. If the remote hosts are within your company, you must set up a name-to-address translation (NAT) server or proxy server to reach the Internet. If the remote hosts are not within your company, you should report the problem to the remote organization.

Examine the routing tables.
1. Check the routing tables on both the local machine and the peer.
2. Check the routing tables for any routers that are in the path from the peer to the remote system. Also check the routing tables for any routers on the path back to the peer.
  
  Ensure that the intermediate routers have not been misconfigured. Often the problem can be found in the path back to the peer.

(Optional) If the machine is a router, check the optional features.
# ndd -set /dev/ip ip_forwarding 1
For more information about ndd, refer to the ndd(1M) man page.

In the Solaris 10 release, you can use routeadm(1M), instead of ndd(1M).
# routeadm -e ipv4-forwarding -u
Note –
The ndd command is not persistent. The values set with this command are lost when the system is rebooted. The routeadm command is persistent. The values set with this command are maintained after the system is rebooted.

Check the statistics that are obtained from netstat -s and similar tools.

For complete details about netstat, refer to the netstat(1M) man page.
1. Run statistics on the local machine.
2. Call the peer.
3. Observe the new statistics that are generated by netstat -s. For more information, refer to Common Network Problems That Affect PPP.

Check the DNS configuration.

A faulty name service configuration causes applications to fail because IP addresses cannot be resolved.

Common Network Problems That Affect PPP

You can use the messages that are generated by netstat -s to fix the network problems that are shown in the following table. For related procedural information, refer to How to Diagnose Network Problems.

Table 21–2 Common Network Problems That Affect PPP


Message	Problem	Solution
`IP packets not forwardable`	The local host is missing a route.	Add the missing route to the local host's routing tables.
`ICMP input destination unreachable`	The local host is missing a route.	Add the missing route to the local host's routing tables.
`ICMP time exceeded`	Two routers are forwarding the same destination address to each other, causing the packet to bounce back and forth until the time-to-live (TTL) value is exceeded.	Use `traceroute` to find the source of the routing loop, and then contact the administrator of the router in error. For information about `traceroute`, refer to the traceroute(1M) man page.
`IP packets not forwardable`	The local host is missing a route.	Add the missing route to the local host's routing table.
`ICMP input destination unreachable`	The local host is missing a route.	Add the missing route to the local host's routing tables.

How to Diagnose and Fix Communications Problems

Communications problems occur when the two peers cannot successfully establish a link. Sometimes these problems are actually negotiation problems that are caused by incorrectly configured chat scripts. The following procedure shows you how to clear communication problems. For clearing negotiation problems that are caused by a faulty chat script, see Table 21–5.

Become superuser on the local machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Call the peer.

Call the remote peer. Then enable debugging features.
% pppd debug call peer-name
You might need to obtain debugging information from the peer in order to fix certain communications problems.

Check the resulting logs for communication problems. For more information, refer to General Communications Problems That Affect PPP.

General Communications Problems That Affect PPP

The following table describes symptoms that are related to log output from the procedure, How to Diagnose and Fix Communications Problems.

Table 21–3 General Communications Problems That Affect PPP


Symptom	Problem	Solution
`too many Configure-Requests`	One peer cannot hear the other peer.	Check for the following problems: The machine or modem might have faulty cabling. The modem configuration might have incorrect bit settings. Or, the configuration might have broken flow control. The chat script might have failed. In this situation, see Table 21–5.
The `pppd debug` output shows that LCP starts, but higher-level protocols fail or show CRC errors.	The asynchronous control character map (ACCM) is incorrectly set.	Use the `default-async` option to set the ACCM to the standard default of FFFFFFFF. First, try to use `default-async` as an option to `pppd` on the command line. If the problem clears, then add `default-async` to `/etc/ppp/options` or to `/etc/ppp/peers/peer-name` after the call option.
The `pppd debug` output shows that IPCP starts but terminates immediately.	IP addresses might be incorrectly configured.	Check the chat script to verify whether the script has incorrect IP addresses. If the chat script is correct, request debug logs for the peer, and check IP addresses in the peer logs.
The link exhibits very poor performance.	The modem might be incorrectly configured, with flow-control configuration errors, modem setup errors, and incorrectly configured DTE rates.	Check the modem configuration. Adjust the configuration if necessary.

How to Diagnose Problems With the PPP Configuration

Some PPP problems can be traced to problems in the PPP configuration files. The following procedure shows you how to isolate and fix general configuration problems.

Become superuser on the local machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Call the remote peer. Then enable debugging features.
% pppd debug call peer-name

Check the resulting log for the configuration problems. For more information, refer to Common PPP Configuration Problems.

Common PPP Configuration Problems

The following table describes symptoms that are related to log output from the procedure, How to Diagnose Problems With the PPP Configuration.

Table 21–4 Common PPP Configuration Problems


Symptom	Problem	Solution
`pppd debug` output contains the error message, `Could not determine remote IP address`.	The `/etc/ppp/peers/peer-name` file does not have an IP address for the peer. The peer does not provide an IP address during link negotiation.	Supply an IP address for the peer on the pppd command line or in `/etc/ppp/peers/peer-name` by using the following format: :10.0.0.10
`pppd debug` output shows that CCP data compression has failed. The output also indictes that the link is dropped.	The peers' PPP compression configurations might be in conflict.	Disable CCP compression by adding the `noccp` option to `/etc/ppp/options` on one of the peers.

How to Diagnose Modem Problems

Modems can be major problem areas for a dial-up link. The most common indicator of problems with the modem configuration is no response from the peer. However, you might have difficulties when determining if a link problem is indeed the result of modem configuration problems.

For basic modem troubleshooting suggestions, refer to Troubleshooting Terminal and Modem Problems in System Administration Guide: Advanced Administration. Modem manufacturers' documentation and web sites contain solutions for problems with their particular equipment. The following procedure helps determine whether a faulty modem configuration causes link problems.

Call the peer with debugging turned on, as explained in How to Turn on PPP Debugging.

Display the resulting /var/log/pppdebug log to check for faulty modem configuration.

Use ping to send packets of various sizes over the link.

For complete details about ping, refer to the ping(1M) man page.

If small packets are received but larger packets are dropped, modem problems are indicated.

Check for errors on interface sppp0:

% netstat -ni
Name  Mtu  Net/Dest   Address      Ipkts    Ierrs Opkts    Oerrs Collis Queue 
lo0   8232 127.0.0.0  127.0.0.1    826808   0     826808   0     0      0     
hme0  1500 172.21.0.0 172.21.3.228 13800032 0     1648464  0     0      0     
sppp0 1500 10.0.0.2   10.0.0.1     210      0     128      0     0      0

If interface errors increase over time, the modem configuration might have problems.

Troubleshooting

When you display the resulting /var/log/pppdebug log, the following symptoms in the output can indicate a faulty modem configuration. The local machine can hear the peer, but the peer cannot hear the local machine.

No “recvd” messages have come from the peer.
The output contains LCP messages from the peer, but the link fails with too many LCP Configure Requests messages that are sent by the local machine.
The link terminates with a SIGHUP signal.

How to Obtain Debugging Information for Chat Scripts

Use the following procedure for obtaining debugging information from chat and suggestions for clearing common problems. For more information, refer to Common Chat Script Problems.

Become superuser on the dial-out machine or assume an equivalent role.

Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Edit the /etc/ppp/peers/peer-name file for the peer to be called.

Add -v as an argument to the chat command that is specified in connect option.
connect "/usr/bin/chat -v -f /etc/ppp/chat-script-name"

View chat script errors in the file /etc/ppp/connect-errors.

The following is the main error that occurs with chat.

Oct 31 08:57:13 deino chat[107294]: [ID 702911 local2.info] expect (CONNECT)
Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] alarm
Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] Failed

The example shows timeout while waiting for a (CONNECT)string. When chat fails, you get the following message from pppd:

Connect script failed

Common Chat Script Problems

Chat scripts are trouble-prone areas for dial-up links. The following table lists common chat script errors and gives suggestions for fixing the errors. For procedural information, refer to How to Obtain Debugging Information for Chat Scripts.

Table 21–5 Common Chat Script Problems

Symptom

Problem

Solution

pppd debug output contains Connect script failed

Your chat script supplies a user name and password.

ogin: user-name
ssword: password

However, the peer that you intended to connect to does not prompt for this information.

Delete the login and password from the chat script.
Try to call the peer again.
If you still get the message, call the ISP. Ask the ISP for the correct login sequence.

The /usr/bin/chat -v log contains "expect (login:)" alarm read timed out

Your chat script supplies a user name and password.

ogin: pppuser
ssword: \q\U

However, the peer that you intend to connect to does not prompt for this information.

Delete the login and password from the chat script.
Try to call the peer again.
If you still get the message, call the ISP. Ask the ISP for the correct login sequence.

pppd debug output contains possibly looped-back

The local machine or its peer is hanging at the command line and not running PPP. An incorrectly configured login name and password are in the chat script.

Delete the login and password from the chat script.
Try to call the peer again.
If you still get the message, call the ISP. Ask for the correct login sequence.

pppd debug output shows that LCP activates, but the link terminates soon afterward.

The password in the chat script might be incorrect.

Ensure that you have the correct password for the local machine.
Check the password in the chat script. Fix the password if incorrect.
Try to call the peer again.
If you still get the message, call the ISP. Ask the ISP for the correct login sequence.

Text from the peer begins with a tilde (~).

Your chat script supplies a user name and password.

ogin: pppuser
ssword: \q\U

However, the peer that you intend to connect to does not prompt for this information.

Delete the login and password from the chat script.
Try to call the peer again.
If you still get the message, call the ISP. Request the correct login sequence.

The modem hangs.

Your chat script contains the following line to force the local machine to wait for the CONNECT message from the peer:

CONNECT ”

Use the following line when you want the chat script to wait for CONNECT from the peer:

CONNECT \c