Article

How to Make a Solaris 2.5.1 Workstation Support PPP Dial-Up from Windows

Ben Diamond

About six months ago a client asked my team to put one of our Solaris workstations/ftp servers into their facility and remotely manage it. For security reasons, however, they would not grant us access from the Internet through their firewall. Our only option for remote support was direct dial-up, which they did allow and for which they provided the phone line.

My support staff primarily uses Windows 98 or NT workstations on their desktops. The trick to this customer's request was how to easily and reliably enable our Windows PCs to gain full (albeit slow) access to the remote Solaris workstation.

It is easy to get a Solaris 2.5.1 workstation to support a dial-up terminal session. A terminal session enables a remote client (for example, Windows 95/98 running “HyperTerminal”) to have a shell into the machine to run command-line programs. However, loading files to and from a remote Sun Sparc is cumbersome through a shell interface. To upload or download large binary files, and even small ASCII files, requires kludgy old utilities like kermit, ymodem, or zmodem. Furthermore, terminal sessions give no access to the easy, intuitive GUIs that OpenWindows, Common Desktop, or other windowing and X Window front-ends give you. Also, you can only run one terminal shell at a time per dial-up connection.

You must establish a TCP/IP connection over the dial-up phone line (as opposed to a regular terminal session) in order to use easier, newer graphical file transfer tools like WSFTP, or even MS Explorer, to run multiple terminal sessions to the same machine at once (multiple telnet sessions), and to get remote graphical control over the Sun Sparc (e.g., rexec - xterm through an X windowing program). The only way to use TCP/IP over a dial-up connection to a Solaris machine is to run PPP (Point to Point Protocol) or SLIP (Serial Line Interface Protocol). These act as shims to allow TCP/IP to run over a serial-line connection.

Sun Microsystems, Inc. sells Solstice PPP 3.0.1, which helps configure a Sun Solaris 2.4 (or later) server for PPP and provides an easy-to-use command line or graphical front-end. However, the $995.00 price tag per server is large, especially considering that all of the necessary tools are built into the Solaris OS. (The command-line version of the Solstice PPP product is shipped with Solaris 2.6, 2.7, and 2.8, but not 2.4 or 2.5.1. One more reason to upgrade!)

This article outlines the necessary steps to get PPP running under Solaris 2.5.1 on a Sun Ultra or Sparc 20, which will then act as a PPP server for a Windows 9x client. This is done without the need for Sun's “Solstice PPP 3.0.1” product. This article will not discuss Sun-to-Sun PPP or any type of dial-out PPP configurations. For a detailed look at the full range of configuration options, see “TCP/IP and Data Communications Administration Guide, November 1995”, available from www.sun.com or docs.sun.com. This article assumes that you currently have physical access to the Sun Sparc and are configuring it for future remote access.

First Things First

Set up the modem and initialize the serial connection. Start with a US Robotics modem. This is what Sun recommends. You can use anything with a speed of 9600 or greater (the faster the better, for obvious reasons), but the maximum throughput you can ever hope for is 38.4 Kb over the serial line in Solaris 2.5.1 or earlier. Solaris 2.6 and later support greater speeds on Ultra 2's, 5's, 10's and better. (Note that this is only the connection speed between the Solaris host and the modem. The modem-to-modem speed will be auto-negotiated between the two modems.) US Robotics modems usually have DIP switches on the back. If so, set switches 1-7 to “off” and switch 8 to “on”.

In my setup, I use the 9-pin serial port for connecting the Ultra to the modem. You need a modem cable with 25-pin male on the end connecting to the modem, and a 9-pin female end for the Sparc Ultra 5. For a Sun Sparc 20, you need a 25-pin male to 25-pin male cable (or some sort of gender adapter) and the y-terminal splitter that came with the Sparc. The 9-pin connection on the Ultra will be associated with the device /dev/cua/b. (On some Solaris OS loads, the device name is /dev/cuab, not cua/b. Check your /dev/ directory to see which is on your system.)

Log in as the root user, bring up OpenWindows, and launch admintool to get access into the Serial Port Manager so you can set up the modem port (Figures 1 and 2).

