Chapter 24 PPP Reference

This chapter provides reference material for working with PPP. The following topics are covered:

• "UUCP Databases"

• "/etc/asppp.cf Configuration File"

• "PPP Troubleshooting"

• "Dynamically Allocated PPP Links"

• "Configuring a Virtual Network"

• "Rules for PAP/CHAP Keywords"

• "Configuration Keywords"

UUCP Databases

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

• /etc/uucp/Devices

• /etc/uucp/Dialers

• /etc/uucp/Systems

Updating /etc/uucp/Devices for PPP

The /etc/uucp/Devices file must contain entries for every communications device that a particular host uses or must know about. For example, if a machine uses a US Robotics V.32bis modem as part of the PPP link, you should ensure that /etc/uucp/Devices has an entry similar to the following:

# Use these if you have a USrobotics V.32bis modem on Port B.
ACUEC   cua/b - 9600 usrv32bis-ec
ACUEC   cua/b - 19200 usrv32bis-ec
ACUEC   cua/b - 38400 usrv32bis-ec

Be sure that the Devices file on each PPP endpoint machine has an entry describing its modem. For more information about /etc/uucp/Devices, refer to "UUCP /etc/uucp/Devices File".

Updating /etc/uucp/Dialers for PPP

The /etc/uucp/Dialers file must have an entry describing the conversation with the modem attached to your PPP endpoint machine. Here is a sample entry for a US Robotics V.32bis modem that is part of a PPP link:

usrv32bis-ec =,-,  "" \dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2\r\c OK\r 
\EATDT\T\r\c CONNECT\s14400/ARQ STTY=crtscts

The first parameter in the entry, usrv32bis, corresponds to the last parameter in the /etc/uucp/Devices file. The remainder of the entry describes the characters that the modem sends, those that it expects to receive, and so on. Table 27-5 defines the control codes used in the Dialers file.

Be sure that an entry is in the Dialers file for the modem attached to each dial-out endpoint on your link. If you are unsure of the correct conversation for a particular modem, refer to the System Administration Guide, Volume 1 and the operating manual for the modem.

Updating /etc/uucp/Systems for PPP

The /etc/uucp/Systems file contains entries for every machine to which the local host can dial out. Information in an entry might include the remote host's phone number, the line speed, and so on. Here is an example that host nomadb in Figure 23-1 might have for its dial-in server:

nubian-ppp  Any ACUEC 38400 5551212 "" P_ZERO "" 
\r\n\c login:-\r\n\c-login:-\r\n\c-login:-
EOT-login: bnomad password: Secret-Password

The first field gives the server's host name, nubian-ppp, a value used by the asppp.cf file keyword peer_system_name. ACUEC and 38400 refer to the device and speed, and are used to select an entry from the /etc/uucp/Devices file. The remaining information includes the phone number of the machine that nomadb is to dial in to, the login name that nomadb is using to log in, and so on. "UUCP /etc/uucp/Systems File" fully defines the parameters you need to supply to the Systems file.

On each remote host in your configuration, you must add an entry for its dial-in server. You can have additional entries in the /etc/uucp/Systems file for other machines to which the host can dial out for UUCP communications and for other PPP dial-in servers.

If the dial-in server also directly dials out to remote hosts, you must add entries to its Systems file describing each of these remote hosts.

/etc/asppp.cf Configuration File

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

Parts of Basic Configuration File

The basic asppp.cf configuration file must contain at least two main sections: an ifconfig line and at least one path section. It can also contain a defaults section, which you use when you want to set the default values for an endpoint. (Refer to "Configuration Keywords" for a description of keywords used in the defaults section.)

The following example shows a basic configuration file such as you would create for a remote host to establish a point-to-point link with a dial-in server.

Example 24-1 Basic Configuration File

ifconfig ipdptp0 plumb nomada nubian-ppp up
   path
      interface ipdptp0
      peer_system_name nubian-ppp      # The name in the /etc/uucp/Systems file
      inactivity_timeout 300           # Allow five minutes before timing out

ifconfig Section of the asppp.cf File

The asppp.cf file must contain an ifconfig section with this syntax:

