INFODOC ID: 11976
SYNOPSIS: PPP PSD/FAQ
DETAIL DESCRIPTION:

SunService Tip Sheet for Sun PPP

Revision: 1.8
Date: December 21, 1995

1.0: About PPP
  1.1: The basic components of PPP 
2.0: Debugging PPP 
  2.1: Checking Your Configuration 
  2.2: Turning On PPP Debugging 
  2.3a: Checking Dial-Out Connection Establishment 
  2.3b: Checking Incoming PPP Connection Establishment 
  2.4:  PPP Option Negotiations 
  2.5: Basic TCP/IP Connectivity 
  2.6: Routing 
3.0: Common How Tos 
  3.1: How to Prepare Your Machine for PPP 
  3.2: How to Set Up a Dial-out PPP Client Machine 
  3.3: How to Set Up an Advanced Dial-out PPP Client Machine 
  3.4: How to Set Up a PPP Server on a LAN, With Static IP Addresses 
  3.5: How to Set Up a Dial-In PPP Server, With Dynamic IP Addresses 
  3.6: How to Set Up a Network-to-Network PPP Link 
  3.7: How to Set Up A Normal User to Start and Stop the PPP Daemon 
  3.8  How do I enable the Dynamic Address capability on Solaris 2.5 aspppd? 
4.0: Some Frequently Asked Questions 
  4.1: General PPP Questions 
  4.2: Modems & Serial Ports 
  4.3: PPP Dial-In Questions & Problems 
  4.4: PPP Link Activity 
  4.5: Routing Questions 
  4.6: Other PPP Error Messages 
  4.7: PPP Performance Tuning 
5.0: Patches 
  5.1: Solaris 2.3 PPP Patches 
  5.2: Solaris 2.4 PPP Patches 
  5.3: Solaris 2.4x86 PPP Patches 
  5.4: Solaris 2.5 PPP Patches 
  5.5: Solaris 2.5x86 PPP Patches 
6.0: Known Bugs & RFEs 
7.0: References 
  7.1: Important Man Pages 
  7.2: Sunsolve Documents 
  7.3: Sun Educational Services 
  7.4: Solaris Documentation 
  7.5: Third Party Documentation 
  7.6: RFCs 
  7.7: Other Internet Resources 
8.0: Supportability 
9.0: Additional Support

1.0: About PPP PPP stands for the Point-to-Point protocol. It is an industry-standard protocol for sending network packets over a point-to-point link. Sun has many PPP implementations (PC-NFS, Sunlink PPP, Sunlink ISDN), but this Tip Sheet only discusses the asynchronous PPP bundled with Solaris 2.3 and above. The basic information about PPP comes from a couple sources: For Solaris 2.3: the System Adminstrator's answerbook and hardcopy documentation set includes the manual: SunOs 5.3 Administering TCP/IP and PPP For Solaris 2.4: the System Adminstrator's Answerbook and hardcopy documentation set includes the manual: TCP/IP Network Administration Guide The man pages aspppd(1M) and ppp(7). For more background information about PPP, the internet Request for Comments define the internet protocol standards. Sun's PPP implemenation is based on RFC 1331. (See Section 7.0 for more information on how to access this RFC, and for full information on all of the references mentioned here.) If Sun's bundled asynchronous PPP program does not provide sufficient functionality, you may interested in an alternate product, Sunlink PPP version 3.0. Features include: - support for internet standards 1144, 1331, 1332, 1334, 1661, 1662 - simple port and modem configuration - chat scripts that can be recorded and reused later - dynamic address assignment - authentication using PAP and CHAP - support for synchronous serial lines - automatic or manual connection establishment - powerful tracing/debugging options Other sun products that use PPP in some way are: - Sunlink ISDN 1.0.2 which uses a modified version of PPP. - Sunlink PPP 1.0 and 2.0, which support synchronous connections only. All Sunlink products are unbundled software packages which may be purchased from Sun. If you are interested in one of these products, you should contact your local Sun Sales office.

1.1: The basic components of PPP

The following files and programs are used by PPP. /usr/sbin/aspppd - the PPP link manager is used to initiate PPP connections. When packets are queued for a PPP interface that isn't physically connected, the link manager attempts to initiate the connection. /etc/asppp.cf - the configuration file read by aspppd on startup. It defines the interfaces that are configured and the characteristics that define a PPP connection ("path"). /etc/log/asppp.log - the PPP log file. This contains log information about each inbound and outbound connection. When aspppd is invoked with higher levels of debugging, this will contain important information about the caller scripts for dialing out to other systems, as well as the PPP negotiation that takes place when a link comes up. (note that this file is also /var/adm/log/asppp.log) /etc/init.d/asppp - the startup script executed when the system boots. It executes all the 'ifconfig' lines in /etc/asppp.cf, then starts the daemon /usr/sbin/aspppd. This file is also known as /etc/rc2.d/S47asppp, /etc/rc0.d/K47asppp and /etc/rc1.d/K47asppp (these are link). It can be used to stop PPP with the command: # /etc/init.d/asppp stop and start PPP again with: # /etc/init.d/asppp start /tmp/.asppp.fifo - this file is created by the link manager, aspppd, for communication with the login service, aspppls. If it is missing, the link manager probably isn't running. The following components are used only on PPP client systems (systems that dial out): /etc/uucp/Systems - This defines the baud rate, phone number and login chat script to log into a server system from a client system. When the link manager initiates a dial-out connection, it uses the peer_system_name defined in asppp.cf to match a system name in this file. /etc/uucp/Devices - matches the third field in the Systems file and defines an entry in the dialers file to use. /etc/uucp/Dialers - defines the chat script to initialize a modem, dial the phone number from the Systems file and connect to the server system. The following components are used only on PPP server systems (systems that have dial-in PPP clients): /usr/sbin/aspppls - the PPP login service is invoked as a login shell for dial-in PPP connections. It communicates with aspppd through /tmp/.asppp.fifo to initiate inbound PPP connections. (The ppp user must have /usr/sbin/aspppls configured as their login shell on server systems to start ppp when the user logs in.) /etc/passwd - should have a login name defined for each PPP user with the login shell /usr/sbin/aspppls. The login name is matched against a name defined in the 'peer_system_name' section of the /etc/asppp.cf file. Only the first 8 characters of the login name will be used.

2.0: Debugging PPP

2.1: Checking Your Configuration

Verify that you have met all the prerequisites listed in Section 3.1. Make sure you have the correct packages installed and get the correct patches. Make sure that all the host names in the ifconfig lines, and all the peer_ip_address sections of the /etc/asppp.cf file are defined in the /etc/hosts file.

2.2: Turning On PPP Debugging

To turn on debugging, you must make sure that PPP is started with the appropriate debug level. First, stop the ppp daemon: # /etc/init.d/asppp stop Then change the debug_level of the 'path' you want to debug to level 9 by adding: debug_level 9 to the file /etc/asppp.cf. An alternate method is to edit the file/etc/init.d/asppp to change the line: /usr/sbin/aspppd -d 1 to: /usr/sbin/aspppd -d 9 A good way to debug PPP is to run openwindows and open 2 windows. In the first window, run the command: # tail -f /etc/log/asppp.log This will show the log file and update continuously as messages appear. This is especially helpful to see actions and problems logged as they occur. In the other window, start the daemon and attempt to start up the ppp link. # /etc/init.d/asppp start If the daemon properly started, the log window should show something like this: 09:26:57 Link manager (83) started 6/27/94 09:26:58 parse_config_file: Successful configuration

2.3a: Checking Dial-Out Connection Establishment

For a dial-out connection, PPP uses the same files as cu and uucp to select an outgoing line, initialize the modem, dial the phone, log into the remote system and start the remote PPP session. With the two-window setup above, you can say: # ping <farside> and the log window should show some sort of progress. It should show the system being dialed using the /etc/uucp/Systems, Devices and Dialers files. The message: Call Failed: SYSTEM NOT IN Systems FILE indicates that the peer_system_name entry did not match an entry in the /etc/uucp/Systems file. The message: Call Failed: CALLER SCRIPT FAILED indicates that some expect/send sequence failed. All must work before the ppp link will come up. Each of the uucp files have documentation in Section 3.0, but pay special attention to the P_ZERO and STTY=crtscts sequences as defined in the example dial-out system described in the Notes of Section 3.2. The uucp scripts have completed successfully when this message appears in the log file: call cleanup(0) Next, PPP will come up and start negotiating the link parameters. An extra tip for debugging login problems, you can type # cu -d -L systemname in Solaris 2.4, and it will log in using the same files as PPP. You should be able to see the raw PPP packets if logged in correctly to the other system. (Raw PPP packets start and end with a ~ character and usually have a lot of } characters in them). In Solaris 2.3, you can use cu as well, but there is no -L flag to execute the login sequence in the /etc/uucp/Systems file.

2.3b: Checking Incoming PPP Connection Establishment

