Configuring Solaris as a dial-up server

For enterprise-level IT departments, setting up a dial-up server is critical to business. Stew Benedict walks you through setting up a dial-up server with Solaris and then makes the connection with an array of operating systems.

You have Solaris up and running and set up to your internal network. You have a Web server and a database server running, and with PHP you can do some neat things by tying the two together. Now suppose you want to share this newfound power with some friends or access your server from work or while on vacation? You can readily do that by configuring the machine to act as a dial-up server and with some additional software, you can make it look like a native Windows or MacOS server.

Most SPARCs do not come with internal modems. You connect an external modem to the built-in serial port or add S-bus serial MUXes, such as those made by Aurora and others, to have multiple serial ports. If you were using this box as a dial-up server for an ISP, you might look at implementing something like a Livingston unit for banks of modems. In that case, much of the following dial-up setup will be done by your hardware.

I'm using a SPARC20, which has a two-in-one serial port. One 25-pin D connector on the back of the machine requires a special cable in order to split into two 25-pin connectors. You can get this cable from Sun or some other vendors, but if you need only a single serial port, a standard cable will access port A.
This page has a wiring diagram, if you wish to make your own cable.
Connect your cable to an external modem (I'm using a 56-K Hayes model), and you can begin setting up the software on Solaris to monitor the port. We’ll assume that you’re using the first serial port, Port A; adjust the technique as necessary if you’re using Port B. This work should all be done as root.

Doing tty dialup
First, we'll make sure that we can do a simple tty dialup and get a login prompt. Open /etc/ttydefs with your favorite text editor and add the following line at the bottom:
modem:115200 -parenb cs8 -clocal hupcl:115200 -parenb \
cs8 -clocal hupcl crtscts::modem

(The \ indicates that this entry should all be on one line.)

If you have an older SPARC, then you may need to back down the speed appropriately to 38400, or 19200, or even 9600 (yuck!). For my SPARC20, I had to set the speed to 38400.

You'll also need to make a modem entry in /etc/remote:

Again, adjust the speed as necessary.

The next step is to run admin tool and select Browse | Serial Ports. Double-click on a and make the following Template settings:
  1. Set the Modem to Bidirectional. (We want to still be able to dial out).
  2. Set the Detail to More.
  3. Check Service Enabled for Port A.
  4. Set the Speed to Other.
  5. Enter modem in the Input text box to correspond to our entry in /etc/ttydefs.
  6. Set the terminal type to vt100.
  7. Set your login prompt.
  8. Comment as desired.
  9. Leave the rest of the settings at the defaults.

Check your setup by typing pmadm –l. You should see the following output:
bash-2.03# pmadm –l
zsmon  ttymon  ttyb   u root /dev/term/b I
- /usr/bin/login - 9600 ldterm,ttcompat ttyb login: - tvi925 y #
zsmon  ttymon  ttya   u root /dev/term/a b
- /usr/bin/login - modem ldterm,ttcompat login: - vt100 n #Modem -

To enable a banner upon connection, echo an appropriate comment into /etc/issue:
echo "Welcome to AYSNET..." > /etc/issue

Check the permissions on your device file. The device should have at least Owner, Read, and Write permissions. The /dev/term/a entry is a symbolic link to the actual hardware device. Here are the settings from my system:
bash-2.03# ls -l /dev/term/a
lrwxrwxrwx 1 root root  32 Sep 28 11:28 /dev/term/a
-> ../../devices/obio/zs@0,100000:a
bash-2.03# ls -L /dev/term/a
crw-rw-rw- 1 root sys  29, 0 Sep 28 11:27 /dev/term/a

If the permissions are not as shown here, set them with the following commands:
chmod 777 /dev/term/a
chown -h root /dev/term/a
chgrp -h root /dev/term/a
chmod -R 600 /dev/term/a
chown root /dev/term/a
chgrp sys /dev/term/a

The -h option tells chown and chgrp to modify the symbolic link.

Now you need to set your modem to auto-answer. For this you can use tip:
# tip modem

ATS0=1  (answer incoming calls on 1 ring)
AT&D0  (ignore DTR)

If you want the modem to store this setting, you can write it to the modem's NOVRAM:

To exit tip, type
<ENTER> ~.

where <ENTER> is the Enter key, or Return on a Sun keyboard.

If you have another phone line, you can now dial in to your system, or you can ask a friend to dial in for you. Once you see the CONNECT string, hit [Enter] or [Return] and you should see the login banner and get a login prompt.

Providing services for Windows and Mac users
Okay, now we're connected, and other UNIX users can connect, telnet, ftp, etc., but we'd also like to provide services for those folks that haven't joined the UNIX bandwagon, namely Windows and Mac users. Luckily, some clever folks have worked this out with Samba for the Windows crowd and netatalk for the MacOS folks.

Samba setup
The latest stable version of Samba is 2.0.7. There is a binary tarball for Solaris 7 on the Samba ftp site. But we're gluttons for punishment, so we'll build from source, which can also be found on the Samba ftp site.
gtar -xzf samba-2.0.7.tar.gz
./configure —prefix=/usr —libdir=/etc \
—with-lockdir=/var/lock/samba —with-privatedir=/etc \
—with-swatdir=/usr/share/swat —with-quotas —with-pam
sudo make install
sudo cp examples/simple/smb.conf /etc
cp examples/svr4-startup/samba.server /etc/rc3.d/S85samba

Edit to fit your installation; mine is as follows:
# Start/stop processes required for samba server
case "$1" in
/usr/local/bin/smbd -D
/usr/local/bin/nmbd -D
killproc nmbd
killproc smbd
echo "Usage: S85samba { start | stop }"

Make a copy for the shutdown sequence, too:
cp /etc/rc3.d/S85samba /etc/rc0.d/K85samba

Here’s a very basic /etc/smb.conf file:
debug level = 10
server string = Samba Server - Sparc
guest account = nobody
log file = /var/adm/log.smb
workgroup = AYSNET
hosts allow = 192.168.192. 127.
security = user
interfaces =
netbios name = curly-joe

comment = Home Directories
browseable = no
read only = no
create mode = 0750


path = /home/public
public = yes
only guest = yes
writable = yes
printable = no
browsable = yes

This file omits the printers, which doesn't make much sense for a dial-up connection. It gives each user access to their home directory as well as the shared public directory. The two entries in the interfaces support our local LAN and the dial-up connections. You can do a lot more with Samba, and the manual is included in the distribution.

Netatalk setup
Netatalk can be downloaded from Cobaltnet. The Netatalk Guide is located at the Netatalk project.

By default, netatalk builds to install in /usr/local/atalk, so we'll leave it there. Edit the top-level make file and comment out the following lines (place a # in front of them):

I was unsuccessful in getting netatalk to work with PAM, even though it is present on Solaris. TCPWrappers may be desirable, and if you’re interested, you can download it from Porcupine.org.

If you want encrypted passwords, you'll need the DES library.

Edit etc/afpd/Makefile and add

By now, the routine should be second nature:
gmake install

Add the following line to /etc/netconfig:
ddp tpi_clts - appletalk ddp /dev/ddp -

For Solaris, we need to install a kernel patch (as root, no sudo):
cd /home/stew/netatalk-1.4b2+asun2.1.3/
gmake kinstall

And finally, we’ll do some configuring:
echo le0 > /usr/local/atalk/atalkd.conf

Edit /usr/local/atalk/etc/afpd.conf:
- -loginmesg "Welcome to AYSNet"

Edit /usr/local/atalk/etc/AppleVolumes.default:
~    "AYSNet Home Folder"
/home/public "AYSNet Public Folder"

Note that the public directory is the same one we set up for the Windows users. This will allow these two groups of users to share files if necessary. Also copy AppleVolumes.system from the source directory to /usr/local/atalk/etc. This file lists the associations of file types so the Mac clients can recognize files and open the appropriate application when they are logged on.

PPP server setupMuch of this information was derived from the Solaris Resources at Kempston site.
One issue I had, as a lazy, yet efficient, administrator, was editing separate entries with fixed IP addresses for each user. I used my shortcomings as a clue to enhance this task by dynamically allocating addresses from a pool and using PAP authentication.

Check to be sure you have ppp installed:
pkginfo | grep ppp
system SUNWapppr PPP/IP Asynchronous PPP daemon configuration files
system SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service
system SUNWpppk PPP/IP and IPdialup Device Drivers

Choose a pair of IP addresses that fit in with your existing network setup. I’m using 192.168.192.xxx, and I have these available: - server IP - client IP

Edit /etc/hosts and add the new entries: dialup_server dialup_client1 dialup_client2 dialup_client3

Notice the third and fourth entries: You can continue to add these entries to accommodate as many dial-up lines as you have available.

The program to call ppp is /usr/sbin/aspppls. We’re going to alter the login action, so that when the user logs in, we will launch this as a shell and initiate the ppp connection. For a larger pool of modems, we may want to pick from a pool of IP addresses or use dhcpd.
cp /etc/asppp.cf /etc/asppp.cf.original
cp /etc/asppp.cf /etc/asppp.cf.dialin

Edit /etc/asppp.cf.dialin and add the following:
ifconfig ipdptp0 plumb dialup_server dialup_client1 down
ifconfig ipdptp1 plumb dialup_server dialup_client2 down
ifconfig ipdptp2 plumb dialup_server dialup_client3 down
interface ipdptp*
inactivity_timeout 900
debug_level 5
will_do_authentication pap


peer_system_name  stew
pap_peer_id    stew
pap_peer_password  some_password

The debug_level can be set high initially, while you're debugging, and then reduced if you like. The ifconfig line will need to be duplicated for each dial-up IP you've allocated, and the path entry will be repeated for each dial-up user. The man pages for aspppd or aspppls discuss the various configuration options. The password will appear in plain text, so you'll want to be sure to have appropriate permissions on this file to keep the world from seeing it.
chmod 600 /etc/asppp.cf
chmod 600 /etc/asppp.cf.dialin

We could also configure using CHAP instead of PAP, but since we're going to be doing a UNIX command-line login, CHAP doesn't do much for us. We'll now replace the users' shell in /etc/passwd with aspppls, which will allow them dial-up access but will not allow command-line access to the machine (this is a good thing).

Change the old /etc/passwd entry


We also need to add aspppls to /etc/shells, because netatalk expects to see the users' shell there:
# echo '/usr/sbin/aspppls' >> /etc/shells

We need to find the machine's MAC (Media Access Control) address to set up proxy arp entries:
ifconfig -a | grep ether

This command returns the MAC address in the form
ether 8:0:20:81:94:38

The MAC address of your Solaris system will differ from this example. You’ll need this MAC address to allow the client to communicate with the rest of the network with the arp command, as follows:
/usr/sbin/arp -s ppp_client1 8:0:20:81:94:38 pub

We also need to enable packet forwarding in the kernel:
ndd -set /dev/ip ip_forwarding 1

We accomplish both, for all the dial-up clients, with a script. Create a file in the /etc/rc2.d directory named S45dialin containing the following:
/usr/sbin/ndd -set /dev/ip ip_forwarding 1
for host_id in `grep dialup_client /etc/hosts | awk '{print $2}'`; do
/usr/sbin/arp -s $host_id 8:0:20:81:94:38 pub

Make the new script executable:
chmod 744 /etc/rc2.d/S45dialin

This script file is executed automatically before the S47asppp script, which starts the aspppd PPP daemon.

PPP log file
We should also create a PPP log file so that we have a way to troubleshoot the connection:
touch /var/adm/log/asppp.log

To prevent the routing process from sending routing information packets (RIP ) out the dial-up interface, edit /etc/gateways and add an entry for each interface:
norip ipdptp0
norip ipdptp1
norip ipdptp2

Now test the ppp dial-in. As a start, if you don't have two phone lines, just telnet in from another machine as one of the ppp users. Copy /etc/asppp.cf.dialin to /etc/asppp.cf:
cp /etc/asppp.cf.dialin /etc/asppp.cf

Stop and restart the asppp daemon, which provides ppp services:
/etc/init.d/asppp stop
/etc/init.d/asppp start

Now check the PPP log file window for any errors reported during startup of the asppp daemon. If there are any syntax errors in the /etc/asppp.cf.dialin file, the PPP daemon will write an error message to the log file and probably exit. If the startup is successful, you’ll see that, too:
19:45:52 Link manager (1694) started 12/26/00
19:45:52 parse_config_file: Successful configuration

If you telnet in from another machine as one of the ppp users, you should see something like the following:
[stew@omnibook stew]$ telnet curly-joe
Connected to curly-joe.
Escape character is '^]'.

SunOS 5.7

Welcome to AYSNET...
login: stew
Last login: Tue Dec 26 19:46:04 from moe
~ÿ}#À!}!L} }6}!}$}%Ü}#}$À#}%}&kGqr}'}"