Choose “port b” and go into the Expert setup. Set port b to “Enable” and set the baud rate of your modem. Leave the terminal to TVI925. Set the Comment to “Dial-In Only”. (I've had a lot of problems with bidirectional modem ports in Solaris 2.5.1. If you don't need to dial out of this port, you will have fewer problems by setting it to “dial-in only”.) Leave the “Services” field as-is, but you can set a timeout time if you are worried about security. Set “connect on carrier” to automatically give a login prompt without forcing the client to issue a carriage return first. Selecting “software Carrier” forces the Sun to use Software flow control with the modem (X-on, X-off), as opposed to hardware control. You do not want to use this setting if you can avoid it.

For more information on the graphical Serial Port Manager, see pages 1109-1128 of Sun's “System Administration Guide, Volume II, November 1995”. For information on how to use command-line options to set up the ports, see pages 1129-1152.

This graphical interface performs the same function as the command-line program ttyadm. For information on how to use command-line options using ttyadm to set up the ports, see pages 1129-1152 or the man pages on ttyadm. Both programs modify the file /etc/saf/zsmon/_pmtab, which you can manually modify if you do not have access to admintool.

myhost# more /etc/saf/zsmon/_pmtab

# VERSION=1
ttya:u:root:reserved:reserved:reserved:/dev/term/a:I::/usr/bin/   \
   login::9600:ldterm,ttcompat:ttya login\: ::tvi925:y:#
ttyb:u:root:reserved:reserved:reserved:/dev/term/b:c::/usr/bin/   \
   login:120:38400:ldterm,ttcompat:ttyb    \
   login\: ::tvi925:n:#Modem - Dial-In Only

Your modem is now set to receive incoming calls and will issue a login prompt. At this point, you could use any terminal session program from your client PC (Procom, HyperTerminal, etc.) to get a terminal session on the Sparc. However, you want PPP.

Before Proceeding

Check that the Solaris version of PPP is installed on all machines to be involved in the PPP link. On the Sun server, type:

# pkginfo | grep ppp

If PPP is installed, the following package names will be displayed:

SUNWpppk # Contains kernel modules
SUNWapppu # Contains the link manager and login service
SUNWapppr # Contains configuration files

If PPP is not installed on an endpoint system, install it using either the pkgadd program or admintool software manager. (Note that when using pkgadd to install PPP, you must install the packages in the order listed above.)

Setting up the Modem

After PPP is installed, you can set up the modem to use PPP. You must first decide how PPP is to be implemented. Do you want PPP access only to your Sun Sparc, or do you want PPP/TCP/IP access to the entire network on which the Sun is sitting?

You can set up the PPP so that the dial-in machine gets a valid IP address on the host's real network. This is a bit simpler to configure than what I describe below, and it also allows direct TCP/IP access to the hosts network. However, remember my security conscious client? They don't want my support staff making direct connections into their network. They will not give me another valid IP address from their network (which I would need to assign to the remote dial-up client), and I don't want extra network traffic from their end to slow down my already crawling dial-up line. I will set up a PPP connection so that the dial-in client only has direct TCP/IP access to the host server. It will not be able to ping other hosts on the network directly, although I could launch a telnet session to the host and then ping out into the network. In effect, I will set up a virtual network between the PPP server and dial-up client.

If, however, you do want the Sun Sparc to route traffic from the serial line to the Ethernet port, and vice versa, you have to:

1. Create an empty file called /etc/gateways
2. Make sure there is no file called /etc/norouter
3. Turn RIP on for the virtual PPP interface that you will create in the next step (ipdptp0).

The “TCP/IP and Data Communications Administration Guide, November 1995”, has more information about this step on page 85 (/etc/gateways), pages 126-127 (RIP), and scattered throughout the text. You also have to manually add the DNS servers into the Windows dial-up settings (see below). Finally, if this server is behind a firewall, you will need to modify the firewall to let it know how to reach the new subnet 192.168.200.0.

Creating a Virtual Network