If you are debugging an incoming connection, you should watch the 'tail -f /etc/log/asppp.log' from above while the other system attempts to log in. If the log file didn't show any changes, then maybe the login user isn't even getting logged in. Another problem may be that /usr/sbin/aspppls is not the login shell for the ppp user. If the message: 10:13:22 get_fifo_msg: can't find path with peer_system_name joeppp shows up, then the login name joeppp doesn't correspond to any path in /etc/asppp.cf that has the peer_system_name of joeppp (note that only the first 8 characters of a login name are checked). If PPP packets start appearing like this: 17:50:05 066790 ipdptp0 RECEIVE PPP ASYNC 23 Octets NB LCP Config-ACK ID=29 LEN=18 MRU=1500 MAG#=2ccfbb2d ProtFCOMP AddrCCOMP Then PPP negotiations have started and this step is complete.

2.4: PPP Option Negotiations

At this point, there should be 2 PPP daemons talking to each other over the serial lines. They start with a negotiation phase where the Link Control Protocol exchanges options between the two systems. They will try to exchange IP addresses, maximum packet sizes and compression options. Each system will start by sending Configuration Request (Config-Req) packets. If every option in the packet is acceptable to the receiving system, it will return a configuration acknowledgement packet (Config-ACK). However, if there is a problem with the options that a system has requested, the receiving system will send back a Configuration NAK (Config-NAK) packet, listing the unacceptable options and their values. Boolean options (options that are on or off) are returned in a Configuration Reject (Config-REJ) packet. If negotiations end with the message: process_ppp_msg: PPP_ERROR_IND Loop back detected Then there is a communications problem. What this means is that every configuration packet that the PPP process has sent has been echo'd back verbatim. This is not a negotiation problem, it is a communications problem. See the question and answer section for a more thorough explanation of this message. See Section 4.3 for more information. If this message appears: process_ppp_msg: PPP_ERROR_IND Maximum number of configure requests exceeded the PPP process has sent 10 configuration requests without any configuration acknowledgements and has given up. This means that the other side isn't responding at all, or has stopped responding after option negotiation has failed. The question and answer section has a more thorough explanation of this message. See Section 4.3 for more information. When all the options have been correctly negotiated, a message like: 11:56:01 start_ip: IP up on interface ipdptp0, timeout set for 0 seconds will appear in the log file, and IP packets will be transferred back and forth.

2.5: Basic TCP/IP Connectivity

At this point, both systems start exchanging IP packets. The log file will show IP and TCP packets being exchanged. The most common problems now occur with ip address assignments and routing. If you can ping the other side of the PPP link *by IP address*, then the address negotiation is probably ok and this step is complete. If it works by IP address, but not by name, then you have a naming service problem. Make sure the name is in your /etc/hosts file and check nsswitch.conf. Sometimes, however, the PPP negotiation phase changes some of the IP addresses, and ping will not work. The easiest way to check this is to do: # ifconfig -a and see if the ppp link shows the ip addresses you expected for both ends of the link. If the adresses have changed since before the link was brought up, then one or both sides of the link has configuration errors to be resolved. You can track a lot of this down in the configuration section of the /etc/log/asppp.log file. Look closely for Config-NAK packets showing IP addresses. This means that some IP addresses are being rejected and probably re-negotiated. If it still isn't working, check to make sure packets are actually going back and forth. Check to see if entries appear in the log file (usually marked IP_PROTO) when you ping the other side of the link. If you see packets in the log file, but with {Unescaped characters} messages, it is possible that the other computer is not negotiating the async control character map correctly. Try adding 'ipcp_async_map 0' to /etc/asppp.cf for the path to that system. (See the question on unescaped characters later in this document.) See Section 4.6 for more information. Make sure that the interface is marked UP in the ifconfig line on both sides. One common configuration error is ifconfig ipdptp0 plumb thisside otherside down path interface ipdptp0 peer_system_name sysppp The asppp.log file will show packets coming into the system but no responses being returned. This is because 'interface ipdptp0' will not automatically configure the interface up on connection like 'interface iptpdp*' does. In rare cases, (usually when PPP and another interface share the same IP address), duplicate routes in the routing tables may cause problems. Make *sure* that the current patches are applied to your system. If you can ping the other end of the PPP link, this part is complete.

2.6: Routing

If you can ping the other side of the link, but can't ping other systems in the network, this is a routing problem. Routing is used to determine where a packet will go. The routing tables are maintained in the kernel, and are either statically defined at boot time (static routing) or updated periodically when the system is up (dynamic routing). For a brief description, see the Q and A section later. For a much more technical answer, see the man pages for routing(4). These problems with routing can be broken down this way: For a ping (or a telnet, etc) to work correctly, there must be a route from the source system, through all the intermediate systems, to the target system. *AND* *BACK*! To simplify things, always ping by IP address when debugging these problems. The most common routing problem is this: A <--ppp--> B <--ethernet--> C System A (a ppp system) can ping system B (the PPP server). However, A cannot ping C. System B can ping system C. System C can ping B. System A just gets no answer to each ping. The answer is probably that C doesn't have a route *BACK* to A. This can be tested by logging onto C and typing: # ping A ICMP Host Unreachable from gateway C (192.9.200.1) for icmp from C (192.9.200.1) to 192.9.201.1 You can get around this by letting system B use proxy ARP for system A (and making A's IP address on the same LAN as system B's le0), or by setting up routing protocols on system B so that the route to A is propagated to system C. Proxy ARP is explained further in Section 4.5. These problems can also be diagnosed by using the snoop command to trace where the ping packets are going (and where they're not going!)

3.0: Common How Tos

3.1: How to Prepare Your Machine for PPP

The packages needed for PPP are: SUNWapppr PPP/IP Asynchronous PPP daemon configuration files SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service SUNWpppk PPP/IP and IPdialup Device Drivers If you will have dial-out connections, you will also need: SUNWbnur Networking UUCP Utilities, (Root) SUNWbnuu Networking UUCP Utilities, (Usr) To check to see if the packages are installed correctly, use the pkgchk command: # pkgchk SUNWpppk SUNWapppu SUNWapppr ERROR: /etc/asppp.cf group name <sys> expected <other> actual file size <360> expected <689> actual file cksum <27915> expected <57161> actual # The message above just says that the file /etc/asppp.cf has changed since it was installed on the system. This is ok since the default asppp.cf file is empty and is always modified when configuring PPP. NOTE: Some device files may not be properly created when the PPP packages are installed after the initial system installation (bugid 1162353). This is indicated by missing /dev/ipd, /dev/ipdptp and /dev/ipdcm files. This bug can be avoided if the PPP packages are installed in the following order: SUNWpppk, SUNWaspppr, SUNWaspppu. After you have installed all of the correct packages, reboot with the -r flag: # reboot -- -r Or boot with: ok boot -r You must also have installed the PPP patches referenced in Section 5.0, and should be aware of the bugs which are referenced in Section 6.0.

3.2: How to Set Up a Dial-out PPP Client Machine

This example shows a home machine or a remote machine whose ONLY interface is the PPP link. There is NO local ethernet. If you require a this, look at the client side of the network to network example in section 3.6. The machine is connected to an internet service provider who provides two static IP addresses for the PPP link (for the sun and the gateway) as well as the ip address of a DNS server to point to. Notes: PPP does not support dynamic ip address assignments in 2.3 or 2.4. If your service provider doesn't give you a static IP address, you may have to wait for Solaris 2.5, which supports dynamically assigned ip addresses, when specified in the asppp.cf file. The provider normally gives you these things: - your ip address (we'll use 192.9.200.1) - a gateway ip address (we'll use 192.9.200.253) - a dns server ip address (we'll use 192.9.200.10) - a domain name (we'll use mycorp.com) You should do the following steps to set your PPP client up correctly: 1) install the system as a networked system. For naming service, chose OTHER. Do not choose NIS+ or NIS. 2) Remove /etc/hostname.le0 to prevent the le0 interface from being configured and brought up when the system is booted. (The primary interface will be the PPP interface, and it will be configured when S47asppp is executed.) Make sure the hostname in /etc/nodename is correct and corresponds to the ip address of the PPP link. Assumption: the local ethernet interface is not used because this example assumes just one machine. 3) create /etc/asppp.cf: ifconfig ipdptp0 plumb 192.9.200.1 192.9.200.253 up path interface ipdptp0 inactivity_timeout 300 # drop idle link after 5 minutes peer_system_name myprovider # matches "myprovider" in # /etc/uucp/Systems ipcp_async_map 0 # more efficient # debug_level 5 # uncomment for chat script debugging # debug_level 9 # uncomment for ppp negotiation debugging 4) create /etc/defaultrouter: 192.9.200.253 5) create /etc/resolv.conf: domain mycorp.com nameserver 192.9.200.10 6) set up nsswitch.conf so the system looks at dns: # cp /etc/nsswitch.files /etc/nsswitch.conf # vi /etc/nsswitch.conf and add "dns" to the hosts line of the nsswitch.conf, so that it looks like this: hosts: files dns 7) set up the modem port as a dial-out modem or a bidirectional modem using admintool's serial port manager 8) create an entry in /etc/uucp/Systems for 'myprovider'. This name matches the peer_system_name line in the asppp.cf file. # cd /etc/uucp # grep myprovider Systems myprovider Any ACUTEC 9600 9030874 "" P_ZERO "" login:-\r\n\c-login:-\r\n\c-login:-EOT-login: mylogin ssword: mypasswd # grep ACUTEC Devices ACUTEC cua/a - Any tb9600-ec # grep tb9600-ec Dialers tb9600-ec =W-, "" \dA\pA\pA\pT&D2E1V1X1Q0S2=255S12=255S50=6S58=2\r\c OK\r \EATDT\T\r\c CONNECT\s9600 STTY=crtscts At this point, reboot the system. A ping to the far side of the PPP link (192.9.200.253) should start bringing up the link. Note: it is ok if the ping fails - see the Q & A about ping later in this document. [[IN SECTION 4.X]] Notes: The 3 lines in the Systems file and the 2 lines in the Dialers file were wrapped for this document. They really are one line. If you execute /etc/init.d/asppp stop the system may appear to hang or slow down because the primary interface will be marked down. This may cause problems with some applications. Static routing will be used (in.routed will not be started) because the /etc/defaultrouter file has a default route defined. If DNS isn't used, just skip steps 5 and 6 and make sure that systems you want to contact by name are in the /etc/hosts file. Note that the reference to 'tb9600-ec' in the Dialers file corresponds to a specific modem type, a telebit trailblazer at 9600 baud with error correction. In general, this field must correspond to the correct entry in the Dialers file for your modem. If there is no entry for your modem, you should create one along the guidelines described later in this document. See Section 4.2. For more information about the uucp files (Systems, Devices and Dialers), look at the files. Each has a header defining the fields. Also look at "TCP/IP Network Administration Guide" (for Solaris 2.4) or "SunOS 5.3 Administrating TCP/IP and PPP" (for Solaris 2.3). Pay *SPECIAL* attention to two expect/send sequences in the uucp files. The "" P_ZERO expect/send sequence in the file /etc/uucp/Systems sets 8 bits/no parity when logging into the other system. The STTY=crtscts send sequence in the /etc/uucp/Dialers file sets up hardware flow control RTS/CTS for the outgoing modem line. Omitting these can cause difficult problems later.