This gibberish will continue, and you'll eventually be disconnected when you fail to complete the PAP authentication. This indicates that the ppp service is working as it should.

Arrange for another system to dial in to your Solaris system or, if you have two phone lines and modems, try it yourself. You should get the same display over a dial-up. Now we need to do something useful with it. If you wish to use the modem for dial-out as well as dial-in, the Kempston Web pages cover how you need to modify your scripts.

Linux client connection
This procedure outlines connecting with a Linux client running KDE using kppp. The technique would be similar for other UNIX variants and GUI dialers. You could also edit the pppd scripts by hand and accomplish the same result.

Open kppp, select Setup | New, and create a new connection:
Connection Name: Sun Box
Login ID: stew
Password: some_password
Phone Number: phone number for connection
Authentication: PAP
Store Password: checked
Edit pppd arguments: add the argument noipdefault
IP: Dynamic IP address
DNS: leave blank for now
Gateway: Default Gateway checked Assign the default route to this GW
Login Script:
Expect ogin:
Send stew
Expect: word:
Send: some_password

This should be it. Dial in to the Sun server and you should see the kppp modem light indicators in your taskbar. You should be able to ping and ftp to the server IP. Telnet will not work; you'll end up kicking off another ppp connection because we replaced the user's shell with aspppls. If you have trouble connecting, enable debugging in kppp and check /var/adm/log/asppp.log on the Solaris box.

