PPP over High-Speed Serial Cards
Thom Garrett 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 access corporate 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 before continuing. Verifying the details in each phase of the installation can save hours of debugging and the associated frustration and headaches. 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 with the high-speed card. To further simplify the testing, I recommend you 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 and comments were developed from the record of that experience. Software Installation 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 Kernel after reading the description and determining that it fixes problems you are currently experiencing. 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 the packages and reinstalling them in the order shown in Listing 1. After determining that the correct patches and packages are installed, 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 a straight-through RS 232 cable. Then configure the serial port, in this case serial port A, to connect to the modem. In my initial setup, the connection was bidirectional at 9600 baud. I use the Solaris admintool to modify the serial port's configuration. You can view the resulting configuration with the portadm command:
# pmadm -l
With the port properly configured, you can test the modem configuration. First, turn on the (already cabled) modem and check that you have the front panel indicators listed in Listing 2. The panel indicators may vary depending on the type of modem used. If these are correct, you 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 file:
cuaa:dv=/dev/cua/a:
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 Listing 3. 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 modem connectivity. 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 to ignore interfaces in the "down" state. Since PPP is a dial-up interface, it is brought up interactively only when needed. To keep in.routed from overlooking the PPP paths, you must enable ip_forwarding and create the appropriate routings. To check the current status of ip_forwarding, type the following:
# 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 file in /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 configuration. 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 file will grow quite rapidly with this option selected. Another way to initiate level 9 debug level is to modify the /etc/init.d/asppp startup file. Replace the line:
/usr/sbin/aspppd -d 1
with
/usr/sbin/aspppd -d 9
Client Files Modified Since the Client node will be used only to dial into the corporate network, its serial port only needs a "dial-out" characteristic. Similarly, the modem should be configured exactly like the server modem, except that the remote modem does not need to have the Auto-Answer feature enabled. 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 quick continuity 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 system. Then, modify the /etc/asppp.cf. Listing 7 shows the final client /etc/asppp.cf file in which lcp_compression is on. This compression will improve performance slightly, but should be disabled during testing. The inactivity_timeout value of "120" means timeout in about 2 minutes. An inactivity_timeout value of "0" means do not timeout. Dial-Up Details For PPP negotiations to work at all, the following files in the /etc/uucp directory must be set up perfectly.
/etc/uucp/Devices /etc/uucp/Dialers /etc/uucp/Systems
I have found that a misplaced character in one of these files can deny proper connection and magically increase the frustration level simultaneously. 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 /dev/ttya port, and another entry for a Hayes modem on a serial card port /dev/tty0. 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 likely your modem will be compatible with one of the standard entries. (See sidebar on Modem Compatibility.) Next, make an entry for the server in the /etc/uucp/Systems file. Listing 9 gives an example. The trickiest part of this file is the chat script that automates aspppd's login process. The expect sequences in this script must match the login prompts on your server. The send sequences must match the account name and password information for the PPP account. Finally, remember to create a default router entry in the /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 same Systems, 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 Listing 10. Once you are satisfied that you can dial into the server, start the aspppd on both server and client systems. Monitor the PPP negotiations 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 and 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 sequence. 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 files. I 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 modem. Before 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 I inherited the Magma cards from a fellow employee, I wanted to make sure that I was working the with latest device driver. After contacting Magma and 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 OS before 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 reconfigure boot.
# 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 install command after disabling the volume manager was needed.
# ./MAGMA_install
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 corresponds to 115200. The value 1800 is used in configuration files as well. If Magma's setport command is used, other port configuration commands 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 Devices and 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 the new configuration (see Listing 13). Review the results after issuing the command. Remember to stop aspppd before performing the cu tests. When you are satisfied with the cu tests, start aspppd on both systems and monitor the /etc/log/asppp.log files. Once negotiations are working 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. Conclusion Several different types of PPP installations exist, some more automated then others. Automated or not, after my last few sessions with PPP (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 staged testing plan. Working through the installation in incrementally tested phases can save many hours of frustration and help relieve some of the inherent stress of system administration. Many thanks to Bruce Schoenleber of Magma (bruce@magma.com) for his patience in helping on the initial PPP installation.
About the Author
Thom Garrett has been involved in various aspects of system/network installation and administration for about 10 years. He received a B.S. in Mathematics/Computer Science from Virginia Commonwealth University. 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 tgarrett@dsrnet.com.
|