3.3: How to Set Up an Advanced Dial-out PPP Client Machine

This set up gives more control over Connection Initiation. The previous setup will initiate a connection for any reason. It assumes it doesn't matter if the link goes up and down. If it DOES matter if the link goes up and down, you may want to make some changes: Do not create the file /etc/defaultrouter above in step 4, instead add the following line to /etc/asppp.cf: default_route To initiate the connection, you will have to explicitly send a packet to the other side of the ppp link (192.9.200.253 in the example above). When the link comes up, a default route is added through the far side of the PPP link. The link will function normally and remain up until the inactivity_timeout expires, and when it comes down, the default route will be removed. When the link is down, however, all DNS lookups will back off quickly since there is not a route to the dns server. This will prevent the link from coming up and down all the time. Note that this will run in.routed in quiet mode. It assumes that the file /etc/gateways does not exist, and that only the PPP interface exists (besides the loopback interface lo0 of course).

3.4: How to Set Up a PPP Server on a LAN, With Static IP Addresses

This example shows a server that has two dialin modems and three ppp accounts for people that could log in from home or remote sites. When a ppp user dials in and logs on, a free interface is configured up because this is a dynamic point-to-point configuration (indicated by ipdptp*). In this example, each PPP user has a statically assigned IP address. Examine your ifconfig, and note the ether address for the S99proxyarp script later: # /usr/sbin/ifconfig le0 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.9.200.1 netmask ffffff00 broadcast 192.9.200.255 ether 8:0:20:1:2:3 Modify your hosts and asppp.cf files: /etc/hosts: 127.0.0.1 localhost 192.9.200.1 myserver loghost 192.9.200.100 johnhome 192.9.200.101 paulhome 192.9.200.102 marypc /etc/asppp.cf: ifconfig ipdptp0 plumb myserver johnhome up ifconfig ipdptp1 plumb myserver paylhome up ifconfig ipdptp2 plumb myserver marypc up defaults inactivity_timeout 120 ipcp_async_map 0 # debug_level 9 # uncomment for debugging path peer_system_name johnppp # matches login name interface ipdptp0 In this example, each PPP user has a statically assigned IP address. Examine your ifconfig, and note the ether address for the S99proxyarp script later: # /usr/sbin/ifconfig le0 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.9.200.1 netmask ffffff00 broadcast 192.9.200.255 ether 8:0:20:1:2:3 Modify your hosts and asppp.cf files: /etc/hosts: 127.0.0.1 localhost 192.9.200.1 myserver loghost 192.9.200.100 johnhome 192.9.200.101 paulhome 192.9.200.102 marypc /etc/asppp.cf: ifconfig ipdptp0 plumb myserver johnhome up ifconfig ipdptp1 plumb myserver paylhome up ifconfig ipdptp2 plumb myserver marypc up defaults inactivity_timeout 120 ipcp_async_map 0 # debug_level 9 # uncomment for debugging path peer_system_name johnppp # matches login name interface ipdptp0 path peer_system_name paulppp interface ipdptp1 path peer_system_name maryppp interface ipdptp2 Create an executable file called /etc/rc2.d/S99proxyarp. This should have an arp entry for each of your PPP clients, listing your server's ethernet address: ndd -set /dev/ip ip_forwarding 1 arp -s johnhome 8:0:20:1:2:3 pub arp -s paulhome 8:0:20:1:2:3 pub arp -s maryhome 8:0:20:1:2:3 pub Make it executable: # chmod +x /etc/rc2.d/S99proxyarp Add the following entries to /etc/passwd: johnppp:x:1200:1045:john ppp login:/:/usr/sbin/aspppls paulppp:x:1201:1045:paul ppp login:/:/usr/sbin/aspppls maryppp:x:1203:1045:mary ppp login:/:/usr/sbin/aspppls And the following to /etc/shadow: johnppp:::::::: paulppp:::::::: maryppp:::::::: Use passwd to set the passwords for these users. Notes: This setup uses proxy arp to allow the use of addresses with the same network address as the le0 interface address. The system will run as a router sending RIP packets out all the interfaces unless it is configured to run the routing protocols in quiet mode. See the Q&A on routing below for more information. [[SEE SECTION]]

3.5: How to Set Up a Dial-In PPP Server, With Dynamic IP Addresses

NOTE: This example doesn't work (bugid 1217294, 1205460). It will work the first time, but after the line is dropped, the ip address of the remote end of the PPP link is reset to 255.255.255.255. A patch is forthcoming. [polo 10/4/95] --- The benefit of this system is that if you have only 2 modems, you only need to assign 2 ip addresses (since at most, 2 people can log in at one time). Many accounts are defined and each will get dynamically assigned ip address 192.9.200.100 or 192.9.200.101 depending on when they log in. Solaris clients generally need a static ip address, so this won't work for them. This will change in Solaris 2.5. Examine your ifconfig, and note the ether address for the S99proxyarp script later: # /usr/sbin/ifconfig le0 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.9.200.1 netmask ffffff00 broadcast 192.9.200.255 ether 8:0:20:1:2:3 Modify your hosts and asppp.cf files: /etc/hosts: 127.0.0.1 localhost 192.9.200.1 myserver loghost 192.9.200.100 pc1 192.9.200.101 pc2 /etc/asppp.cf: ifconfig ipdptp0 plumb myserver pc1 down ifconfig ipdptp1 plumb myserver pc2 down defaults interface ipdptp* inactivity_timeout 120 ipcp_async_map 0 # debug_level 9 # uncomment for debugging path peer_system_name pcppp1 path peer_system_name pcppp2 path peer_system_name pcppp3 path peer_system_name pcppp4 path peer_system_name pcppp5 path peer_system_name pcppp6 Create an executable file called /etc/rc2.d/S99proxyarp. This should have an arp entry for each of your PPP clients, listing your server's ethernet address: ndd -set /dev/ip ip_forwarding 1 arp -s pc1 8:0:20:1:2:3 pub arp -s pc2 8:0:20:1:2:3 pub make it executable: # chmod +x /etc/rc2.d/S99proxyarp Add the following entries to /etc/passwd: pcppp1:x:1200:1045:pc login:/:/usr/sbin/aspppls pcppp2:x:1201:1045:pc login:/:/usr/sbin/aspppls pcppp3:x:1202:1045:pc login:/:/usr/sbin/aspppls pcppp4:x:1203:1045:pc login:/:/usr/sbin/aspppls pcppp5:x:1204:1045:pc login:/:/usr/sbin/aspppls pcppp6:x:1205:1045:pc login:/:/usr/sbin/aspppls And also update /etc/shadow.

3.6: How to Set Up a Network-to-Network PPP Link