Windows 9x client configuration
In Windows, create a new dial-up networking connection through Start | Programs | Accessories | Dial-Up Networking. Choose to make a new connection: Enter a name for the connection, the modem, and a phone number. Right-click the new connection and go to Properties, then make these settings:
  1. Set Type Of Dial-Up Server to PPP, Windows 95, Windows NT, Internet.
  2. Select Log On To Network.
  3. Select Enable Software Compression.
  4. Don’t select Require Encrypted Password.
  5. Don’t select NetBEUI.
  6. Don’t select IPX/SPX.
  7. Select TCP/IP.

Then make the following TCP/IP settings:
  1. Select Server Assigned IP Address.
  2. Select Use IP Header Compression.
  3. Select Use Default Gateway On Remote Host.

Under the Scripting tab, you'll again need a script to cover the UNIX login sequence. You can save the following listing under C:\Program Files\Accessories\Hyperterminal as Solaris.scp and enter that as the script file. Also, check Start Terminal Screen Minimized.
;simple Solaris dialup script
;12/28/2000 S. Benedict

proc main

; Change these variables to customize for your
; specific Internet service provider.

integer nTries = 3

; These are the login prompt and timeout values

string szLogin = "login:"
integer nLoginTimeout = 3

; These are the password prompt and timeout values