ifconfig interface-number plumb local-machine remote-machine up

Here is a description of the fields:

• ifconfig - Tells the link manager to run the ifconfig command and begin configuring the PPP interface.

• interface-number - Identifies the PPP interface ipdptpn for a point-to-point link or ipdn for a multipoint link. (Replace the n with the number of the interface.)

• plumb - Option of ifconfig that enables IP to recognize the interface.

• local-machine - Gives the name of the local endpoint, which can be the local host name or IP address.

• remote-machine - Gives the name of the remote endpoint, which can be the remote host name or IP address.

• up - Option of ifconfig that marks the interface just described as "up."

The link manager first runs the ifconfig command on the local machine to configure the ipdptp0 point-to-point interface. The zero in ipdptp0 gives the device number of the interface. The plumb option performs various activities necessary for IP to recognize the ipdptp0 interface. nomada is the name of the local host. nubian-ppp is the name of the dial-in server to which nomada connects through the point-to-point link. The ifconfig option up marks the ipdptp0 interface as up.

For more information about ifconfig, see "How to Check Interface Status" and the ifconfig(1M) man page.

path Section of the asppp.cf File

The path section of the configuration file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. At a minimum the path section should contain the following lines:

path
   interface interface-number
   peer_system_name endpoint-name

interface Keyword

This keyword defines the PPP interface (either ipdptpn or ipdn). In Example 24-1, the following information appears in the path section:

interface ipdptp0	  
peer_system_name nubian-ppp

The interface keyword identifies ipdptp0 as the point-to-point interface that local endpoint nomada uses to communicate with the remote endpoint in the manner described in this path section. It associates the peer_system_name with the interface.

peer_system_name Keyword

On a dial-out machine such as a remote host, the peer_system_name keyword takes the host name of the remote endpoint as its argument. This is the name of the remote endpoint given in /etc/uucp/Systems. The name need not be the same as the host name on the corresponding ifconfig line.

The argument to the peer_system_name keyword for a dial-in server has a different value. See Example 24-1 for details.

