PPP over High-Speed Serial Cards
This article shows how to connect a remote node, such
as an employee's
home Sparc, with a corporate network using PPP. (See
Figure 1.) With a
working PPP link, the client node becomes a temporary
part of the
corporate network, allowing it to run applications and
file systems as if it were an on-site node. This is
an ideal solution
for software engineers wishing to telecommute.
A successful new PPP installation requires a great deal
of attention to
the numerous variables involved. Thus, you should follow
a plan of
attack that allows you to verify each step in the process
continuing. Verifying the details in each phase of the
save hours of debugging and the associated frustration
Figure 2 lists the plan I use to guide my installation.
Note that this
plan includes the installation and configuration of
a high-speed serial
card (steps 7 through 8). I completed the installation
of PPP using the
standard serial card and then reconfigured and retested
high-speed card. To further simplify the testing, I
configure and test the client system in-house, and then
move it off-site
for final testing.
I recently used this installation plan to configure
a PPP-link between
the platforms detailed in Figure 3. The following instructions
comments were developed from the record of that experience.
Depending on the status of your operating system, you
may need to
install more than the PPP packages. PPP will not work
properly if you
haven't also installed the appropriate Solaris patches.
For example, if
you don't have certain patches installed on Solaris
2.4, the routing
table may become confused with duplicate routes. For
Solaris 2.4, ensure
that at least Solaris 2.4 Jumbo Kernel patch 101945-27
is installed. Use
the showrev command to check for this patch:
# showrev -p | grep 101945
It is always a good idea to install the latest Jumbo
reading the description and determining that it fixes
problems you are
Once the relevant patches are installed, you can turn
to the PPP
packages. The Sun packages SUNWpppk, SUNWapppr, and
SUNWapppu must be
present on both machines. You use can the pkgchk command
to check if
these packages are already installed on your system.
(See Listing 1.) If
errors are detected with the pkgchk command, try removing
and reinstalling them in the order shown in Listing
After determining that the correct patches and packages
you can begin to adapt the configuration files necessary
for PPP on the
server and client systems. The files will vary slightly
between the two,
so I'll cover each separately, beginning with the server.
For the sake
of brevity and clarity, from here I'll refer to the
server system as
serverPPP and to the client as clientPPP.
Server Serial Line and Modem Setup
First, connect a modem to the desired serial port with
straight-through RS 232 cable. Then configure the serial
port, in this
case serial port A, to connect to the modem. In my initial
connection was bidirectional at 9600 baud. I use the
to modify the serial port's configuration. You can view
configuration with the portadm command:
# pmadm -l
With the port properly configured, you can test the
First, turn on the (already cabled) modem and check
that you have the
front panel indicators listed in Listing 2. The panel
vary depending on the type of modem used. If these are
should be able to interrogate the modem's configuration
by sending it an
at&V command via the UNIX command tip.
Before using tip, add the following line to the /etc/remote
Then, you can connect (remember, to exit tip; use ~.):
# tip -9600 cuaa
New modems should conform to the factory settings. If
you are not sure
of the setting, in most cases, you can reset the modem
using the at&f
command and force the modem to an appropriate state
with the commands in
Once the modem is properly configured, you are ready
to try dialing out
to some site that is known to be working. If you set
the server serial
port to "dial-in only," you can temporarily
change its characteristics
to "bidirectional" or "dial-out"
for this quick test. As long as the
modem on the other end answers, you should be able to
at least establish
Server Files Modified for PPP
Once you have established modem connectivity, you are
ready to begin
editing the PPP configuration files. The first step
is to create a PPP
login account to handle the incoming connection. Again,
I use admintool
to create a login account (called trgPPP), which runs
aspppls instead of
the usual shell. Then, I use a text editor to add the
PPP systems to the
hosts file. (See Listing 4.)
After you create the PPP account, you should modify
the network startup
files to enable ip_forwarding and create appropriate
entries in the
routing tables. (See sidebar on Dynamic IPAddressing.)
By default, ip_forwarding is turned off, causing in.routed
interfaces in the "down" state. Since PPP
is a dial-up interface, it is
brought up interactively only when needed. To keep in.routed
overlooking the PPP paths, you must enable ip_forwarding
and create the
To check the current status of ip_forwarding, type the
# ndd -get /dev/ip ip_forwarding
ip_forwarding equal to "1" means always allow
packets to enter one
interface and be forwarded to a destination through
another interface. I
recommend you enable ip_forwarding by creating a executable
/etc/rc2.d (mine is called S99proxy_ppp_arp -- the name
affects when it
runs). Make certain that you mark the file executable.
This file should
look something like Listing 5.
Finally, modify the /etc/asppp.cf file to reflect your
See Listing 6 for an example that has one interface
ipdptp0 (IP Dial-up
Point To Point).
Note that Listing 6 starts asppd with the debug_level
set to the highest
value, 9. Although this helps during the testing stage,
it is not
appropriate for an operational system. The /etc/log/aspp.log
grow quite rapidly with this option selected.
Another way to initiate level 9 debug level is to modify
/etc/init.d/asppp startup file. Replace the line:
/usr/sbin/aspppd -d 1
/usr/sbin/aspppd -d 9
Client Files Modified
Since the Client node will be used only to dial into
network, its serial port only needs a "dial-out"
Similarly, the modem should be configured exactly like
the server modem,
except that the remote modem does not need to have the
Again, the serial port can configured using admintool.
This example was
configured as "dial- out only." Once you have
set up the modem and
serial port, you can use the UNIX command tip for a
test. Just tip to the server system (this is a good
baseline test). You
should get the login: prompt and be able to log into
a standard account.
The /etc/hosts file must be modified to reflect your
PPP setup. Verify
that the name and address are the same as the server
modify the /etc/asppp.cf.
Listing 7 shows the final client /etc/asppp.cf file
lcp_compression is on. This compression will improve
slightly, but should be disabled during testing. The
value of "120" means timeout in about 2 minutes.
value of "0" means do not timeout.
For PPP negotiations to work at all, the following files
/etc/uucp directory must be set up perfectly.
I have found that a misplaced character in one of these
files can deny
proper connection and magically increase the frustration
Add a line for your modem in the /etc/uucp/Devices file.
Listing 8, is a
sample file with an entry for a Hayes modem on the standard
port, and another entry for a Hayes modem on a serial
Once the Devices file is modified, verify that there
is an entry for
your modem type in the /etc/uucp/Dialers file. This
file comes with
entries for a number of different types of modems. Most
modem will be compatible with one of the standard entries.
on Modem Compatibility.)
Next, make an entry for the server in the /etc/uucp/Systems
Listing 9 gives an example. The trickiest part of this
file is the chat
script that automates aspppd's login process. The expect
this script must match the login prompts on your server.
sequences must match the account name and password information
Finally, remember to create a default router entry in
/etc/defaultrouter file. This file contains the address
or hostname of
the default IP gateway. In our proposed network, the
PPP interface will
be the default gateway for the remote machine.
Connect to Server
To test the dialer, serial port, and modem configuration,
dial from the
client to server using cu. The cu command is a good
test to run just
before turning on the PPP daemons because it uses the
Devices, and Dialers files as the PPP daemons. Before
initiating the cu
command, try the tip command to verify your modem setup
once more. Next,
type the cu command and carefully review the results.
If all is working well, you should get the login: prompt
and be able to
log into any standard account. An example test session
is shown in
Once you are satisfied that you can dial into the server,
aspppd on both server and client systems. Monitor the
by watching the PPP log file /etc/log/assppp.log on
each machine. (See
sidebar on Debugging.)
I found it useful to have at least two xterm windows
open during these
tests on the console. One window can be used for debugging
start/stop of aspppd:
# /etc/init.d/aspppd start
# ping serverPPP
In the second window, you can view the PPP log file:
# tail -f /etc/log/asppp.log
The example log file in Listing 11 shows a typical negotiation
The last line in Listing 11 is a good sign!
High-Speed Serial Card Upgrade
Once the PPP configuration is stabilized on the Sun
serial port, you can
install the additional serial cards and modify the appropriate
am using the Magma LC2+1 Sbus serial card, which is
able to support
speeds up to 115200 bps from the serial card to the
installing, I needed to verify that I was working with
the correct PROM
level for Solaris 2.x. A quick scan of the Sbus card
revealed a "-S"
after the REV number (i.e., 056000 REV C-S). Also, because
the Magma cards from a fellow employee, I wanted to
make sure that I was
working the with latest device driver. After contacting
determining that my driver was indeed an older version,
I downloaded the
latest driver from their ftp site.
Magma recommended reviewing the patch levels of the
installing. Read their README file for each release,
and if patches are
needed, install in their numerical sequence. Before
installing the Magma
driver, you must install the Magma Sbus serial card
and perform a
# reboot _ -r
Once you've rebooted both the client and server systems,
you can install
the driver. Magma's install process is in package form,
and they built
an install script around it; therefore, just a quick
after disabling the volume manager was needed.
Move the modems to new lines on both the client and
server systems. In
this case, the new port was /dev/tty00. admintool was
used to specify
the new port desired. Note that Magma reuses some of
the lower baud
rates for their higher speeds. For example, 1800 actually
115200. The value 1800 is used in configuration files
If Magma's setport command is used, other port configuration
are not necessary. I placed the setport command in a
startup file, which
was all that was needed (i.e., setport supersedes any
other values that
were set to the port).
# setport ttym00 115200 cs8 -parenab crtscts
Once the cards are installed, and the modems are connected,
use the tip
command again to verify connectivity. Then modify the
Systems files to reflect the higher baud rates and serial
lines. Listing 12
shows my entries.
The same cu command as used above can be used to test
configuration (see Listing 13). Review the results after
command. Remember to stop aspppd before performing the
When you are satisfied with the cu tests, start aspppd
on both systems
and monitor the /etc/log/asppp.log files. Once negotiations
properly, you may want to turn off or lower the debug
level in the
/etc/asppp.cf file or in the /etc/init.d/asppp file,
whichever was used.
Several different types of PPP installations exist,
some more automated
then others. Automated or not, after my last few sessions
(Point-to-Point Protocol), I think the acronym should
be changed to mean
Persistence-Plus-Perseverance. Several areas can go
wrong when setting
up a PPP configuration, and I think I experienced most
of them. I hope
this article will make your installations go smoothly.
In particular, I can't overstate the importance of a
plan. Working through the installation in incrementally
can save many hours of frustration and help relieve
some of the inherent
stress of system administration.
Many thanks to Bruce Schoenleber of Magma (firstname.lastname@example.org)
patience in helping on the initial PPP installation.
About the Author
Thom Garrett has been involved in various aspects of
installation and administration for about 10 years.
He received a B.S.
in Mathematics/Computer Science from Virginia Commonwealth
He is currently employed at Digital System Resources,
Inc located in
Farifax, Virginia, where he is Manager of Computer Services.
He can be
reached at email@example.com.