Make your own free website on Tripod.com

Info Docs document 11976


[ Notify of patch changes ] [ Mark Document ] [ Fax Document ]

INFODOC ID: 11976

SYNOPSIS: PPP PSD/FAQ
DETAIL DESCRIPTION:

SunService Tip Sheet for Sun PPP

Revision: 2.0
Date: July 16, 1996

This document and all contents are Copyright (C)1995, Sun Microsystems, Inc.

TABLE OF CONTENTS:

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 to Set Up a Dial-Out PPP client, With Dynamic IP Addressing
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

 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

        For Solaris 2.5: the System Administrator's Answerbook and
        hardcopy documentation set includes the manual: TCP/IP and
        Communications 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.1. In general, this product is more robust than then bundled
PPP.

Features of SunLink PPP 3.0.1 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
- interactive chat scripts for use with token cards
- GUI to initiate and close asynchronous connections
- 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.3: 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 in /etc/asppp.cf 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. Verify that your chat script
in the Systems file is correct by running the following command:

        /usr/lib/uucp/Uutry -r -x9 <remote-system>

where <remote-system> is the value of peer_system_name from
/etc/asppp.cf.
The value of peer_system_name should match an entry in the /etc/uucp/Systems
file. The output of the above command should show your modem dialing into
the remote system, logging in, then several lines of garbage that are the raw
PPP packet. These packets usually have a lot of }}} in them.

If Uutry works ok, proceed with configuring or troubleshooting PPP. If Uutry
does not work you need to troubleshooting your UUCP files and/or modem until
it does work.

IMPORTANT: Since PPP relies on UUCP, it is essential that the UUCP files be
setup correctly and tested with Uutry before attempting to configure PPP.

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)

 2.4: 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.5: 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.6: 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.7: 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, SUNWapppr, SUNWapppu.

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 have an
ethernet interface, look at the client side of the network to network
example in section 3.6.  This 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.

Note: 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 need to install Solaris 2.5 which supports dynamically assigned ip
addresses.

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) or
"TCP/IP and Data Communications Guide" (for Solaris 2.5).

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 down # 1st modem
#       ifconfig ipdptp1 plumb myserver down # uncomment if you have a 2nd
modem
#       ifconfig ipdptp2 plumb myserver down # uncomment if you have a third
modem

        defaults
                interface ipdptp*
                inactivity_timeout 120
                ipcp_async_map 0
        #       debug_level 9   # uncomment for debugging

        path
                peer_system_name johnppp        # matches login name
                peer_ip_address johnhome        # matches hosts entry

        path
                peer_system_name paulppp        # matches login name
                peer_ip_address paulhome        # matches hosts entry

        path
                peer_system_name maryppp        # matches login name
                peer_ip_address marypc          # matches hosts entry

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

------------------------------------------------------------------

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.

The below example shows 2 IP numbers reserved for the 2 ppplinks (modems)
That are used by 6 ppp clients that have the ability to negotiate dynamically
assigned IP numbers (server assigned).
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.2     client
        192.9.200.100   ppplink1
        192.9.200.101   ppplink2

        /etc/asppp.cf:
        ifconfig ipdptp0 plumb myserver ppplink1 down
        ifconfig ipdptp1 plumb myserver ppplink2 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 (or use admintool/ adminsuite):

        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 .

Note: Normally the ppp client users requires another regular shell account
if it is to use application resources on the server.

 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 To Set Up a Dial-Out PPP Client, With Dynamic IP Addressing?

A.  Receiving a dynamically assigned IP address from the PPP server is a
    feature that is only supported in Solaris 2.5. The following example
    is for a system that is connected to a LAN and has a PPP connection to
    an Internet Service Provider. The ISP is using dynamic IP addressing, so
    the client machine receives a new IP address each time it connects to
    the ISP.

    /etc/asppp.cf:

    ifconfig ipdptp0 plumb 192.1.1.10 207.89.17.3 up
    path
        interface ipdptp0
        inactivity_timeout 120
        peer_system_name isp
        default_route
        negotiate_address on

    In the above asppp.cf file, the IP address 192.1.1.10 is a dummy IP address
    that is just used to initially configure the PPP interface, ipdptp0. When
    using dynamic IP addressing, it does not matter what IP address this is as
    the PPP server will be assigning this IP address once the PPP connection is
    made.

    The 2nd IP address in the ifconfig line, 207.89.17.3, is the IP address of
    the ISP. This is a static IP address the ISP should give you. Dynamic IP
    addressing refers only to the assignment of the client IP address, the
    server's IP address remains the same.

    The parameter, negotiate_address, is new with Solaris 2.5. This is the
    parameter that turns dynamic IP addressing on or off. The man page for
    aspppd states that this parameter is turned on by default but this is not
    the case. You must include this parameter and set it to 'on'.

    Since this example demonstrates connecting to an ISP, also include the
    parameter default_route. This will enable PPP to reset your default_route
    each time a new PPP connection is made and a new IP address assigned.

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.

Q. Is synchronous PPP supported?

A. The bundled PPP which comes with Solaris 2.x does not support synchronous
   connections. The bundled PPP in Solaris 2.x does not support direct
   connections between serial ports using a null modem cable. Solstice PPP
   does support both asynchronous and synchronous connections. See
   http://www.sun.com/sunexpress for more information on Solstice PPP.

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
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:09:52 000195 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=5a LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:09:55 000196 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=5b LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:09:58 000197 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=5c LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:10:01 000198 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=5d LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:10:04 000199 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=5e LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:10:07 000200 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=5f LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:10:10 000201 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=60 LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:10:13 000202 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=61 LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:10:16 000203 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req  ID=62 LEN=24
MRU=1500 ACCM=00000000 MAG#=340e77db ProtFCOMP AddrCCOMP
19:10:19 process_ppp_msg: PPP_ERROR_IND Maximum number of configure requests
exceeded

   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
MRU=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) {Unrecognized 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 AddrCCOMP

   ...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

 5.0: Patches

============

The following is the list of all of the PPP patches for 5.3, 5.4 and 5.5.
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-82 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-45 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.

102956-01 SunOS 5.4: PPP diag crashes if non-implemented option received

102820-01 SunOS 5.4: aspppd fixes

 5.3: Solaris 2.4 x86 PPP Patches

--------------------------------

101946-39 SunOS 5.4_x86: jumbo patch for kernel

102855-01 Windows 95 PPP causes Solaris to crash every time

   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.

102957-01 SunOS 5.4_x86: PPP diag crashes if non-implemented option received

102821-01 SunOS 5.4_x86: aspppd fixes

 5.4: Solaris 2.5 PPP Patches

----------------------------

103009-03   Sunos 5.5  PPP driver fixes

            Fixes problem with PPP not working well with Morningstar link
            quality reports; LX panics with zs0 ring buffer overflow/silo;
            SS1000 panics with recursive mutex enter out of unpack_ppp+0x7

 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)

From the Solaris 2.5 System Administration Answerbook and document set:

        TCP/IP and Data Communications Guide

 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.


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

Copyright 1997 Sun Microsystems, Inc. 2550 Garcia Ave., Mt. View, CA 94043-1100 USA. All rights reserved.