This example describes a network to network configuration where the systems each have their own network. The le0 ip address and the ipdptp0 ip address are identical in each case (which requires the latest kernel jumbo patch to work correctly in 2.3 and 2.4). With this example, the machines on each network should be able to reach the machines on the other network. Note that both machines must have ip addresses on separate networks. There is *NO WAY* to get this example to work if the machines share the same network portion of their ip address. IP addresses are used to clearly distinguish the network addresses in the /etc/gateways file. First, you must modify the DIAL-OUT MACHINE. Set Up your asppp.cf file: /etc/asppp.cf: ifconfig ipdptp0 plumb 192.9.200.1 200.100.99.25 up path interface ipdptp0 peer_system_name server inactivity_timeout 120 ipcp_async_map 0 # debug_level 9 # uncomment for debugging Modify your /etc/gateways file to: - Prevent routes from being sent as RIP packets over the PPP interface (which would keep it active past the inactivity timeout period). - Also, add a route to the other network so that clients on this network can get back. This machine will broadcast this route to the local network using in.routed. /etc/gateways: norip ipdptp0 net 200.100.99.0 gateway 200.100.99.25 metric 1 passive Disable router discovery (so the link isn't brought up when the system boots and the link doesn't stay up because of in.rdisc packets every 10 minutes): # cd /usr/sbin # mv in.rdisc in.rdisc.save Set up the modem port as a dial-out modem or a bidirectional modem using admintool's serial port manager Create an entry in /etc/uucp/Systems for 'server'. This name matches the peer_system_name line in the asppp.cf file. # cd /etc/uucp # grep myprovider Systems server Any ACUTEC 9600 9030874 "" P_ZERO "" login:-\r\n\c-login:-\r\n\c-login:-EOT-login: mylogin ssword: mypasswd # grep ACUTEC Devices ACUTEC cua/a - Any tb9600-ec # grep tb9600-ec Dialers tb9600-ec =W-, "" \dA\pA\pA\pT&D2E1V1X1Q0S2=255S12=255S50=6S58=2\r\c OK\r \EATDT\T\r\c CONNECT\s9600 STTY=crtscts (The 3 lines in the Systems file and the 2 lines in the Dialers file were wrapped for this document. They really are one line.) Next, modify the DIAL-IN MACHINE: You must set the machine up as a dialin machine, with the link up so that a route to the other network can be added to /etc/gateways. Note that this can sometimes lead to messages like 'Call Failed: SYSTEM NOT IN Systems FILE' in the /etc/log/asppp.log file, which should be ignored. You can also make this machine dial-in/dial-out by adding a 'mylogin' entry to the /etc/uucp/Systems file so dial-out can occur. The client machine should have a login for this machine that starts /usr/sbin/aspppls. Be aware that this may lead to a standoff if both systems try to dial each other at the same time. /etc/asppp.cf: ifconfig ipdptp0 plumb 200.100.99.25 192.9.200.1 up path interface ipdptp0 peer_system_name mylogin inactivity_timeout 120 ipcp_async_map 0 # debug_level 9 # uncomment for debugging Create a login user that runs the ppp login service by addin the following entry to /etc/passwd: mylogin:x:1200:1045:john ppp login:/:/usr/sbin/aspppls and the following to /etc/shadow: mylogin:::::::: Modify your gateways file to: - Prevent routes from being sent as RIP packets over the PPP interface (which would keep it active past the inactivity timeout period). - Also, add a route to the other network so that clients on this network can get back. This machine will broadcast this route to the local network using in.routed. /etc/gateways: norip ipdptp0 net 192.9.200.0 gateway 192.9.200.1 metric 1 passive Disable router discovery (so the link doesn't stay up with in.rdisc packets every 10 minutes): # cd /etc # mv in.rdisc in.rdisc.save

3.7: How to Set Up A Normal User to Start and Stop the PPP Daemon

To do this, compile the following two programs: pppstart.c: #include <stdlib.h> #include <sys/types.h> #include <unistd.h> main() { setuid(geteuid()) setgid(getegid()) system("/etc/init.d/asppp start") } pppstop.c: #include <stdlib.h> #include <sys/types.h> #include <unistd.h> main() { setuid(geteuid()) setgid(getegid()) system("/etc/init.d/asppp stop") } To compile them: # cc -o pppstart pppstart.c # cc -o pppstop pppstop.c # chown root pppstart pppstop # chmod 4755 pppstart pppstop Then a normal user can start and stop ppp manually. Note that this example isn't particularly secure a more secure example would set the environment to a default value before the system call.

3.8 How do I enable the Dynamic Address capability on Solaris 2.5 aspppd?

A: Edit the asppp.cf file, adding a line that reads: negotiate_address on It has been observed that the 2.5 aspppd man page alleges that negotiation is on by default. Apparently you still need to make this specification in the asppp.cf file.

4.0: Some Frequently Asked Questions

4.1: General PPP Questions

4.1.1: Supported Protocols -------------------------- Q: Is callback supported? A: No. Q: Are PAP or CHAP supported by PPP? A: PAP shands for Password Authentication Protocol, and CHAP stands for Challenge Handshake Authentication Protocol. They are methods of used for each PPP machine to authenticate the other machine while the PPP connection is established. PAP and CHAP not supported in Solaris 2.3/2.4 PPP. They are supported in Solaris 2.5, and are documented in the aspppd man page. 4.1.2: Informational Queries ---------------------------- Q: what do 'ipd' and 'ipdptp' stand for? A: IP/Dialup and IP/Dialup Point-to-Point. Q: What's the difference between a point-to-point interface (like ipdptp0) and a point-to-multipoint interface (like ipd0)? A: A point-to-point interface connects 2 points together, and both ip addresses are indicated in the ifconfig output: # ifconfig ipdptp0 ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 192.9.200.1 --> 128.1.1.1 netmask ffffff00 ether 0:0:0:0:0:0 and a point-to-point link shows up as a host route in the routing table: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 128.1.1.1 192.9.200.1 UH 3 35 ipdptp0 A point-to-multipoint interface usually takes a whole subnet, like an ethernet interface (without broadcast capability). It is expected that each host on the given subnet should be reachable through the given interface. It will show up in ifconfig output like this: # ifconfig ipd0 ipd0: flags=c1<UP,RUNNING,NOARP> mtu 8232 inet 192.9.200.1 netmask ffffff00 ether 0:0:0:0:0:0 but the routing information will show a network route to an entire network: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 192.9.200.0 192.9.200.1 U 2 0 ipd0 The system will expect to get to any ip address within the 192.9.200 network through the ipd0 interface. If some don't exist (there is no 'path' in /etc/asppp.cf with the given peer_ip_address), then a message will appear in /etc/log/asppp.log: 16:39:25 process_ipd_msg: ipd0 needs connection for address 192.9.200.3 16:39:26 place_call: can't find path for ipd0 In general, point-to-point interfaces are more flexible than point-to-multipoint interfaces because they can share the same ip address as another interface and do not require changes for routing and subnet allocation. Q: what are the differences between the different debug levels? A: levels between 1 and 7 primarily affect UUCP debug levels. They give progressively more information about the uucp file chat scripts. Debug levels 8 and 9 cause the the ppp_diag module to be invoked so that individual PPP packets appear in the log. This is useful to debug the PPP negotiation phase and possibly the ip packets. debug_level 8 does not print hex information about each packet. debug_level 9 prints out the start of the ip packets in hex, prints extended error information and reports header compression info. 4.1.3: Miscellanea ------------------ Q: I do an ifconfig -a and see ...,UNNUMBERED> what does it mean? A: This means that it's an interface with the same address as the local machine (it should not be set for the first interface, but subsequent interfaces with the flag set should have it set) This is usually the case when the PPP interface has the same ip address as le0.

4.2: Modems & Serial Ports