In Example 24-1, peer_system_name identifies dial-in server nubian-ppp as the remote endpoint at the other end of this link. When the link manager reads the asppp.cf file, it then looks for the entry for nubian-ppp in the /etc/uucp/Systems file. (Recall that the Systems file contains information about how to set up communications with the remote endpoint, including that machine's telephone number. Refer to "Updating /etc/uucp/Systems for PPP".)

inactivity_timeout Keyword

The inactivity_timeout keyword is optional. It tells the link manager that the link can remain inactive for the interval designated. When that interval is passed, the link manager knows to automatically disconnect the link. The default interval is two minutes; you do not have to use inactivity_timeout unless you require a different inactivity interval.

Additional Keywords

You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate. "Configuration Keywords" has complete information about these keywords.

Configuration File for Multipoint Dial-in Server

The asppp.cf configuration file for a multipoint dial-in server contains the same basic sections as that for a point-to-point link: an ifconfig section, at least one path section, and, if desired, a defaults section.

The following example shows a configuration file for the dial-in server nubian introduced in Example 24-1.

Example 24-2 Configuration File for a Multipoint Dial-in Server

ifconfig ipd0 plumb nubian-ppp up

path
   interface ipd0
   peer_system_name tamerlane  # The user name this remote
                               # machine logs in with when it
                               # dials this server
   	peer_ip_address nomada
                               # nomada is a remote machine that
                               # dials in to this server

# nomadb is another remote machine that dials in to nubian

path
   interface ipd0
   peer_system_name lawrence
   peer_ip_address nomadb

# nomadc is another remote machine that dials in to nubian

path
   interface ipd0
   peer_system_name azziz
   peer_ip_address nomadc

ifconfig Section for Multipoint Dial-in Server

The ifconfig section for a multipoint dial-in server has a slightly different syntax than that for a point-to-point link. This syntax is:

ifconfig ipdn plumb server-name up

The major difference is that no destination endpoints are listed as arguments to ifconfig. Instead, the link manager obtains this information from the path section of the asppp.cf file.

In Example 24-2, the link manager first runs the ifconfig command on the dial-in server to configure multipoint interface ipd0. The zero in ipd0 gives the device number of the interface. The option plumb performs various activities necessary for IP to recognize the ipd0 interface. The ifconfig option up marks interface ipd0 as up.

You might have to supply a netmask + parameter on the ifconfig line if you use subnetting.

path Section for Multipoint Dial-in Server

The path section of the asppp.cf file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. However, on a multipoint dial-in server, you can include more than one path section. Additionally, some of the arguments to the keywords are used differently with multipoint links.

path
    interface interface-number
    peer_system_name endpoint-username
    peer_ip_address endpoint-hostname

You need to define a path section for each nomadic endpoint with which the dial-in server can establish connections.

interface Keyword

For a multipoint dial-in server, the interface keyword defines the PPP interface ipdn. You must specify the same PPP interface in the path section for every endpoint that communicates with the server through this interface.

peer_system_name Keyword

The peer_system_name keyword takes a slightly different argument for a dial-in machine than a dial-out machine. For a dial-in server, this argument is the login name used by the remote host when it tries to establish communications with the server. This user name must already be present in the server's /etc/passwd file. When the login service reads this name, it verifies the user name in the /etc/passwd and /etc/shadow files enabling communications.

In this excerpt from Example 24-2:

path
    interface ipd0
    peer_system_name scarlett
    peer_ip_address nomadc

the argument to peer_system_name is scarlett, indicating that when nomadc logs in to nubian-ppp, it uses the login name scarlett.

peer_ip_address Keyword

The peer_ip_address keyword is required for multipoint links. It takes the host name or IP address of the remote endpoint as its argument. The previous example uses the host name nomads as the argument to keyword peer_ip_address.

Additional Keywords

You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate. Refer to "Configuration Keywords" for a complete list of keywords.

PPP Troubleshooting

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

Analyzing Diagnostic Output

When a PPP link runs correctly, the asppp.log file includes diagnostic information in addition to its normal output. This section explains what the diagnostic messages mean. If your output is different, refer to RFC 1331.

Host and Modem Setup

This section contains messages that occur as the local host sends configuration information to the modem, and then as the modem tries to dial the remote host. These initial activities are actually handled by the UUCP daemon. You might think of them as the UUCP portion of asynchronous PPP communications. (Refer to Chapter 25, Overview of UUCP for complete details on UUCP.)

The following two messages should always appear at the beginning of the session. They indicate that the aspppd daemon has started successfully.

11:53:33 Link manager (1057) started 04/14/94
11:53:33 parse_config_file: Successful configuration

The next line indicates that a packet was routed to the ipdptp0 interface on the local host. It helps you to determine if a dial-out is occurring correctly. For example, if you tried to ping the remote machine and this message isn't in asppp.log, the packet was lost, probably due to a routing problem.

Next, UUCP checks for an entry that matches Ppac7 in a chat script in the /etc/uucp/Systems file. It then reports that it found an entry that had a device type ACUTEC. (For more information on the Systems file, refer to "UUCP /etc/uucp/Systems File".)

11:53:46 process_ipd_msg: ipdptp0 needs connection
conn(Ppac7)
Trying entry from '/etc/uucp/Systems' - device type ACUTEC.

UUCP then finds the dialing information for an ACUTEC dialer in the /etc/uucp/Devices file. When it finds the information, it opens the appropriate serial port on the local host and sets it with a speed of 9600. (For more information on /etc/uucp/Devices, see "UUCP /etc/uucp/Devices File".)

Device Type ACUTEC wanted
Trying device entry 'cua/a' from '/etc/uucp/Devices'.
processdev: calling setdevcfg(ppp, ACUTEC)
fd_mklock: ok
fixline(8, 9600)
gdial(tb9600-ec) calle

UUCP checks for the entry tb9600 in the /etc/uucp/Dialers file and then sends out these messages.

Trying caller script 'tb9600-ec' from '/etc/uucp/Dialers'
expect: ("")

The host waits a couple of seconds and then sets the registers on the modem. The information shown in the following log is modem specific. It comes from the /etc/uucp/Dialers file.

got it
sendthem (DELAY)
APAUSE
APAUSE
APAUSE
T&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M<NO CR>)