string szPW = "password:"
integer nPWTimeout = 3

; Attempt to log in at most 'nTries' times

while 0 < nTries do

; Wait for the login prompt before entering
; the user ID, timeout after x seconds

waitfor szLogin then DoLogin
until nLoginTimeout

transmit "^M"  ; ping
nTries = nTries - 1


goto BailOut

; Enter user ID

transmit $USERID, raw
transmit "^M"

; Wait for the password prompt

waitfor szPW until nPWTimeout
if FALSE == $SUCCESS then
goto TryAgain

; Send the password

transmit $PASSWORD, raw
transmit "^M"

goto Done

; Something isn't responding. Halt the script
; and let the user handle it manually.

set screen keyboard on



There are also settings for DNS, but we haven't covered setting that up yet in Solaris, so we'll leave it for now. Click OK, then double-click the icon to dial. Enter the username and password and select Save Password.

Windows users should probably add an entry in the Hosts file in C:\Windows for the dial-up server:  dialup_server

They may also need to add an entry with the hostname and IP address that the Samba services are using in LMHosts:  curly-joe

It has been my experience that browsing Network Neighborhood can be erratic over a dial-up connection. Users should be able to connect to the Samba shares either from the command line, as shown here:
net use s: \\curly-joe\stew
net use p: \\curly-joe\public