Q: How should I configure the serial port for PPP logins? A: simple answer: Use admintool's serial port manager. Select the port to configure, then choose (Use Template V) (Modem - Bidirectional) For most cases, this will work just fine. A2: more complicated: (add a modified /etc/ttydefs entry) The baud rate chosen by admintool's serial port manager actually corresponds to an /etc/ttydefs entry. If you choose 38400 for instance, it actually corresponds to the entry: 38400:38400 hupcl:38400 hupcl::19200 the 19200 at the end will attempt other baud rates if things don't work at 38400 on dial in. To lock the interface at 38400 and enable hardware flow control, put an entry like this in /etc/ttydefs: X38400:38400 hupcl crtscts:38400 hupcl crtscts::X38400 then invoke the serial port manager and choose [Other...] for baud rate and reference X38400 Q: What are some general tips for configuring my modem for PPP? A: Modem problems show up in many ways, some of them obscure, including the following: - inability of PPP to dial the phone - inability of PPP to hang up the modem - inability of PPP (or the login process) to detect a modem hangup - slow, missing or garbled login prompts - garbled PPP packets Modem problems may also generate the following messages: Call Failed: CALLER SCRIPT FAILED {BAD FCS} {Unrecognized protocol} {Unescaped characters} process_ppp_msg: PPP_ERROR_IND Loop back detected process_ppp_msg: PPP_ERROR_IND Maximum number of configure requests exceeded catch_sighup: HUP caught This isn't a complete list! Modems are different from manufacturer to manufacturer, but by looking in the manuals, there are a couple things to set: - use hardware (CTS/RTS) flow control - reset the modem on DTR drop - turn on error correction - compression is ok (lcp_compression and ipcp_compression used by ppp do not compress the data, only the headers) - try to lock the interface speed to the highest speed supported, usually this is 38400. (this is the speed between the modem and the sun system, which is different than the connect speed) - on server systems, set the modem to auto answer (usually ATS0=1) - save these settings if possible (usually AT&W) Also, make sure all the wires are connected. Use a sun serial port adapter cable for systems with a din plug and connect to the modem with 25-wire RS232 cables. Here are some initialization strings to configure some common modems for dial-in/dial-out: (Thanks to the Chris Kovacs Solaris 2.x modem faq) --------------------------------------------------------------- Hayes Optima/Acura Modems: AT&F1N0Q2X0&C1&D2S=1&W --------------------------------------------------------------- US Courier Modems: AT&F1&B1&C1&D2X0S0=1&W dip switch settings: Switch Setting 1 OFF 2 OFF 3 ON 4 OFF 5 OFF* 6 OFF 7 ON* 8 ON 9 OFF 10 OFF --------------------------------------------------------------- US Robotic Modems: AT&F1&B1&C1&D2X0S0=1&W --------------------------------------------------------------- Telebit T2500 modems in Conventional mode: AT&FQ2X0N0S0=1S37=0&C1&D2&K3&W1&W2 --------------------------------------------------------------- Telebit T2500 modems in Enhanced mode: AT&FS52=4Q9S131=1S58=2S68=255S95=0S150=2S50=0S51=5 S51=5 (19200 bps) S51=4 (9600 bps) --------------------------------------------------------------- GVC 288 V.34 Modem: AT&F2E0Q1S0=1&C1&D2&W&W1 ---------------------------------------------------------------

4.3: PPP Dial-In Questions & Problems

Q: How can I get PPP client to dial multiple phone numbers, trying a second phone number if the first one is busy?? A: Have multiple entries in the /etc/uucp/Systems file, identical to one another *except* for the phone number. If the first one fails, it will try the second one (or the third, etc...) Q: Why does 'ping machinename' quit before my modem even finishes connecting to the other system with PPP? A: By default, ping will send ICMP ECHO packets to the remote machine for 15 seconds only. When the first packet queues up for the PPP interface, the ppp daemon aspppd will attempt to bring up the PPP connection. It will dial the other site using the /etc/uucp configuration files, negotiate the link and bring the interface up. However, by the time all this takes place, ping has sent packets for 15 seconds with no response and has given up. To see that this is not exclusive to PPP, try 'ping localhost 0'. To see that the ping can work with PPP, try extending the timeout period to 5 minutes: ping ppp-farside 300. Q: The other side disconnects after 50 seconds, even though things seemed to be going ok. Any idea why? A: This MAY be because of a common problem with line quality reporting. (There are many other reasons why the other end may disconnect!) Some other PPP implementations require line quality reports from Sun's PPP, without negotiating the correct timeout value. To check to see if this is the problem, enable debug_level 9, and look for packets marked LQM_REPORT every 10 seconds: 15:39:44 start_ip: IP up on interface ipdptp0, timeout set for 1200 seconds 15:39:54 000350 ipdptp0 RECEIVE PPP ASYNC 53 Octets LQM_REPORT Magic-number= 7a945fba LastOutLQRs= 0 LastOutPackets= 0 LastOutOctets 0 PeerInLQRs= 0 PeerInPackets= 2 PeerInDiscards= 0 PeerInErrors= 0 PeerInOctets= 56 PeerOutLQRs= 2 PeerOutPackets= 6 PeerOutOctets= 206 15:40:02 000351 ipdptp0 SEND PPP ASYNC 57 Octets IP_PROTO 15:40:04 000352 ipdptp0 RECEIVE PPP ASYNC 53 Octets LQM_REPORT Magic-number= 7a945fba LastOutLQRs= 0 LastOutPackets= 0 LastOutOctets 0 PeerInLQRs= 0 PeerInPackets= 2 PeerInDiscards= 0 PeerInErrors= 0 PeerInOctets= 56 PeerOutLQRs= 3 PeerOutPackets= 7 PeerOutOctets= 259 15:40:14 000353 ipdptp0 RECEIVE PPP ASYNC 53 Octets LQM_REPORT Magic-number= 7a945fba LastOutLQRs= 0 LastOutPackets= 0 LastOutOctets 0 PeerInLQRs= 0 PeerInPackets= 2 PeerInDiscards= 0 PeerInErrors= 0 PeerInOctets= 56 PeerOutLQRs= 4 PeerOutPackets= 8 PeerOutOctets= 312 15:40:24 000354 ipdptp0 RECEIVE PPP ASYNC 53 Octets LQM_REPORT Magic-number= 7a945fba LastOutLQRs= 0 LastOutPackets= 0 LastOutOctets 0 PeerInLQRs= 0 PeerInPackets= 2 PeerInDiscards= 0 PeerInErrors= 0 PeerInOctets= 56 PeerOutLQRs= 5 PeerOutPackets= 9 PeerOutOctets= 365 15:40:32 000355 ipdptp0 SEND PPP ASYNC 57 Octets IP_PROTO 15:40:34 process_ipd_msg: interface ipdptp0 has disconnected 15:40:34 disconnect: disconnected connection from ipdptp0 15:40:34 000356 ipdptp0 RECEIVE PPP ASYNC 9 Octets LCP Term-REQ ID=02 LEN=4 15:40:34 000357 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-ACK ID=02 LEN=4 15:40:38 000358 ipdptp0 PPP DIAG CLOSE If you can disable line quality monitoring or line quality reports on the other side, it may work fine. Q: my PPP chat script quits with "enough already", what do I do? A: There is a hard limit of 1000 characters in uucp/cu/ppp chat scripts when looking for an expect sequence. Some systems that are very verbose on login might exceed this limit on login. If the system being logged into is a solaris system, you may want to create a .hushlogin file for the ppp login user. You may also be able to include part of the login message as part of the chat script. A smaller /etc/issue file may also help. Q: Connecting to a solaris ppp server doesn't work. When debugging the connection, the log shows something like: I_SENDFD failed error 6 A: This message is usually accompanied by the /etc/log/asppp.log message: cannot find path for peer_system_name <loginname> Make sure the login name matches a peer_system_name in one of the path statements of the ppp server machine. A2: If the serial port is not set up correctly, you can get the message: cannot find path for peer_system_name .zsmon You might want to use admintool's serial port manager to delete the service on the serial port and re-add the service to correct it. Q: Why does PPP fail with the message: process_ppp_msg: PPP_ERROR_IND Loop back detected A: This happens when the calling PPP process is not communicating with the remote PPP process. What is happening is that that every character sent by the calling process is being echoed verbatim by the remote system. Even though PPP packets appear in the log file, this is NOT a negotiation problem, it is a communications problem. Usually, this indicates that the "" P_ZERO expect/sent sequence has been left out of the /etc/uucp/Systems file chat script, and the PPP process is talking to the login process which is happily echoing every character back (just like it echoes each character you type in your login name) Note: sometimes, changing the STTY=crtscts to STTY=crtscts,cs8,-parenb will work where the P_ZERO entry doesn't. Another reason this might fail is an invalid password on the remote system. The calling PPP will get 'login incorrect', then talk to the 'login:' prompt instead of the remote PPP process. One more reason this might fail is that /usr/sbin/aspppls is not the login shell on the remote system. The calling PPP process logs in correctly, but talks to an interactive shell, which echoes all the characters of a PPP packet (just as if a user was typing a command) In every case, the calling PPP process is never communicating with the remote PPP process. You may be able to debug this problem by using cu in solaris 2.4: % cu -d -L systemname where 'systemname' is the peer_system_name entry (the /etc/uucp/Systems file entry for the remote PPP system). When correctly logged into the remote system, PPP packets will appear after the 'transmit started' and 'receive started' messages. Their appearance in ascii will look like 25 or so random characters starting and ending with ~. If you get a login prompt, a "login incorrect" message or a shell prompt, you have found the problem. Q: Why does PPP fail with the message: process_ppp_msg: PPP_ERROR_IND Maximum number of configure requests exceeded A: the PPP process has sent 10 configuration requests without any configuration acknowledgements and has given up. This means that the other side isn't responding at all, or has stopped responding after option negotiation has failed. To determine the cause of this problem, change the debug_level to 9 and check the /etc/log/asppp.log files on both sides. If the log file just shows 10 configuration requests, for instance: 19:09:49 000194 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=59 LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:09:52 000195 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=5a LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:09:55 000196 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=5b LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:09:58 000197 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=5c LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:10:01 000198 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=5d LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:10:04 000199 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=5e LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:10:07 000200 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=5f LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:10:10 000201 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=60 LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:10:13 000202 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=61 LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:10:16 000203 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=62 LEN=24 MR U=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP 19:10:19 process_ppp_msg: PPP_ERROR_IND Maximum number of configure requests exc eeded Then the remote PPP daemon is not responding to the local PPP daemon at all. This could indicate a communications problem or a problem starting the remote PPP daemon. Check the other side of the link to see if there is any record of the communications. If this log is from a client system, use the 'last' command on the server system to see if a login of the PPP user occurred. The troubleshooting advice from the last question, 'cu -d -L systemname' may also help diagnose this. If the log file does show configuration requests and some responses, it may be an option negotation problem: 14:26:57 000219 ipdptp0 SEND PPP ASYNC 19 Octets LCP Config-Req ID=ab LEN=14 MR U=1500 MAG#=da308f5d 14:26:57 000222 ipdptp0 RECEIVE PPP ASYNC 29 Octets NB LCP Config-Req ID=01 LEN =24 ACCM=00000000 MAG#=6f7d2cf3 ProtFCOMP AddrCCOMP Auth=PAP 14:26:57 000223 ipdptp0 SEND PPP ASYNC 17 Octets NB LCP Config-REJ ID=01 LEN=12 ProtFCOMP AddrCCOMP Auth=PAP 14:26:58 000224 ipdptp0 RECEIVE PPP ASYNC 26 Octets NB LCP Config-Req ID=02 LEN =21 ACCM=00000000 Auth=CHAP Alg=MD5 MAG#=6f7d2cf3 14:26:58 000225 ipdptp0 SEND PPP ASYNC 14 Octets NB LCP Config-REJ ID=02 LEN=9 Auth=CHAP Alg=MD5 14:26:58 000226 ipdptp0 RECEIVE PPP ASYNC 21 Octets NB LCP Config-Req ID=03 LEN =16 ACCM=00000000 MAG#=6f7d2cf3 14:26:58 000227 ipdptp0 SEND PPP ASYNC 19 Octets NB LCP Config-Req ID=ac LEN=14 MRU=1500 MAG#=da308f5d 14:26:58 000228 ipdptp0 SEND PPP ASYNC 21 Octets NB LCP Config-ACK ID=03 LEN=16 ACCM=00000000 MAG#=6f7d2cf3 14:26:58 000229 ipdptp0 RECEIVE PPP ASYNC 19 Octets NB LCP Config-ACK ID=ac LEN =14 MRU=1500 MAG#=da308f5d 14:26:58 000230 ipdptp0 SEND PPP ASYNC 15 Octets NB IP_NCP Config-Req ID=ad LEN =10 IPADDR=192.9.200.1 14:27:01 000231 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=ae LEN=10 IPADDR=192.9.200.1 14:27:04 000232 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=af LEN=10 IPADDR=192.9.200.1 14:27:07 000233 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=b0 LEN=10 IPADDR=192.9.200.1 14:27:10 000234 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=b1 LEN=10 IPADDR=192.9.200.1 14:27:13 000235 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=b2 LEN=10 IPADDR=192.9.200.1 14:27:16 000236 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=b3 LEN=10 IPADDR=192.9.200.1 14:27:19 000237 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=b4 LEN=10 IPADDR=192.9.200.1 14:27:22 000238 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=b5 LEN=10 IPADDR=192.9.200.1 14:27:25 000239 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=b6 LEN=10 IPADDR=192.9.200.1 14:27:28 process_ppp_msg: PPP_ERROR_IND Maximum number of configure requests exceeded 14:27:29 000240 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-REQ ID=b7 LEN=4 14:27:29 000241 ipdptp0 PPP DIAG CLOSE This example shows the remote side asking for PAP authentication, which is rejected. Next it asks for CHAP authentication, which is also rejected. After that, the remote end stops negotiating while the local side sends 10 configuration requests and finally gives up. One other way of getting this is to have the line: ipcp_async_map 0 in the path section of the asppp.cf file on one PPP system, but not in the other. Make sure the systems either both omit this parameter or both have this parameter. Basically, one system sends packets with control characters unescaped, and the other system expects control characters to be escaped and rejects all packets with these errors. This case may show '{Unescaped characters}' messages on one side while the other end continually sends configuration requests which are ignored.

