This chapter provides reference material for working with PPP. The following topics are covered:
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
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".
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.
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.
The /etc/asppp.cf configuration file provides the PPP link manager on one endpoint machine with information about the machine on the other end of the link--or the machines on the other end of a multipoint (or dynamic point-to-point) link. When the machine boots, the link manager uses this information to establish and maintain communication with a remote endpoint.
The basic asppp.cf configuration file must contain at least two main sections: an ifconfig line and at least one path section. It can also contain a defaults section, which you use when you want to set the default values for an endpoint. (Refer to "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.
ifconfig ipdptp0 plumb nomada nubian-ppp up path interface ipdptp0 peer_system_name nubian-ppp # The name in the /etc/uucp/Systems file inactivity_timeout 300 # Allow five minutes before timing out |
The asppp.cf file must contain an ifconfig section with this syntax:
ifconfig interface-number plumb local-machine remote-machine up
Here is a description of the fields:
ifconfig - Tells the link manager to run the ifconfig command and begin configuring the PPP interface.
interface-number - Identifies the PPP interface ipdptpn for a point-to-point link or ipdn for a multipoint link. (Replace the n with the number of the interface.)
plumb - Option of ifconfig that enables IP to recognize the interface.
local-machine - Gives the name of the local endpoint, which can be the local host name or IP address.
remote-machine - Gives the name of the remote endpoint, which can be the remote host name or IP address.
up - Option of ifconfig that marks the interface just described as "up."
The link manager first runs the ifconfig command on the local machine to configure the ipdptp0 point-to-point interface. The zero in ipdptp0 gives the device number of the interface. The plumb option performs various activities necessary for IP to recognize the ipdptp0 interface. nomada is the name of the local host. nubian-ppp is the name of the dial-in server to which nomada connects through the point-to-point link. The ifconfig option up marks the ipdptp0 interface as up.
For more information about ifconfig, see "How to Check Interface Status" and the ifconfig(1M) man page.
The path section of the configuration file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. At a minimum the path section should contain the following lines:
path interface interface-number peer_system_name endpoint-name |
This keyword defines the PPP interface (either ipdptpn or ipdn). In Example 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.
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".)
The inactivity_timeout keyword is optional. It tells the link manager that the link can remain inactive for the interval designated. When that interval is passed, the link manager knows to automatically disconnect the link. The default interval is two minutes; you do not have to use inactivity_timeout unless you require a different inactivity interval.
You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate. "Configuration Keywords" has complete information about these keywords.
The asppp.cf configuration file for a multipoint dial-in server contains the same basic sections as that for a point-to-point link: an ifconfig section, at least one path section, and, if desired, a defaults section.
The following example shows a configuration file for the dial-in server nubian introduced in Example 24-1.
ifconfig ipd0 plumb nubian-ppp up path interface ipd0 peer_system_name tamerlane # The user name this remote # machine logs in with when it # dials this server peer_ip_address nomada # nomada is a remote machine that # dials in to this server # nomadb is another remote machine that dials in to nubian path interface ipd0 peer_system_name lawrence peer_ip_address nomadb # nomadc is another remote machine that dials in to nubian path interface ipd0 peer_system_name azziz peer_ip_address nomadc |
The ifconfig section for a multipoint dial-in server has a slightly different syntax than that for a point-to-point link. This syntax is:
ifconfig ipdn plumb server-name up
The major difference is that no destination 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.
The path section of the asppp.cf file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. However, on a multipoint dial-in server, you can include more than one path section. Additionally, some of the arguments to the keywords are used differently with multipoint links.
path interface interface-number peer_system_name endpoint-username peer_ip_address endpoint-hostname |
You need to define a path section for each nomadic endpoint with which the dial-in server can establish connections.
For a multipoint dial-in server, the interface keyword defines the PPP interface ipdn. You must specify the same PPP interface in the path section for every endpoint that communicates with the server through this interface.
The peer_system_name keyword takes a slightly different argument for a dial-in machine than a dial-out machine. For a dial-in server, this argument is the login name used by the remote host when it tries to establish communications with the server. This user name must already be present in the server's /etc/passwd file. When the login service reads this name, it verifies the user name in the /etc/passwd and /etc/shadow files enabling communications.
In this excerpt from Example 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.
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.
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.
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.
When a PPP link runs correctly, the asppp.log file includes diagnostic information in addition to its normal output. This section explains what the diagnostic messages mean. If your output is different, refer to RFC 1331.
This section contains messages that occur as the local host sends configuration information to the modem, and then as the modem tries to dial the remote host. These initial activities are actually handled by the UUCP daemon. You might think of them as the UUCP portion of asynchronous PPP communications. (Refer to Chapter 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 |
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.
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 |
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.
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.
You must update the hosts database on all machines involved in the dynamic-link configuration.
The next steps in the configuration process involve editing the /etc/passwd file and the /etc/shadow file. Edit these files for the dynamic-link configurations just as you would for the remote host-to-multipoint dial-in server configuration. Refer to "Modifying the /etc/passwd File" for information regarding the /etc/passwd and /etc/shadow files.
The asppp.cf configuration file for a dynamic-link configuration must contain information about remote hosts and the interfaces to use for the PPP link. After the dial-in server boots, its link manager uses this information to establish communications whenever the server is called by a remote endpoint.
The asppp.cf configuration file for a remote host is the same as the one described in "Parts of Basic Configuration File", except for the addition of the parameter negotiate_address:
ifconfig ipdptp0 plumb dummy mojave up path interface ipdptp0 peer_system_name mojave-ppp connectivity_timeout 300 negotiate_address on |
The negotiate_address parameter indicates whether local IP address assignment is obtained through negotiation and assigned dynamically. If set to "on", the IP address supplied by the server is used as the client's local address for the duration of the connection.
When the dial-in server receives an incoming packet, the link manager reads the path sections of its configuration file to identify the remote endpoint and determine the interface to use. The configuration file shown in Example 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:
ifconfig ipdptp0 plumb mojave clienta down ifconfig ipdptp1 plumb mojave clientb down ifconfig ipdptp2 plumb mojave clientc down # This means grab whatever interface is available (not in use) defaults interface ipdptp* # Each path specifies a machine that might dial up / log # in to this server path peer_system_name tamerlane # nomada uses the login name # tamerlane path peer_system_name lawrence # nomadb uses the name lawrence # for login path peer_system_name nomadc |
The ifconfig section for a dial-in server with a dynamically allocated link has the syntax:
ifconfig ipdptpn plumb server-name client-address down
Example 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 |
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.
The configuration file for the server with dynamic links must contain path sections for every remote host permitted to establish connections with the server. The path section has the following syntax:
path peer_system_name endpoint-username |
No interface keyword has been defined in the path section because this value is defined in the defaults section. The peer_system_name keyword has the same meaning here as it does in the configuration file for the multipoint server. See "path Section for Multipoint Dial-in Server" for more information.
You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate, including the use of security keywords as explained in "Configuration Keywords".
Virtual networks consist of a group of standalone computers, each in an isolated location, that can connect to each other through PPP multipoint links. "Virtual Networks" introduces virtual network concepts. This section explains how to configure a virtual network.
The network shown in 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.
You must add host information to the /etc/hosts file for each machine in the virtual network. When typing the IP addresses used for the PPP endpoints:
Designate a PPP-specific IP address for its point-to-point link. Note that if the machine was not previously configured in a physical network, you must create an IP address for the PPP link. This address becomes the host's primary network interface.
Create a network number for the virtual network. See "Assigning a Network Number to the PPP Link" for more information.
The first step in the configuration process involves updating the hosts and networks databases with information about your virtual network.
The /etc/inet/hosts file on each machine must contain the addressing information for every member of the network that this host has permission to access. For example, each host in the network in Figure 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 |
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 |
The next steps in the configuration process involve editing the UUCP databases, the /etc/passwd file, and the /etc/shadow file. You edit these files for the machines in the virtual network just as you would for the multipoint dial-in server configuration. Refer to "Editing UUCP Databases" for UUCP-related information and "Modifying the /etc/passwd File" for information regarding the passwd file.
The configuration file for a local machine on a virtual network must contain information about all remote hosts on the network that the local host can access. Moreover, each machine on the virtual network must be configured for both dial-in and dial-out functions. After the local machine boots, its link manager reads the asppp.cf file to establish communications.
The following example shows a configuration file such as you would set up for nomada on a virtual network 192.41.47.
# /etc/asppp.cf for hosta ifconfig ipd0 plumb nomada netmask + up defaults interface ipd0 path peer_ip_address nomadb peer_system_name lawrence # name machine logs in with path peer_ip_address nomadc peer_system_name azziz |
The following example shows a configuration file such as you would set up for nomadb on virtual network 192.41.47.
# /etc/asppp.cf for nomadb ifconfig ipd0 plumb nomadb netmask + up defaults interface ipd0 path peer_ip_address nomada peer_system_name tamerlane # name the machine logs in with path peer_ip_address nomadc peer_system_name azziz |
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.
Keywords |
Value Definition |
---|---|
Specifies whether the peer must authenticate itself. If either pap or chap is present, the peer must participate in authentication or end the connection. The default value is off. |
|
Specifies the name of the peer to be authenticated for the current path. peername string is one or more octets. To indicate a zero-length string, do not include the keyword. |
|
Specifies password for peer in one or more octets. To indicate a zero-length string, do not include the keyword. |
|
Specifies the secret used with the challenge value to generate the response sent by the peer. The format is one or more octets, preferably at least 16. |
|
Specifies the identity of the peer transmitting the packet. The name should not be NULL or terminated with CR/LF. The name is received from the peer in a response packet and consists of one or more octets. |
|
Specifies whether the system is willing to participate as the authenticated peer in the specified authentication process. If both pap and chap are present, the system is willing to participate in either authentication protocol. The default value is off. |
|
Specifies the name of the system to be sent to the authenticator in the response packet. To indicate a zero-length string, do not include the keyword. |
|
Specifies the password for the system to be sent to the authenticator in the response packet. To indicate a zero-length string, do not include the keyword. |
|
Contains the secret that is used with the received challenge value to generate the response sent to the authenticator. The format is one or more octets, preferably at least 16. |
|
Specifies the identity of the system. The name should not end with a NULL or CR/LF. The name is sent to the authenticator in a response packet. |
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.
Table 24-2 Required Keywords for asppp.cf
Keywords |
Value Definitions |
---|---|
Tells the link manager to run the ifconfig command with the values supplied by parameters. See "ifconfig Section of the asppp.cf File", "ifconfig Section for Multipoint Dial-in Server", and the ifconfig(1M) man page for more information. |
|
Specifies the beginning of the token sequences that are grouped as attributes of this (current) path. The collection of attributes comprising the current path are terminated by the occurrence of a subsequent path keyword, defaults keyword, or the end-of-file character. |
|
Specifies either an ipdptp (static point-to-point), ipdptp* (dynamic point-to-point), or ipd (multipoint) device for each interface in your network. For ipdptpn and ipdn, this keyword associates the specific interface defined by n with the current path. n must be a non-negative integer. It matches the interface defined in the path section with the interface stated in the ifconfig section.
For the ipdptp* interface, the * indicates that the interface will match any point-to-point interface that is configured as "down." |
|
On dial-out machines, specifies the hostname of the remote endpoint that the local machine wants to call. This is the same as the system name in the /etc/uucp/Systems file. Associates the remote system name with the current path. This name is used to look up modem- and peer-specific information for outbound connections in the /etc/uucp/Systems file. On dial-in machines, this keyword specifies the username that remote machines use when logging in to the dial-in machine. The appropriate path is determined by matching username with the login name that was used to obtain the connection. |
|
Specifies the destination host address. It is required only for multipoint links. This address is associated with the current path. The value is ignored if the path specifies a point-to-point interface. The address format can be dotted decimal, hexadecimal, or symbolic. |
The following table contains optional keywords for asppp.cf that you can use to further define your PPP configuration.
Table 24-3 Optional Keywords for asppp.cf