The next lines are the dialog between the modem and the host machine. expect (OK^M) means that the host expects the modem to send an "okay." The words got it at the end of the second line indicate that the host got the "okay" message from the modem.

expect: (OK^M)
AAAT&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M^M^JOK^Mgot it

Next, the host sends the following string to the modem, which does the actual dialing. The phone number in the second line is retrieved from the entry for the remote host in the /etc/uucp/Systems file.

sendthem (ECHO CHECK ON
A^JATTDDTT99003300887744^M^M<NO CR>)

The line beginning with expect indicates that the local host expects to get a response from the modem at a speed of 9600 bps. The next line indicates that the modem responded.

expect: (CONNECT 9600)
^M^JCONNECT 9600got it

This line indicates that hardware flow control has started on the link. The host obtains flow control information from the /etc/uucp/Dialers file.

STTY crtscts

In the next series of messages, the local host waits for the remote host to send it a standard UNIX login prompt.

getty ret 8
expect: ("")
got it
sandiest (^J^M)
expect: (login:)

The next messages indicate that the local host has received the login prompt from the remote. It then retrieves the appropriate login sequence from the chat script in the /etc/uucp/Systems entry for the remote host. This sequence is Ppong^M, which is required for login by the remote host.

^M^J^M^Jlogin:got it
sendthem (Ppong^M)

In these messages, the local host waits for the ssword prompt from the remote host. On receipt of the prompt, the local host sends the password retrieved from the chat script in the /etc/uucp/Systems entry for the remote host.

expect: (ssword:)
login: Ppong^M^JPassword:got it

The following messages indicate that dialing and modem connection completed successfully.

sendthem (ppptest1^M)
call cleanup(0)^M

Communications Between the Local and Remote Hosts

At this point, PPP communications start, as the link between local and remote hosts is now established.

The first lines in this part of the session constitute a configuration request (Config-Req). This is the first PPP packet sent to the remote host. The configuration request is one example of a Link Control Protocol (LCP) packet. It requests that configuration be set up and then sets up the PPP link between endpoint machines. The following example shows a sample configuration request.

Example 24-3 Configuration Request

11:54:20 004298 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req 
ID=4c LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP
AddrCCOMP

Here is a description of the configuration request.

• 11:54:20 - Time stamp field, indicating the time when the packet was sent

• 004298 - Number of the packet

• ipdptp0 - Network interface used

• SEND PPP ASYNC - Indicates that the modem is sending asynchronous PPP

• 29 Octets - Amount of data the host sent

• LCP - Packet type to send

• ID=4c - Identifier associated with the packet; it is actually part of the packet

• LEN=24 - Length of the LCP part of the packet

The remaining items are a list of options to be negotiated between hosts.

• MRU=1500 - Maximum receive unit (MRU), the largest packet size the calling host can receive from the remote host

• ACCM=00000000 - Asynchronous Character Map (ACCM), the mask sent to the remote host that tells what control characters to escape on transmission

• MAG#=69f4f5b2 - Magic number field; used for loopback-detection mechanism

• ProtFCOMP AddrCCOMP - Asks for the remote host to compress certain parts of the frame header (protocol field, address field)

The next lines are reporting invalid PPP packets. They come from the remote host, which is sending out UNIX text. This does not indicate a problem with PPP.

11:54:20 004299 ipdptp0 RECEIVE {Invalid ppp packet}PPP ASYNC 7
Octets [BAD FCS] {Unrecognized protocol:    1}

11:54:20 004299 ipdptp0 RECEIVE PPP ASYNC 73 Octets [BAD FCS]
{Unrecognized protocol:    880a}

In these packets, the local host receives the remote host's request for configuration, then sends out another configuration request. The packets are identical except for their ID fields. The ID field helps to distinguish between the two packets.

11:54:21 004301 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config-
Req  ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

11:54:21 004302 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req 
ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP
AddrCCOMP

In this packet, the local host acknowledges the remote request by sending it a configuration acknowledgment (Config-ACK).

11:54:21 004303 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK 
ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

The local host receives a configuration request (Config-Req) from the remote host.