4.4: PPP Link Activity

Q: I want COMPLETE control over when the link is active or not, how can I do this? A: To make sure that PPP is not enabled when the system boots, first make the following changes: # cd /etc # mv rc0.d/K47asppp rc0.d/disable.K47asppp # mv rc1.d/K47asppp rc1.d/disable.K47asppp # mv rc2.d/S47asppp rc2.d/disable.S47asppp Then you can manually bring the link up and down with: # /etc/init.d/asppp start # /etc/init.d/asppp stop Note that this may cause the system to have strange delays if PPP is the primary interface on the machine. Q: How can I get PPP to always keep the line active? A: add this line to /etc/asppp.cf: inactivity_timeout 0 Q: Why does the system dial on bootup? Why does my connection come up by itself? Why does the connection stay active past the inactivity_timeout value? A: An outgoing PPP connection is brought up by aspppd when a packet is sent out the interface. The most common reason the system dials on bootup is in.rdisc. Whether the system is configured as a router or as host, in.rdisc will send out three quick multicast packets when it starts up to discover other routers on connected networks. See Section 4.5 for a better explanation. Also, if the system has more than one interface, it is configured as a router. This means that it will run in.rdisc and in.routed so that they will actively share the system routing tables. They do this by sending packets out all the interfaces with the routing tables. in.routed will broadcast RIP packets out all the interfaces every 30 seconds. in.rdisc will send multicast packets out all the interfaces every 10 minutes. PPP may remain connected because of in.routed's RIP packets, or be brought up every 10 minutes by in.rdisc's multicast packets. See Section 4.5 for a better explanation of in.rdisc and in.routed. If modifying /etc/rc2.d/S69inet (also known as /etc/init.d/inetinit), pay attention to ip_forwarding, which takes on these values for solaris 2.x: 0 - never forward a packet from one interface to another. 1 - always allow packets to enter one interface and be forwarded to a destination through another interface. 2 - allow forwarding if the system has 2 or more interfaces. DNS is also a common culprit if there is a default route pointing to the PPP interface. If the /etc/nsswitch.conf file says: hosts: files dns then moving any commonly used system names and ip addresses into the hosts file may prevent dns lookups for something that should could be found in the /etc/hosts file. You can turn on dns debugging with the command: # kill -USR1 <process-id-of-in.named> to catch some of these. The information will be logged in /var/tmp/named.run. Another way to get around this might be to not have a default route pointing out the PPP interface, but to add the 'default_route' keyword to the asppp.cf file. This will cause dns to work normally when the PPP link is up, but when PPP is down, there is no route for dns to follow and it will just fail looking up names (and since there is no route to the host, it will back off of name lookup very quickly instead of a slow timeout). See the man page for in.named(1M) for more information on DNS. Note: for solaris 2.5, a new daemon called nscd caches nameserver requests and may also be a factor. See the man page for nscd(1M) The best way to check for packets that keep an interface alive is to run snoop as root. # snoop -t a -d ipdptp0 will snoop all packets on the ppp interface with timestamps. Unfortunately, this won't trace the packets that actually brought up the interface, but it will track packets that keep an interface up. See the man page for snoop(1M). Q: I have a dial-in system set up with a ipdptp ppp link, but sometimes it tries to dial out and gets 'system not in systems file'. How do I make sure it doesn't dial out? A: change the ifconfig line in /etc/asppp.cf so that the link is configured down instead of up to start: ifconfig ipdptp0 plumb me you down and change the 'interface' line for it's path to: interface ipdptp* The system will configure the link up when the remote system dials in, and back down when the ppp connection terminates. note that this may have an effect on routing (the system might only recognize the le0 link and not set itself up as a router, if that's what you expected)

4.5: Routing Questions