Assume that the Sun Sparc is on a network of 199.199.0.0. Its IP address is 199.199.0.60 (alias “server”) and there are plenty of other machines on this subnet. You will be creating a virtual network 192.168.0.0 to the Sun's dial-up connection. You will create two IP addresses in this virtual subnet:. The PPP server's virtual IP address will be 192.168.200.100 (alias “server-ppp”), and the IP address it will assign to the dial-in port will be 192.168.200.1 (alias “nomada”). (Again, this step is unnecessary if you have an additional IP address on the client's network.)

Add an entry with the IP address for the PPP interfaces to the /etc/inet/hosts file for the dial-in server.

# Internet host table
#
127.0.0.1 localhost loghost
199.199.0.60 server
192.168.200.100 server-ppp  #virtual IP for this machine as a PPP 
                            #server
192.168.200.1 nomada        #virtual IP for nomadic dial-up client

Add a new network number to the dial-in server's /etc/inet/networks:

server-ppp 192.168.200      #virtual PPP network

Edit the /etc/uucp/Devices File

Sun says the /etc/uucp/Devices file must contain entries for every communications device that a particular host uses or must know about. For example, if a machine uses a US Robotics V.32bis modem as part of the PPP link, ensure that /etc/uucp/Devices has an entry similar to the following:

# Use these if you have a USrobotics V.32bis modem on Port B.
ACUEC cua/b - 9600 usrv32bis-ec
ACUEC cua/b - 19200 usrv32bis-ec
ACUEC cua/b - 38400 usrv32bis-ec

In practice, this step is not necessary if you are just setting up a dial-in PPP server. The files in /etc/uucp are used in dial-out scenarios, not dial-in scenarios. If you expect to use the Sparc for PPP over dial-out to another PPP server, then you need to make these changes, as well as changes to /etc/uucp/Systems (see page 138, TCP/IP).

Configure a Dial-In Server

To configure a dial-in server, you must also edit the /etc/passwd and /etc/shadow files. The best way to do this is via admintool/add users. You must add entries to the /etc/passwd file on the dial-in server for each user on a remote host authorized to log into the server.

When a remote host connects to the dial-in server, the server reads its UUCP databases and passes the server a user name or user ID for the host initiating the call. The server then verifies this user information in its /etc/passwd file and runs the appropriate initialization script. A normal /etc/hosts entry would initialize a shell like csh, ksh, or bash. The login here initializes a program called aspppls instead of a shell. Thus, this account is not a login account, but rather an account that exists solely to initialize a PPP connection.

Add a user called “nomada” and be sure to set the shell to /usr/sbin/aspppls:

nomada:x:21:99:PPP shell launcher:/:/usr/sbin/aspppls

Configure the /etc/asppp.cf Configuration File

The /etc/asppp.cf configuration file provides the PPP link manager on one endpoint machine with information about the machine on the other end of the link. When the server boots, the link manager uses this information to establish and maintain communication with a remote endpoint. Use the following configuration:

ifconfig ipdptp0 plumb server-ppp nomada up
path
interface ipdptp0
peer_system_name server-ppp # The name in the /etc/uucp/Systems file
inactivity_timeout 300 # Allow five minutes before timing out

ifconfig Section of the asppp.cf File

The asppp.cf file must contain an ifconfig section with this syntax:

ifconfig interface-number plumb local-machine remote-machine up

Here are descriptions of the fields:

• ifconfig -- Tells the link manager to run the ifconfig command and begin configuring the PPP interface.

• interface-number -- Identifies the PPP interface ipdptpn for a point-to-point link or ipdn for a multipoint link. (Replace the n with the number of the interface.)

• plumb -- Option of ifconfig that enables IP to recognize the interface.

• local-machine -- Gives the name of the local endpoint, which can be the local host name or IP address.

• remote-machine -- Gives the name of the remote endpoint, which can be the remote host name or IP address.

• up -- Option of ifconfig that marks the interface just described as up.

The link manager first runs the ifconfig command on the local machine to configure the ipdptp0 point-to-point interface. The zero in ipdptp0 gives the device number of the interface. The plumb option performs various activities necessary for IP to recognize the ipdptp0 interface. nomada is the name of the local host. Server-ppp is the name of the dial-in server to which nomada will connect through the point-to-point link. The ifconfig option up marks the ipdptp0 interface as up. For more information about ifconfig, see Chapter 10, “Troubleshooting PPP”, and the ifconfig(1M) man page.

Reboot

Reboot the server (init 6). To confirm that PPP started, type:

ps -e | grep asppp

You should see the daemon running. You can start PPP manually without rebooting, but it's a good idea to make sure that PPP will start automatically after reboots. To manually start/stop PPP, type:

# /etc/init.d/asppp start

# /etc/init.d/asppp stop

If you run ifconfig -a from the command line, you should see the following:

#ifconfig -a
ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
        inet 192.168.200.100 --> 192.168.200.1 netmask ffffff00
        ether 0:0:0:0:0:0

You are now done with the server and need to set up your Windows PC dial-up client.

PC Client-Side Settings for Dial-Up PPP to Solaris 2.5.1 Running aspppd

After setting up aspppd (the serial PPP daemon) on the server, configure the following options on the Windows client PC in order to connect. Create the script shown in Listing 1 and place it in:

C:\Program Files\Accessories\Sun_dialup-ppp.SCP.

In Control Panel/Dial-up Networking, create a new connection with the client's name (e.g., clientx_dialup-ppp). Set the phone number, then finish. Right click on the new connection and set the following options (Figure 3):

Type of Dial-UP Server: PPP: Internet, Windows NT Server, Windows 98 
Advanced options: Enable software compression 
Advanced network protocols: TCP/IP
TCP/IP Settings: Server assigned IP address; DNS entries depend on your needs 
Scripting: C:\Program Files\Accessories\Sun_dialup- ppp.SCP

The Dial-up Networking connection should log onto the “nomada” account you created in the server configuration. As previously stated, this account only starts a PPP connection. It does not actually log you into a machine or network. You still need a valid account name and password to gain access to services on the server (Figure 4).

Dial up and connect to the PPP server. This profile will connect to the server, receive a terminal session from the server, and login as “nomada,” which then kicks off a PPP session. After PPP is successfully established, you will not see a terminal session or any other clues that you are connected to the remote server, except for the dial-up networking icon in your system tray. However, you are now connected to the server over TCP/IP and are free to use your favorite Internet utilities, like telnet or ftp, to connect to the host. Here's where you use a valid login name and password. At this point, you can launch telnet or some other TCP/IP application and connect to 192.168.200.100.

If you followed the instructions for setting up the dial-up-ppp server, then your PC's IP address for this connection is 192.168.200.1 and the server is 192.168.200.100. You will not be able to connect directly to other hosts/networks or the Internet at-large, but you will be able to run multiple terminal sessions to the remote hosts and take full advantage of Windows graphical utilities like telnet and ftp. You can also take advantage of Sun graphical utilities like admintool and filemgr or the entire Sun desktop using an X Window manager on the PC. I recommend testing this configuration locally by dialing to the Sun over the PC's modem before you ship the Sun to your remote location.

Conclusion

I've shown how to manually configure a Sun Ultra 5 or Sparc 20 running Solaris 2.5.1 to be a dial-in PPP server. There are a few notable differences between what I outlined and what is provided with Sun's Solstice PPP package.

Configuration scripts are a big advantage of the Solstice PPP product. A second advantage is a more automated login service. One of the downsides of the configuration outlined here is the need for the login script on the Windows 95/98 client. Most ISPs do not require that the client run a login script for connectivity, and neither does Solstice PPP. Instead of /usr/bin/aspppls, Solstice PPP runs /usr/bin/pppls (added during installation of Solstice PPP and included in Solaris 2.6 - 2.8), which automatically picks up the login and password from the Windows dial-in client. It does not need the Windows client login script. This makes it a lot easier to roll this service out to many users -- just give the end users login information and a phone number -- no need to manage scripts.

The Solstice PPP 3.0.1 product makes PPP configuration a lot easier. Sun's online product description for Solstice PPP 3.0.1 states one of its main benefits as: “Simple port and modem configuration. The user does not need to go through a complex uucp configuration process to use asynchronous PPP”. For $995 per server, you should expect it to be easier.

References

Cel este Stokely's Tutorial on Solaris 2.x Modems and Terminals at: http://www.stokely.com/unix.serial.port.resources/modem.html.

“Co nfiguring and Using Solstice PPP Servers and Routers, March 1996,” available from www.sun.com or docs.sun.com.

“Co nfiguring U.S. Robotics Modems for Use under Unix-Type Systems” (Applies to U.S. Robotics Sportster and Courier modems): http://consumer.3com.com/ \
modem/documents/10563.htm

Solstice PPP 3.0.1 Product Description: http://store.sun.com/catalog/ \ doc/BrowsePage.jhtml?PartGID=1ZZZZZQ0X22X3M0LLWZDBDI5TWZ3B0YQ

About the Author

Ben Diamond is the Director of Information Technology at Health Care Compliance Strategies, which authors high-end multimedia CBT for the healthcare industry. He holds a B.S. in Labor Relations from Cornell University and an M.A. in English from the University of Maryland. He currently manages an array of Sun servers, which support more than 50, 000 CBT users. He can be reached at: brd@hccsonline.com.