11:54:21 004304 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config-
Req  ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

In these packets, the local host acknowledges the second packet sent by the remote host and receives the remote host's acknowledgment.

11:54:21 004305 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK 
ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

11:54:21 004306 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config-
ACK  ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP
AddrCCOMP

Here the local host negotiates parameters about IP transmission. LEN=16 gives the packet size. VJCOMP indicates Van Jacobsen header compression. IPADDR is followed by the calling host's IP address.

11:54:21 004307 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config-
Req  ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70

This packet indicates that the local host has received IP configuration from the remote host, including its IP address.

11:54:22 004308 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP
Config-Req  ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK
IPADDR=192.9.68.71

The local host sends this ACK to the remote host and receives an ACK from the remote host.

11:54:22 004309 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config-
ACK  ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71

11:54:22 004310 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP
Config-ACK  ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK
IPADDR=192.9.68.70

The first message that follows indicates that IP has started on the link. The next message indicates that the local host is sending IP traffic over the link.

11:54:22 start_ip: IP up on interface ipdptp0, timeout set for
120 seconds

11:54:24 004311 ipdptp0 SEND PPP ASYNC 89 Octets IP_PROTO

In the first message that follows, the local host receives IP traffic from the remote host. The subsequent messages indicate that the interface was disconnected because of an idle timeout.

11:54:25 004312 ipdptp0 RECEIVE PPP ASYNC 89 Octets IP_PROTO
11:56:25 process_ipd_msg: interface ipdptp0 has disconnected
11:56:25 disconnect: disconnected connection from  ipdptp0

The next messages begin the termination sequence. The first message indicates that the remote host has sent a packet to terminate the IP layer. The second is the local host's acknowledgment of the request to terminate.

11:56:25 004313 ipdptp0 RECEIVE PPP ASYNC 9 Octets IP_NCP Term-
REQ  ID=38 LEN=4

11:56:25 004314 ipdptp0 SEND PPP ASYNC 9 Octets IP_NCP Term-ACK 
ID=38 LEN=4

The local host receives a request to terminate the LCP layer. The second message is an acknowledgment of the request, causing a graceful shutdown.

11:56:25 004315 ipdptp0 RECEIVE PPP ASYNC 9 Octets LCP Term-REQ 
ID=39 LEN=4

11:56:25 004316 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-ACK 
ID=39 LEN=4

This message indicates that the link has closed.

11:56:29 004317 ipdptp0 PPP DIAG CLOSE

Dynamically Allocated PPP Links

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

Addressing Issues for Dynamically Allocated Links

You must add host information to the /etc/inet/hosts file for each machine that use the dynamically allocated PPP link. The IP addresses for the PPP endpoints should follow these conventions:

• For the dial-in server, you must use the IP address of the server's primary network interface (for example le0 or smc0) as the address of the dynamic link.

• For a dynamic link, you don't need to assign an IP address to each remote host (as you would for a static link), but you do need to assign a remote IP address to each point-to-point IP interface on the server. The number of IP interfaces you can use is equal to the number of modems your server is connected to. For example, if you have three modems, you need three point-to-point IP interfaces and three IP addresses.

• You must include a dummy IP address for the ifconfig command to work properly on the client. This address acts as a placeholder for the local IP address assigned to the client IP interface when PPP is started.

No restrictions are placed on the remote IP addresses that can be assigned to the IP interfaces, but, for clarity, it is probably best to include only IP addresses belonging to the same subnet.

Updating the hosts Database for Dynamic Links

You must update the hosts database on all machines involved in the dynamic-link configuration.

Considerations for Other Files

The next steps in the configuration process involve editing the /etc/passwd file and the /etc/shadow file. Edit these files for the dynamic-link configurations just as you would for the remote host-to-multipoint dial-in server configuration. Refer to "Modifying the /etc/passwd File" for information regarding the /etc/passwd and /etc/shadow files.

Editing asppp.cf for Dynamic Link

The asppp.cf configuration file for a dynamic-link configuration must contain information about remote hosts and the interfaces to use for the PPP link. After the dial-in server boots, its link manager uses this information to establish communications whenever the server is called by a remote endpoint.