Q: I can ping or telnet to my server system, but not beyond, why??? A: your routing/network design is probably wrong. See below. Q: Here's my routing table, what does it mean? % netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 127.0.0.1 127.0.0.1 UH 01251638 lo0 192.9.201.253 192.9.200.1 UH 5 19 ipdptp0 192.9.200.0 192.9.200.2 U 3 76 le0 224.0.0.0 192.9.200.2 U 3 0 le0 default 192.9.201.253 UG 0 284 % A: Well, your system looks like this: [server] 192.9.201.253 <---> 192.9.200.1 [you] 192.9.200.2 <-- other hosts --> ipdptp0 ^ le0 (ethernet segment) +-+ lo0 (loopback) The first entry is the loopback entry. ping localhost will use this to get to yourself. The second entry is a route to a specific host using a PPP point-to-point link. ipdptp interfaces define links with 2 endpoints. This is what you would get if you check the interface status with ifconfig: # ifconfig ipdptp0 ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 192.9.200.1 --> 192.9.201.253 netmask ffffff00 ether 0:0:0:0:0:0 This shows a point-to-point link with 2 endpoints. The ip address of our side is 192.9.200.1 and the ip address of the far side is 192.9.201.253. In this example, they are on different networks. When ifconfig is used to configure this interface (in /etc/rc2.d/S47asppp), this routing table entry is created. The third entry is for the network 192.9.200.0 through the ethernet interface. Note that the ethernet interface is a multipoint interface. This means you can talk to any host on the network of that interface directly. If you checked the interface status using ifconfig, you would see: # ifconfig le0 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.9.200.2 netmask ffffff00 broadcast 192.9.200.255 ether 8:0:20:1:2:3 When ifconfig is used to configure this interface (in /etc/rcS.d/S30rootusr.sh), which reads hostname.le0, this routing table entry is created. The 224.0.0.0 entry is for multicast. You can ignore this for now. The last entry is for everything else, the default route. All packets that can't be resolved go to 192.9.201.253. Packets are routed this way: 1) if the destination ip address of the packet has a host route in the routing table, then send it through that gateway. 2) if the destination ip address has a network route in the routing table, send it through that gateway 3) if there is a default route, send it through that gateway 4) if none of these steps work, you get an "ICMP host unreachable from gateway <yourhost>" message. for example: - packets to 127.0.0.1 go through the loopback interface lo0 (there's a host route available) - packets to 192.9.201.253 go through the PPP interface ipdptp0 (there's a host route available) - packets to 192.9.200.5 go through the ethernet interface le0 (there's a network route available to net 192.9.200.0, but no host route) - packets to 192.9.9.1 go through the ppp interface (there's a default route that points to the far side of the PPP interface, but no host route and no network route) Q: what does in.routed do? A: in.routed manages routes to specific networks and hosts in the routing table. It can be configured to supply routing information to other routers or just accept information, but not broadcast it. in.routed will: - listen on all interfaces for for RIP (Routing Information Protocol) packets and add routes to the routing table - periodically expire routes that have not been updated recently. - when not in quiet mode (-q), it will broadcast the routes it knows on all the system's interfaces. in.routed does not "look" for routes, it just listens to other routers that pass on their routing table. Whether in.routed is started (and how) is decided in /etc/rc2.d/S69inet. If the file /etc/defaultrouter exists, then in.routed is not started and the routing table will have a default route pointing to the ip address (or addresses) in this file. (This is static routing.) If the system has only one interface on bootup, in.routed is started in quiet mode - it will listen for RIP packets and update the routing tables, but it will not advertise any of the system's routes. If the system has two or more interfaces, or the file /etc/gateways exists, in.routed will run and send the system routing table out all system's interfaces every 30 seconds. To prevent in.routed from broadcasting the system routes on an interface, you can add "norip <interface>" to /etc/gateways. For example: norip ipdptp0 will prevent in.routed from sending RIP packets out the first ppp interface. This is useful when you have to run in.routed and you want to prevent RIP packets from being sent every 30 seconds across a PPP link and keeping it active. in.routed will also allow the syntax "noripin <interface>" and "noripout <interface>". For more information, look at the system startup file /etc/rc2.d/S69inet, and the man pages for in.routed(1M), in.rdisc(1M) and routing(4). Note that in solaris 2.5 a system can be configured as a host (as opposed to a router) by creating the file /etc/notrouter Q: What does in.rdisc do? A: in.rdisc (router discovery) helps manages default routes in the routing table. If the file /etc/defaultrouter exists, then in.rdisc is not started and the routing table will have a default route pointing to the ip address (or addresses) in this file. (This is static routing.) If the system has only one interface (configured as a "host"), then in.rdisc will send three quick multicast messages out all interfaces to try and find other routers nearby. If it doesn't find any, then it will exit and in.routed will be started in quiet mode (-q). If one of the interfaces is a PPP interface capable of dialing out, the first packet will cause aspppd to try to dial out on this interface. If the system has two or more interfaces (configured as a "router"), then in.rdisc will send out multicast messages advertising itself as a router. Then, it will send out multicast advertisement packets every 10 minutes. in.router will run as well. You can disable in.rdisc from running by setting up static routing with an /etc/defaultrouter file, or by doing: # mv /usr/sbin/in.rdisc /usr/sbin/in.rdisc.save For more information, look at the system startup file /etc/rc2.d/S69inet, and the man pages for in.routed(1M), in.rdisc(1M) and routing(4). Note that in solaris 2.5 a system can be configured as a host (as opposed to a router) by creating the file /etc/notrouter Q: What is proxy ARP and how does it apply to PPP? A: In general, when a system does proxy ARP it responds to ARP requests on behalf of another system. For PPP links, it is a fairly easy way to allow remote hosts to appear to be on the local LAN without having to allocate a different network or subnet. Also, there are no added problems with routing. The ppp server will respond to arp requests on the local LAN on behalf of the ppp clients. When the packets are forwarded to the server, it resends them to the client using the route in the routing table. To configure your PPP server system to use proxy arp, you first check the ethernet address of your sun system: # ifconfig le0 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.139.25.202 netmask ffffff00 broadcast 192.139.25.255 ether 8:0:20:1:2:3 (the ether address will show up only if you invoke ifconfig as root) Create a file called /etc/rc2.d/S99proxyarp with this line in it: arp -s 192.139.25.190 8:0:20:1:2:3 pub and make it executable with: # chmod +x /etc/rc2.d/S99proxyarp The ip address here is the PPP client address, and must be on the same LAN as as the PPP server (that is, the network address of the PPP server must be the same network address as that of the PPP client, in this case, 192.139.25.0). Now it will appear as if the ppp system with ip address 192.139.25.190 will be located on the local LAN. Another example of proxy arp is shown above in the PPP server setup (See Sections 3.4 and 3.5). See also the man pages for arp(1M) and arp(4).

4.6: Other PPP Error Messages

Q: When I turn on debug_level 9, I get a lot of messages like 'BAD FCS', 'Invalid ppp packet' and 'Unrecognized protocol'. Is this bad? A: Not always. Here's an example of PPP trying to deal with the "Last login: Mon Nov..." message when logging on as a PPP user: First, the /etc/uucp/Systems chat script finishes... call cleanup(0) 14:52:29 000004 ipdptp0 SEND PPP ASYNC 23 Octets LCP Config-Req ID=01 LEN=18 MRU=1500 MAG#=e2ee748a ProtFCOMP AddrCCOMP 14:52:29 000005 ipdptp0 RECEIVE {Unescaped characters: 0a } {Invalid ppp packet} PPP ASYNC 7 Octets {BAD FCS} NB (AP) {Unrecogniz ed protocol: f0b8 8d 0a } f0 b8 8d 0a - left over characters with CR, LF characters 14:52:29 000006 ipdptp0 RECEIVE {Unescaped characters: 0a } PPP ASYNC 28 Octets {BAD FCS} NB (A) {Unrecognized protocol: 88a0 88 83 c0 21 01 01 80 92 01 04 85 5c 85 86 e2 ee 74 8d 0a 07 ..... } 0a 88 a0 88 83 c0 21 01 01 80 92 01 04 85 5c 85 86 e2 ee 74 8d 0a Explanation: This is an echo of packet 00004 sent by the PPP on our side 14:52:29 000007 ipdptp0 RECEIVE {Unescaped characters: 0a } PPP ASYNC 44 Octets {BAD FCS} NB (A) {Unrecognized protocol: cce1 f3 74 a0 6c 6f e7 69 ee 3a a0 4d 6f ee a0 4e 6f f6 a0 b1 b4 ..... } cc e1 f3 74 a0 6c 6f e7 69 ee 3a a0 4d 6f ee a0 4e 6f f6 a0 b1 b4 ..... L a s t l o g i n : M o n N o v 1 4 ..... 14:52:29 000008 ipdptp0 RECEIVE PPP ASYNC 23 Octets NB LCP Config-Req ID=00 LEN=18 MRU=1500 MAG#=fe47ea2b ProtFCOMP AddrCC OMP ...finally syncs up. In this case (at the BEGINNING) and only the beginning, it happens before any PPP packets are recognized. If this happens AFTER PPP comes up, it's probably a problem. Q: what does the message {BAD FCS} mean? A: This means that the FCS (Frame Check Sequence) didn't match the value calculated. This is a basically a Cyclic Redundancy Check (CRC) of the PPP packet to verify data integrity. Q: Is the 'call cleanup(0)' message an error? A: No, this is normal after the connection has been established with the remote end and before the PPP protocol is exchanged between the two systems. Q: Why does /etc/log/asppp.log repeatedly show the message: Call Failed: SYSTEM NOT IN Systems FILE 12:13:59 process_ipd_msg: ipdptp0 needs connection Call Failed: SYSTEM NOT IN Systems FILE 12:14:29 process_ipd_msg: ipdptp0 needs connection A: This message indicates that the system wanted to initiate a call to a system mentioned in /etc/asppp.cf, however the peer_system_name value doesn't match an entry in /etc/uucp/Systems. If dialout is intended to work for the system, make sure that peer_system_name correctly matches a name in /etc/uucp/Systems. If this appears in the log file for a ppp server that should never dial out to the indicated system, then you should try and find out what is causing the dialout. The most common cause is routing daemons trying to broadcast routing information over the PPP link. in.routed typically broadcasts information every 30 seconds, and in.routed broadcasts information every 10 minutes. See the questions about routing above for more detailed information. Q: Why do I get this message on my ppp dialin server? 10:59:30 catch_sighup: HUP caught 10:59:31 parse_config_file: Successful configuration A: This message may be the result of a misconfigured modem on the dial-in side. See the last question. Note that when aspppd is sent a SIGHUP signal, it drops all the lines and re-reads the configuration file. Q: What does the message {Unescaped characters} in the log file mean? A: By default, a PPP link should assume that all control characters between ascii 0 and 31 (hex 20) should be escaped. This means that each character between 0 and 31 should have 32 added to it's value and be preceeded by the escape character (which is 125 ascii or {). These messages may be normal when a link is first starting up (see above), but indicate a problem later (see below) Q: I'm getting these '{Unescaped characters}' messages in my /etc/log/asppp.log, *AFTER* it says that the link is up. Some things don't work correctly. 13:10:29 000421 ipdptp0 SEND PPP ASYNC 19 Octets IP_NCP Config-Req ID=1c LEN=14 OLD_VJCOMP IPADDR=3.54.20.1 13:10:29 000422 ipdptp0 RECEIVE PPP ASYNC 13 Octets IP_NCP Config-REJ ID=1c LEN=8 OLD_VJCOMP 13:10:29 000423 ipdptp0 SEND PPP ASYNC 15 Octets IP_NCP Config-Req ID=1d LEN=10 IPADDR=3.54.20.1 13:10:29 000424 ipdptp0 RECEIVE PPP ASYNC 15 Octets IP_NCP Config-ACK ID=1d LEN=10 IPADDR=3.54.20.1 13:10:29 start_ip: IP up on interface ipdptp0, timeout set for 300 seconds 13:10:42 000425 ipdptp0 RECEIVE {Unescaped characters} PPP ASYNC 53 Octets IP_PROTO 13:10:43 000426 ipdptp0 RECEIVE {Unescaped characters} PPP ASYNC 53 Octets IP_PROTO 13:10:44 000427 ipdptp0 RECEIVE {Unescaped characters} PPP ASYNC 53 Octets IP_PROTO 13:10:45 000428 ipdptp0 RECEIVE {Unescaped characters} PPP ASYNC 53 Octets IP_PROTO A: This *MAY* be a problem with escaping special characters. Some PC systems assume that all or some control characters are not escaped without explicitly saying so (this goes against the standard). By default, a PPP link should assume that all control characters between ascii 0 and 31 should be escaped. This log shows that after the link comes up, some packets have unescaped characters. By adding this line to the path in your /etc/asppp.cf file: ipcp_async_map 0 you may be able to get around the problem. It could also be a problem with the physical connection (like flow control or error checking) with either the serial lines or the modems. Note that this is one case where the log file will show packets, but they may not be received. Running 'snoop -d ipdptp0' will probably show NO packets received.

