A Solaris Null-Modem PPP HOWTO

Charles Homan solaris[AT]homan.org

v1.0, 16 March 2003


This is a detailed guide to configuring two Solaris machines to speak PPP over a null-modem cable.

Introduction

I recently had to configure two Solaris machines to provide IP routing across a null-modem PPP cable. With some help from the kind folks on the Sun Managers Mailing List, I got the configuration working. A couple of the list members were kind enough to suggest that my summary of the solution might be worth posting on the Web. What you are reading is the result.

The procedure described was based on the following environment:

If your environment is different, YMMV. If you have any corrections or additions to this, please e-mail me at the above address.

Gotchas

Ah, the bad old days of aspppd! With PPP v4 the whole procedure is much simpler. However, there are a couple things which I ran into which will make this procedure difficult, if not impossible: flow control and cable wiring.


Flow Control

In Celeste's Tutorial on Solaris 2.x Modems and Terminals there is a phrase I missed on the first reading: "NEVER use software flow control with UUCP/PPP or the protocol will go nuts from the unexpected XON and XOFF characters". (It appears that there is an option in PPP 4.0 which accepts software flow control, but I didn't wind up using it.)

The Cable

The null-modem cable I was originally given was wired wrong. The guy who wired it swore it would work, but he was testing it on a PC. I couldn't even get a "tip" connection without using software flow control. His pinouts were:

Incorrect null-modem wiring, DB9-DB9
Side A Side B
Signal Pin Pin Signal
CD 1 1 CD
RD 2 3 TD
TD 3 2 RD
DTR 4 6 DSR
GND 5 5 GND
DSR 6 4 DTR
RTS 7 8 CTS
CTS 8 7 RTS

That is almost right. The proper wiring, as I eventually convinced him, is:

Proper null-modem wiring, DB9-DB9
Side A Side B
Signal Pin Pin Signal
CD
DSR
1
6
4 DTR
RD 2 3 TD
TD 3 2 RD
DTR 4 1
6
CD
DSR
GND 5 5 GND
RTS 7 8 CTS
CTS 8 7 RTS

See http://www.geocities.com/SiliconValley/Heights/5704/serial1.html (and other sites.) Once the cable was wired properly I could tip with hardware flow control turned on. Note that although the Sunblades I used have DB9 ports, you can use the same wiring (based on signal, not pin) to connect two DB25 ports, or a DB25 to a DB9. See Stokely Consulting's excellent Sun Serial Port & Cable Pinouts page for more info. That page has been an incredible amount of help to me over the years, especially since my adventures with serial ports are pretty rare...


Chat Script

Since my configuration is on a private network I could use "noauth", which effectively does away with the chat script.


Port Monitor

I removed the port monitor on ttya since it wasn't needed:

# pmadm -r -p zsmon -s ttya

(I'm not positive this is necessary, though.)


/etc/ppp/peers files

Since these machines will only ever connect to each other I could just use the /etc/ppp/options file for all of my connection info.


Files I used

The following files are what I used on machine1, with notes in italics indicating differences in the files on machine2, or providing other explanations about the line.

# cat /etc/ppp/options
cua/a
19200
crtscts
lock
passive
machine1-serial:machine2-serial (reversed on machine2)
logfile /var/adm/ppplog
noauth
persist
debug (just for debugging... ;-)

I used the file /etc/ppp/ifconfig to start pppd in preference to changing the default init script (/etc/init.d/pppd):

# cat /etc/ppp/ifconfig
pppd

For use in the options file (and for my convenience later) I defined names for the serial ports in /etc/hosts:

# cat /etc/hosts
111.22.33.44 machine1 (replaced with machine2's IP/name on machine2)
111.22.55.66 machine1-serial
111.22.55.77 machine2-serial

I used the file /etc/ppp/ip-up to initiate my routes:

# cat /etc/ppp/ip-up
#!/bin/sh
/usr/sbin/ndd -set /dev/ip ip_forwarding 1
/usr/sbin/route add 111.22.55.88/27 111.22.55.77 (/27 masked network, route through machine2-serial; different route and gateway on machine2, but the same principle)

(Note that I did *not* want defaultroute on my ppp line, as each machine is connected to networks that the other shouldn't necessarily know about. Also note that all IP addresses have been changed to generic numbers, so the network boundaries in the route command are almost certainly wrong here.)

With all of that in place, you will be able to boot the machines in either order. The first machine to come up attempts to initiate a connection. If (when) that fails, it simply waits passively for the other machine. When the second machine comes up, it attempts to initiate a connection which is accepted by the first machine, they both turn on IP forwarding and set up their routing tables.


The content of this page is copyright 2003 by Charles Homan. You may reproduce it for any non-commercial purpose only as long as credit is given. Reproduction for commercial purposes may only be made with prior written consent.