Remote Host with Dynamic Link

The asppp.cf configuration file for a remote host is the same as the one described in "Parts of Basic Configuration File", except for the addition of the parameter negotiate_address:

ifconfig ipdptp0 plumb dummy mojave up
path
    interface ipdptp0
    peer_system_name mojave-ppp
    connectivity_timeout 300
    negotiate_address on

The negotiate_address parameter indicates whether local IP address assignment is obtained through negotiation and assigned dynamically. If set to "on", the IP address supplied by the server is used as the client's local address for the duration of the connection.

Dial-in Server With Dynamic Link

When the dial-in server receives an incoming packet, the link manager reads the path sections of its configuration file to identify the remote endpoint and determine the interface to use. The configuration file shown in Example 24-4 does not contain an interface keyword. Instead, the link manager uses interface information established in the defaults section.

The asppp.cf configuration file for a dial-in server with dynamically allocated links might look like the following:

Example 24-4 Configuration File for Server With Dynamically Allocated Link

ifconfig ipdptp0 plumb mojave clienta down
ifconfig ipdptp1 plumb mojave clientb down
ifconfig ipdptp2 plumb mojave clientc down

# This means grab whatever interface is available (not in use)
defaults
	    interface ipdptp*

# Each path specifies a machine that might dial up / log
# in to this server

path
    peer_system_name tamerlane   # nomada uses the login name
                                 # tamerlane
	   
path
    peer_system_name lawrence    # nomadb uses the name lawrence
                                 # for login
    
path
    peer_system_name nomadc   

ifconfig Section for Server With Dynamic Links

The ifconfig section for a dial-in server with a dynamically allocated link has the syntax:

ifconfig ipdptpn plumb server-name client-address down

Example 24-4 contains three ifconfig lines, each initializing a point-to-point interface.

ifconfig  ipdptp0  plumb  mojave  clienta  down
ifconfig  ipdptp1  plumb  mojave  clientb  down
ifconfig  ipdptp2  plumb  mojave  clientc  down

defaults Section for Server With Dynamic Links

When you configure a dynamically allocated link, you might want to include a defaults section in the asppp.cf file. This section sets the defaults for the value replacing keyword, wherever keyword subsequently appears in the asppp.cf file. The syntax for the defaults section is:

default 
     keyword

Example 24-4 uses the keyword interface to define the interface as ipdptp*, indicating a dynamic link. The asterisk wildcard tells the link manager to use any available ipdptp interface defined in the ifconfig section. Thus the link manager on server mojave uses either ipdptp0, ipdptp1, or ipdptp2--whichever is the first interface configured "down" that it finds.

path Section for Server With Dynamic Links

The configuration file for the server with dynamic links must contain path sections for every remote host permitted to establish connections with the server. The path section has the following syntax:

path
    peer_system_name endpoint-username    

No interface keyword has been defined in the path section because this value is defined in the defaults section. The peer_system_name keyword has the same meaning here as it does in the configuration file for the multipoint server. See "path Section for Multipoint Dial-in Server" for more information.

Additional Keywords

You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate, including the use of security keywords as explained in "Configuration Keywords".

Configuring a Virtual Network

Virtual networks consist of a group of standalone computers, each in an isolated location, that can connect to each other through PPP multipoint links. "Virtual Networks" introduces virtual network concepts. This section explains how to configure a virtual network.

Figure 24-1 Sample Virtual Network

The network shown in the sample consists of three isolated computers. Each member of the network connects to the other members of the network through a multipoint PPP link. Therefore, to create such a network, you (and perhaps other network administrators at the remote location) have to configure a multipoint PPP link on each participating host.

You use the same generic process for configuring multipoint links as you do for configuring a multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the virtual network has its own set of issues and requires you to configure each host in the network accordingly.

Addressing Issues for Virtual Networks

You must add host information to the /etc/hosts file for each machine in the virtual network. When typing the IP addresses used for the PPP endpoints:

• Designate a PPP-specific IP address for its point-to-point link. Note that if the machine was not previously configured in a physical network, you must create an IP address for the PPP link. This address becomes the host's primary network interface.