4.7: PPP Performance Tuning

Q: how can I make my link more efficient? A: several things: 1) use a faster sun to modem baud rate. The baud rate can be set to 38400 in the /etc/uucp/Systems file. This will keep the modem buffers full which can result in better modem to modem compression. 2) add this line to /etc/asppp.cf: ipcp_async_map 0 and enable hardware flow control on the modems. This is also known as the Async Character Control Map or ACCM. Characters between 0 and 31 are by default 'quoted' by PPP to eliminate problems where packet data could be interpreted by the physical link as control characters (like ^S/^Q characters used for flow control). If the physical connection CAN PASS all control characters without problem, then this will speed up the link because 1 character will be sent instead of 2 when quoting occurs. Note that this option will have to be configured on both sides of the link for client and server systems. A mismatch could cause "Unescaped Characters" messages during option negotiation, wich could fail with the message: process_ppp_msg: PPP_ERROR_IND Maximum number of configure requests exceeded Q: Do lcp_compression and ipcp_compression actually compress my data? A: Not really. They don't compress the data *IN* the packets, but they can compress the repetitive header information for each packet. Setting ipcp_compression to vj allows the IP packet header to be very small if it is similar to preceeding packets. Typically the 20 byte IP header and a 20 byte TCP header can be compressed to 3 to 5 bytes using Van Jacobson compression. lcp_compression is a way of doing the same thing with the PPP header information.

5.0: Patches

The following is the list of all of the PP patches for 5.3 and 5.4. They must be installed if you expect your PPP system to be stable. In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com. Note that six-digit patch numbers are followed by revision numbers, so make sure that your revision numbers are greater than or equal to the numbers shown. To find the patches already on your system, type: # showrev -p The listing will show the patches in the order they were applied, so patches later in the list override patches earlier in the list.

5.1: Solaris 2.3 PPP Patches

101425-05 SunOS 5.3: fixes to ppp This is basically an upgrade to 2.4 PPP. It fixes many problems in 2.3 PPP and provides the ppp_diag module to decode individual packets, including the configuration packets It also fixes problem with Windows 95 PPP causes Solaris to crash every time. 101318-75 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd) This patch fixes routing problems and duplicate routes that may enter the routing table with point-to-point routes.

5.2: Solaris 2.4 PPP Patches

101945-34 SunOS 5.4: jumbo patch for kernel This patch fixes routing problems and duplicate routes that may enter the routing table with point-to-point routes. 102854-01 Fixes problem with Windows 95 PPP causes Solaris to crash every time.

5.3: Solaris 2.4 x86 PPP Patches

101946-29 SunOS 5.4_x86: jumbo patch for kernel 101970-04 SunOS 5.4_x86: ip driver fixes 102854-01 Fixes problem with Windows 95 PPP causes Solaris to crash every time. Also implements Dynamic IP addressing similar to the 2.5 version of PPP.

5.4: Solaris 2.5 PPP Patches

None

5.5: Solaris 2.5x86 PPP Patches

None

6.0: Known Bugs & RFEs

This section formerly contained information from various T-patches. That information has been moved to Section 5.0, patches. When new T-patches are available, we will update this section.

7.0: References

7.1: Important Man Pages

arp(1M) arp(4) aspppd(1M) aspppls(1M) in.routed(1M) in.rdisc(1M) routing(4) ppp(7) snoop(1M)

7.2 Sunsolve Documents

There are no Sunsolve documents of note related to PPP.

7.3 Sun Educational Services

[pending]

7.4: Solaris Documentation

From the Solaris 2.3 System Administration Answerbook and document set: SunOS 5.3 Administering TCP/IP and PPP From the Solaris 2.4 System Administration Answerbook and document set: TCP/IP Network Administration Guide (Solaris 2.4 sys admin document set)

7.5: Third Party Documentation

_TCP/IP Illustrated Volume 1, The Protocols_ by W. Richard Stevens, ISBN 0-201-63346-9

7.6: RFCs

The Internet Request For Comments (RFC's) that define the internet protocols (including PPP) can be found using www at: http://www.cis.ohio-state.edu:80/hypertext/information/rfc.html or by mail to mailserv@ds.internic.net with "document-by-name rfcnnnn" in the message body ('nnnn' is the RFC number to retrieve). These documents are stored many places on the internet. To find the best way to retrieve the rfc's, send an email message to mailserv@ds.internic.net with the message 'file /ftp/rfc/rfc-retrieval.txt' in the message body. A list of methods to retrieve the rfc's will be mailed to you.

7.7: Other Internet Resources

PPP information available through www: http://cs.uni-bonn.de/ppp/faq.html The PPP protocol supported by Sun's Asynchronous PPP: http://www.cis.ohio-state.edu/htbin/rfc/rfc1331.html Usenet Newsgroups: comp.protocols.ppp

8.0: Supportability

SunService is not responsible for the initial configuration of your PPP, nor for answering basic questions about how to put such a PPP configuration together. This document is supplied with the hope that it will enable you to configure your own PPP setup. We can help resolve problems where PPP is not behaving correctly, but in such cases the contact must be a system administrator who has a good understanding of PPP.

9.0: Additional Support

For initial configuration, or PPP setup, please contact your local SunService office for possible consulting offerings. Sun's Customer Relations organization can put you in touch with your local SunIntegration or Sales office. You can reach Customer Relations at 800-821-4643.

INFODOC ID: 11976 SYNOPSIS: PPP PSD/FAQ DETAIL DESCRIPTION: SunService Tip Sheet for Sun PPP Revision: 1.8 Date: December 21, 1995

TABLE OF CONTENTS:

SOLUTION SUMMARY: PATCH ID: n/a PRODUCT AREA: Gen. Network PRODUCT: PPP SUNOS RELEASE: Solaris 2.x UNBUNDLED RELEASE: n/a HARDWARE: any ~ ~ ~ ~

INFODOC ID: 11976
SYNOPSIS: PPP PSD/FAQ
DETAIL DESCRIPTION:

SunService Tip Sheet for Sun PPP

Revision: 1.8
Date: December 21, 1995

SOLUTION SUMMARY:

PATCH ID: n/a
PRODUCT AREA: Gen. Network
PRODUCT: PPP
SUNOS RELEASE: Solaris 2.x
UNBUNDLED RELEASE: n/a
HARDWARE: any
~
~
~
~