![[Go to CFHT Home Page]](/images/cfht-icon.gif){kind=icon}
Man Pages 
Back to Software Index 
Manpage Top Level
/usr/sbin/aspppls
SUNWapppu
aspppd is the link manager for the asynchronous data link protocol specified in RFC1331, The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links. It is a user level daemon that works in concert with the IP-Dialup driver (ipdcm) and PPP streams module ( ppp(7M) ) to provide IP network services over an analog modem using dialed voice grade telephone lines. The link manager automates the process of connecting to a peer (remote) host when PPP service with that host is required. The connection process can be initiated either by sending an IP datagram to a (disconnected) peer host or by receiving a notification that a peer host desires to establish a connection.
aspppls is the login service that connects the peer host machine to aspppd. aspppls is invoked by the serial port monitor when a peer machine logs into a PPP enabled account. Its purpose is to cause the link manager to accept the incoming call.
In the first case, it consults the UUCP database, dials the modem, logs into the peer host, establishes the PPP data link, brings up IP, and forwards the IP datagram that initiated the process.
In the second case, the link manager opens the file descriptor supplied by the login service, establishes the PPP data link, and brings up IP.
If the link manager determines that there has been no IP traffic for the period specified by the inactivity_timeout keyword, it disconnects the link by bringing down IP and PPP and closing the connection with the peer host.
The link manager can be reinitialized by sending it the -HUP signal (with kill(1) for example), which causes it to disconnect all open PPP links and reread the configuration file.
A path is an object that contains the state of a connection with a peer host. Information such as system names, interface names, timeout values, and other attributes are kept in the path object. There exists a path for each potential peer host. Paths are defined in the configuration file.
The link manager supports two types of IP layer interfaces; the point-to-multipoint interface (ipd) and the point-to-point interface (ipdptp) (see ppp(7M) ).
The point-to-multipoint interface logically connects the host machine to a network containing one or more peer hosts. IP traffic to or from any of the peer hosts is routed through the point-to-multipoint interface. When an ipd interface is configured, only one IP address, that of the host, is assigned. In other words, it behaves very similarly to an Ethernet interface, although the broadcast capability is not supported. This type of interface is well suited for a dial in PPP server.
The point-to-point interface logically connects the host machine with one peer host. Only IP traffic to or from the peer host is routed through this interface. When an ipdptp interface is configured, two IP addresses are assigned. This type of interface is well suited to support a remote, or nomadic, machine.
An interface must be fully configured and enabled (i.e. up) before an IP datagram will be routed to it. It’s also true that a point-to-multipoint interface must be fully configured and enabled before the link manager will associate an incoming connection with it. It’s not necessary, however, for a point-to-point interface to be configured and enabled before an incoming connection will be assigned to it. A point-to-point interface that is "plumbed", but otherwise not configured or enabled (i.e. down), can be used to accept an incoming connection if the path associated with the potential connection contains a dynamic interface specification (e.g. interface ipdptp*). In this case the link manager will select a disabled (down) interface, configure the host and peer addresses, bring it up, and assign it for the duration of the connection.
Special attention should paid to routing issues that may arise if a host has more than one interface configured and enabled. By definition, a host with more then one enabled interface is a router, and the routing daemon (typically in.routed) will advertise the routes provided by the PPP interfaces. This is normally acceptable behavior for a dial in server, but can cause network disruptions if not administered properly.
To prevent routing information packets (RIP) from flowing over point-to-point interfaces, specify the norip keyword followed by the interface name in the /etc/gateways file. These entries, for example, prevent RIP from being sent over ipdptp0 and ipdptp1:
See in.routed(1M) for further information.
norip ipdptp0 norip ipdptp1
The link manager can be configured to support either the Password Authentication Protocol (PAP) or the Challenge Handshake Authentication Protocol (CHAP) as specified in RFC1334. Both protocols can be configured simultaneously, in which case, CHAP has precedence. A single host may participate as an authenticator (the local host requests that the peer host authenticate itself) or an authenticatee (the local host has been asked by the peer host to authenticate itself) or as both. It is also possible for a host to be an authenticator for one protocol and an authenticatee for the other protocol.
PAP is a simple protocol similar to a standard login/password type of authentication. The PAP authenticator sends a message to its peer requesting that the peer authenticate itself. The peer responds with an authenticate request packet that contains an id and a password (both in plaintext). The id and password are matched against a local copy, and if they match, the connection is established. If they don’t match, the connection is dropped.
CHAP does not pass any plaintext authentication data across the link. The CHAP authenticator sends a challenge packet to the peer that contains a random string. The peer then takes the string in the challenge packet and computes a response string that is a function of the challenge string and a shared secret key. The peer then sends a response packet back to the authenticator. The authenticator computes a string based on the original challenge string and the shared secret key and matches that result with the received response. If they match, the connection is established. Otherwise the connection is dropped.
The primary purpose of the /etc/asppp.cf configuration file is to define each path used by the link manager to establish and maintain communication with a peer system.
The file consists of a sequence of tokens separated by white space (blanks, tabs, and new lines). There are no record boundaries or any other constraints on the placement of the tokens. If a token begins with a pound sign (#), all characters between the pound sign and the next newline (\n) are ignored (i.e. they are treated as a comment). Alphanumeric tokens are case insensitive and are translated by the lexical analyzer into lower case before further processing.
A string is a single token that does not contain embedded white space. The standard ANSI C \ escape sequence may be used to embed special characters (see an ANSI C manual for a list of escaped special characters). Use \s for the space character. If a pound sign appears at the beginning of a string, it must be escaped (\#) to avoid interpretation as a comment. A NULL (\0) will truncate the string.
Groups of tokens are assembled into units known as paths (essentially a human-readable form of the path object). A path begins with the keyword path and ends at the token found before any subsequent path (or defaults) keyword or at the last token in the file. The tokens comprising a path are further partitioned into small groups consisting mostly of keyword/value pairs that define the attributes of the current path. If a particular keyword/value pair is not listed for a path, the default value is assumed.
The token sequences that begin with the substrings ipcp_ or lcp_ refer to PPP initial configuration options as specified in RFC1332, The PPP Internet Protocol Control Protocol (IPCP). See the RFC for a more complete definition of these options.
The following is an alphabetic list of the token sequences that can be contained in a configuration file. Required sequences are noted.
| level | meaning |
| _ | _ |
| 0 | errors only |
| 1 | minimal information |
| 4 | some uucp chat-script info |
| 5 | all uucp chat-script info |
| 7 | maximum uucp info |
| 8 | PPP message traces |
| 9 | Raw IP packets |
In this example, the remote machine is most likely a nomadic or home machine with a single modem.
# # Dial in to two servers # ifconfig ipdptp0 plumb nomad1 dialin1 private up path interface ipdptp0 peer_system_name Pdialin1 will_do_authentication pap pap_id nomad1 pap_password secret ifconfig ipdptp1 plumb nomad1 dialin2 private up path interface ipdptp1 peer_system_name Pdialin2 lcp_mru 1006
This example shows a dial in server supporting a point-to-multipoint interface. There may be several modems attached to this server. Note that the network addressed by the ipd interface will be advertised by the router, and all traffic destined for that network will be routed through this host. For that reason, it is not wise to support multiple dial in servers with point-to-multipoint interfaces to the same network.
# # A point-to-multipoint dial in server # ifconfig ipd0 plumb dialin1 netmask + up defaults interface ipd0 inactivity_timeout 900 # 15 minutes require_authentication chap pap chap_peer_name nomads path peer_system_name Pnomad1 pap_peer_id nomad1 pap_peer_password secret path peer_system_name Pnomad2 chap_peer_secret a\sspace path peer_system_name Pnomad3 inactivity_timeout 0 # No timeout for this host chap_peer_secret \#123;. path peer_system_name Pnomad4 chap_peer_secret My\sSecret#Word
This is another dial in server that supports dynamic point-to-point interfaces. Usually the server has one modem for each interface. One advantage of using dynamic interfaces is that (host) routes will only be advertised when an interface is up. Therefore, multiple dial in servers can be supported.
# # A dynamic point-to-point dial in server # ifconfig ipdptp0 plumb dialin2 down ifconfig ipdptp1 plumb dialin2 down ifconfig ipdptp2 plumb dialin2 down defaults interface ipdptp* inactivity_timeout 900 debug_level 5 path peer_system_name Pnomad1 path peer_system_name Pnomad2 negotiate_address off path peer_system_name Pnomad3 path peer_system_name Pnomad4