• Create a network number for the virtual network. See "Assigning a Network Number to the PPP Link" for more information.

Updating hosts and networks Databases

The first step in the configuration process involves updating the hosts and networks databases with information about your virtual network.

/etc/inet/hosts File for the Virtual Network

The /etc/inet/hosts file on each machine must contain the addressing information for every member of the network that this host has permission to access. For example, each host in the network in Figure 24-1 would have this information:

# Internet host table
#
127.0.0.1           localhost	loghost
192.41.47.15        nomada
192.41.47.20        nomadb
192.41.47.12        nomadc

/etc/inet/networks File for the Virtual Network

Because the virtual network requires a unique IP address, you must type this address in the networks database. For example, the network shown in Figure 24-1 has the number 192.41.47. Moreover, if the hosts on the network need to communicate with other networks, you should register the network with the InterNIC addressing authority. See "networks database" for information on editing the networks database.

Each host on the virtual network must have an entry with the network's address in the /etc/inet/networks file. For example, each host on network 192.41.47 might have the following in /etc/inet/networks:

# Internet networks
#
# arpanet   10          arpa
# ucb-ether 46          ucbether
#
# local networks
loopback    127
ppp         192.41.47   #remote sales offices

Considerations for Other Files

The next steps in the configuration process involve editing the UUCP databases, the /etc/passwd file, and the /etc/shadow file. You edit these files for the machines in the virtual network just as you would for the multipoint dial-in server configuration. Refer to "Editing UUCP Databases" for UUCP-related information and "Modifying the /etc/passwd File" for information regarding the passwd file.

asppp.cf Configuration File for a Virtual Network

The configuration file for a local machine on a virtual network must contain information about all remote hosts on the network that the local host can access. Moreover, each machine on the virtual network must be configured for both dial-in and dial-out functions. After the local machine boots, its link manager reads the asppp.cf file to establish communications.

The following example shows a configuration file such as you would set up for nomada on a virtual network 192.41.47.

Example 24-5 Configuration File for nomada

# /etc/asppp.cf for hosta

ifconfig ipd0 plumb nomada netmask + up
defaults
   interface ipd0
path
   peer_ip_address  nomadb
   peer_system_name lawrence	   	# name machine logs in with
path
   peer_ip_address nomadc
   peer_system_name azziz

The following example shows a configuration file such as you would set up for nomadb on virtual network 192.41.47.

Example 24-6 Configuration File for nomadb

# /etc/asppp.cf for nomadb

ifconfig ipd0 plumb nomadb netmask + up
defaults
   interface ipd0
path
   peer_ip_address   nomada
   peer_system_name  tamerlane  # name the machine logs in with
path
   peer_ip_address   nomadc
   peer_system_name  azziz

Rules for PAP/CHAP Keywords

• Either server or client can require authentication or offer to do authentication.

• If PAP and CHAP are both present, the authenticator first tries CHAP. If that fails, the link is terminated. The authenticator will not try PAP.

• The default value for PAP and CHAP authentication keywords is off. The syntax for keywords is:

  require_authentication off | pap[chap] | chap[pap] will_do_authentication off | pap[chap] | chap[pap]

• If you fail to specify pap_id and pap_password or pap_peer_id and pap_peer_password keywords and values for the associated path, the corresponding values are set to the NULL string.

• You must specify chap_name, chap_secret, chap_peer_secret, and chap_peer_name keywords and values for that path.

• peername - The name of the system at the other end of the point-to-point link from the authenticator. It takes the form of a string with the syntax specified below.

• string - A single token without embedded white space. The standard ANSI C \ escape sequence can be used to embed special characters. Use \s for the space character. Any pound sign at the beginning of the string must be escaped (\#) to avoid interpretation as a comment. A NULL (\0) truncates the string.

Configuration Keywords

This section describes the configuration keywords available for the asppp.cf configuration file and the values you must define for them. Most of these keywords are optional. The required ones are indicated. For further explanations of the keywords, refer to RFCs 1331, 1332, 1333, and 1334.

The following table lists required keywords that must appear in all asppp.cf configuration files.

The following table contains optional keywords for asppp.cf that you can use to further define your PPP configuration.