or from Windows Explorer, using the Connect Network Drive command under the Tools menu.

Macintosh client connection
The connection setup for Macintosh is much the same as for the other operating systems. MacOS, at least System 8.6 on my iMac, seems to be unable to maintain two TCP/IP connections, with both a dial-up and the local network. I'll leave it to the Mac experts to reveal how to do that.

First off, open the TCP/IP Control Panel and create a configuration as follows:
Connect Via: PPP
Configure:  Using PPP Server

The remaining options can be left blank.

Now, create a remote-access configuration. Start by duplicating the default and editing as follows:
Registered User:  selected
Name: username on dialup (in this case, stew)
Password: password on dialup
Save Password: selected
Number: phone number of dialup server

Under Options:

Redialing: set as desired
Connection: set as desired

Use Protocol: PPP
Connect Automatically: set as desired
Use TCP header compression: selected
Connect to command-line host: selected

Initially, you will select Use Terminal Window and record and save the login sequence. You can do this once and make it available to your Mac users. After the script is created, import the script and select Use Connect Script. The login sequence will be a typical UNIX login, with a prompt for the username and password. After that, control is passed to aspppd with the username as the path parameter. The script I recorded follows:
MATCHSTR 1 11 "login: "
NOTE "Connect script couldn't match \34login: \34" 3
IFSTR 11 12 "<Guest>"
IFSTR 11 12 ""
WRITE "^u\13"
ASK 0 "Please enter name: "
WRITE "^*\13"
MATCHSTR 1 14 "Password: "
NOTE "Connect script couldn't match \34Password: \34" 3
IFSTR 12 15 ""
WRITE "^p\13"
ASK 1 "Please enter password: "
WRITE "^*\13"
MATCHSTR 1 90 "/a\13\10"
NOTE "Connect script couldn't match \34/a\13\10\34" 3
EXIT -6002 "Connection script failed."

Once you are connected, you can use the Chooser as before to access the netatalk shares as well as to access the server via ftp and the Web server using a browser.

That about does it. We now have a dial-up server providing normal Internet-style ftp and Web services, as well as native network file services for Windows and Macintosh clients. We could expand these concepts and provide NFS file services to the other UNIX clients and possibly DNS and Internet gateway services to the greater Internet. Telnet access to the machine is prohibited since we replaced the user's shell with aspppls, so we don't have that issue to deal with. We didn't cover the configuration in this Daily Drill Down, but we could open up e-mail access to the server, plus we have our groupware application running on the Web server, which all the clients can access with their browsers. Additional modems could allow us to support multiple users simultaneously. Perhaps we'll cover some of these other possibilities in our next Solaris Daily Drill Down.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks