A.P. Lawrence

Quick PPP Setup

Oh my what we used to have to go through.

This references setting up ppp on ancient SCO Unix. Forunately few of us have to use ppp at all anymore, and if you do, surely you are using Linux.

Networking 101

Advanced TCP

Routing

CIDR

http://aplawrence.com/cgi-bin/ta.pl?109485

For Morningstar configuration see: http://www.caldera.com/ta

If you are having trouble getting a ppp link to an ISP working, the best thing to do is to drop back to basics and take it step by step. Obviously you want the most efficient and convenient setup eventually, but for starters, let's just get the thing working.

Editorial aside: This is something SCO should really pay more attention to. Configuring a simple link to an ISP is something stupid Win95 machines manage to do with nearly no effort and very high success rates. See /Unixart/ntvsunix.html if you don't mind listening to me whine and complain about this sort of thing.

If you can use the Scoadmin managers to get this working, great. If not, follow the manual instructions here. If you find that one of the managers has already done some of this, temporarily comment out what they did and try it this "ultra-basic" way first. You can always revisit the more complex scenarios after you get it working.

Remember also to have patience. After the modem connects, after "ifconfig" shows the link is up, it can sometimes take 5 to 20 seconds before you can telnet, ping or browse. Don't jump to the conclusion that it doesn't work too quickly.

The very first thing you need to do is get ppp into the kernel. None of this is there by default; you need to add it. Run "netconfig", and select "Hardware" (yeah, it's not hardware, but this is how it's done) ->Add New WAN Connection-> SCO TCP/IP PPP Driver. Tell it you want a manual outgoing connection, but don't get too wrapped up in the details because we're going to do it by hand further on here. What you want is to get the PPP drivers and config files added in, link a new kernel, and reboot.

After rebooting your modem needs to be able to dial out using cu. If you can get a more advanced dialer to work, great, but if not, drop back to dumb and simple: the "hayes1200" Dialers file. This is a dialer that really does nothing but dial the number: no initialization, no resets, nothing but dial. It goes into /usr/lib/uucp/Devices like this:

ACU tty2A - 38400 hayes1200 \D

The work you did in netconfig above may have already put something into Devices. For the moment, just comment it out with a "#" at the beginning of the line and try it the simple way first. Before proceeding, you need to be able to:

cu -x9 555-1212

(substitute your ISP's number above).

If this doesn't work, you need to find out why. Does the speed entry in Systems not match the ACU entry in Devices? Is the ACU entry correct? Does it start at the very beginning of the line? Is there another conflicting entry nearer the beginning? Is the phone number correct, and do you need anything like a "9" to access an outside line?

The next step is to get your ISP's name into the /usr/lib/uucp/Systems file.

# sample entry
world Any ACU 38400 16177399753 ogin: xxx/rppp sword: xxxxxxxx

This will include any post-login commands you might need to give to get ppp going on their end. For example, the ISP above offers slip, and two different ppp methods. The login above (actual login has been replaced with "xxx") chooses the "rppp" method (Real PPP) by appending "/rppp" to the login name. Different ISP's have different methods, or nothing may be required at all. Note that the speed (38400) matches the speed given for the ACU entry in Devices above. If the speed does not match, this will not work. You can use "Any" instead of 38400.

Again, if any Scoadmin Manager configuration you did has put entries in, examine them carefully and edit as needed.

At this point, you should be able to

cu -x9 ispname

and see a ppp session start. You'll need to login using the login and password that you put in the Systems file- the script there will not be executed when using "cu -x9".

# cu -x9 world
conn(world)
Device Type ACU wanted
lockname(/usr/spool/uucp/LCK..tty1a)
mlock tty1A succeeded
fixline(5, 38400)
processdev: calling setdevcfg(cu, ACU)
dialer args :/usr/lib/uucp/Courier_Dual_Standard_V-34_or_V-Everything:-x9:/dev/tty1A:16177399753:38400
hangup - timeout 15
Sent MODEM <<+++>>-OK
Sent MODEM <<ATQ0^M>>-OK
Sent MODEM <<ATH^M>>-OK
MODEM returned <<^M^JOK^M>>-OK
Sent MODEM <<AT&F1&B1&C1&D2E0Q0V1&A3S0=0&H1&R2&I0&M4^M>>-OK
MODEM returned <<^J^M^JOK^M>>-OK
Sent MODEM <<ATM0^M>>-OK
MODEM returned <<^J^M^JOK^M>>-OK
sending dial string
Sent MODEM <<ATDT16177399753^M>>-OK
wait for connect - timeout 157
MODEM returned <<^J^M^JCONNECT 49333/ARQ/V90/LAPM/V42BIS^M>>-CONNECT
Exit with 0
Forked 1435 Wait got 1435 Status 0
getto ret 5
ISTRIP cleared
device status for fd=5
F_GETFL=2, iflag=`12005', oflag=`0', cflag=`62277', lflag=`0', line=`0'
cc[0]=`177', [1]=`34', [2]=`10', [3]=`25', [4]=`1', [5]=`0', [6]=`377', [7]=`377'
call _mode(1)
Connected
_receive started

transmit started
Welcome to The World (2-a slot:1/mod:4)


Trying 199.172.62.5 ...
Connected to 199.172.62.5.


IRIX System V.4 (world)




Welcome to The World - To create an account login as new, no password


login: xxx/rppp
Password:
Note: You have to type this in. The "cu" does NOT use the chat information
from the systems file. That information WILL be used when the ppp connection
is made by ppp.
Last login: Thu Oct 29 06:58:48 from ppp0a012.std.com


Welcome to The World! A 16 x 250MHZ CPU SGI Challenge XL


**** all dialups now support V.90: see http://world.std.com or type 'modems'


(@) For a look at TODAY on the WORLD type 'help today'

(@) For customer assistance by mail: staff@world.std.com
By phone: 617-739-0202
By usenet: wstd.general and wstd.help
By yourself: type 'help' for online help area



To leave the system, use 'exit', 'logout', or control-d.
For information and PPP software to use with Netscape type 'worldweb'

starting PPP~}#!}!b} %}!}$}%}"}&} } } }}%}&} 3RB}'}"}(}"}1}$}%}3})}#}(} i }"m~~
}#!}!c} %}!}$}%}"}&} } }} }%}&} 3RB}'}"}(}"}1}$}%}3})}#}(} i }"m~~}#!}!d} %}!}$
}%}"}&} } }} }%}&}3RB}'}"}(}"}1}$}%}3})}#}(} i}"m "

That junk you see after "Starting PPP" is ppp. Your ISP may not say "Starting PPP"; it may not say anything at all, but that "junk" should appear on your screen. You do not have a ppp connection at this point!

Or more accurately, you have ppp running at the other end, but not at your end. This is simply testing to be sure that you can get a ppp session.

You'll need to "~." to end this. Press "~" and then "." to end the session. If it doesn't work, do it again. If that doesn't work, shutoff your modem.

You do have an external modem, right? Internal modems are a lousy idea, because sometimes the only way to unconfuse a modem is to shut it off. If it's in your machine, you have to shut off your machine to shut off the modem. Also, it's a lot easier to see the blinking lights on an external modem. Spend the extra money.

The use of "-x9" gives the information that will help you if this test is unsuccessful. For example, if it never dials your ISP, obviously that's your first problem! If the dialing is successful, but you don't see ppp starting, then you may need to talk to your ISP to find out why.

One reason might be that the ISP uses PAP or CHAP negotiation to authenticate you. If so, the manual tests above aren't going to work, and you'll need a slightly different configuration than what is described below. See "man pppauth".

By the way, if you are not using PAP or CHAP, you are going to see messages in /var/adm/syslog saying things like

Jul 23 17:44:25 scobox pppd[413]: can't get passwd for local host
Jul 23 17:44:25 scobox pppd[413]: getppphostent: no local host ID

Now you need to edit /etc/ppphosts for a manual ppp connection. We'll include a debug statement just in case, but you'll need to remember to take this out later.

0.0.0.0:0.0.0.0 attach=world uucp=world retry=4 conf=10 flow=rtscts debug=2 mask=255.255.255.0

Note that the netconfig may have already put an entry in. Again, comment it out or edit it down to simplicity. The entry above says that the ISP will be giving us an IP address and that the netmask is 255.255.255.0. It's possible that your ISP has assigned you a specific IP address; if so, use it.

Now we are are ready to try it. Type:

pppattach world

substituting "world" for the isp name you actually used. Your modem should dial, and after you see the transmit/recieve lights flash a bit, an "ifconfig ppp0" will show that the interface is up. Note that all that happens behind the scenes: you return to a "#" after typing "pppattach".

If you find you made a mistake in /etc/ppphosts, you need to signal the pppd to reread your configuration. That's done by sending a "kill -1" to the pppd daemons (there will be more than one; find them by "ps -e | grep pppd", and send the signal to the second one listed). If you are able to do so while testing, a "tcp stop" and "tcp start" may be easier for you.

Congratulations! You need some more work to get routing setup, but it works, and that lets you branch out to more complex configurations.

A note on routed:

The routed daemon starts by default from /etc/tcp. It will pick up RIP (Routing Information Protocol) packets from your ISP. Unfortunately, your ISP is broadcasting much more routing information than you probably need, so you'll quickly find you have dozens of routes. It may be better to shutoff routed by commenting it out of /etc/tcp. If you do that, you'll need to add your own routes as explained in the rest of this article.

Now some simple scripts to make this all work (these are unnecessary if you will ultimately be using a dynamic link):

First, the script that calls pppattach. This causes the modem to dial and ppp to start at this end. We remove uucp locks here just to avoid any leftover problems from a crash or other disconnection, but note that this system has only one modem, and this might not be appropriate on other systems.

# script "world" called from "up"
pppattach world

Next, the "up" script is used to call "world" and set default routes after the connection is made, It first calls "down" to flush existing routes. Again, be aware that this may not be appropriate for your system.

# script "up"- calls "down and "world"
down
/usr/bin/world
sleep 40
while true
do
ifconfig ppp0 && route add default world.std.com
ifconfig ppp0 && exit 0
sleep 5
done

The length of the "sleep" statements might need adjustment for your specific connection. Also see Replacing UUCP Mail for a modified version of this.

Finally, here's the "down" script referenced above. This is also used to bring down the connection when we're done with it.

#script "down"
ifconfig ppp0 down
route flush
route add 10.1.36.3 127.0.0.1

Now try "up". You should see or hear your modem dial, and after a few tries, you should see something like:

ppp0: flags=4071<UP,POINTOPOINT,WANTIOCTLS,RUNNING,MULTICAST> mtu 1500
inet 208.192.100.1 --> 192.74.137.5 netmask ffffff00
perf. params: recv size: 4096; send size: 8192; full-size frames: 1

If you do not, you'll see

ifconfig: ioctl (SIOCGIFFLAGS): no such interface

every five seconds, and it's time to go look at the debug log. On OSR5 that's in /var/adm/syslog, unless you have Internet Fast Start, which uses /usr/adm/pppd.log (UW7 uses /var/adm/logs/osmlog). Wherever the log is, PPP sessions go through various stages of negotiation, and the results (or failures) will be recorded there.

The details of interpreting this are well covered at http://aplawrence.com/cgi-bin/ta.pl?105424

Note that if you are using Morningstar PPP (this article does not cover Morningstar), the logs are different. See http://aplawrence.com/cgi-bin/ta.pl?109661

Problems at this stage are most likely negotiation issues: the remote end doesn't like something your end wants, or vice versa. SCO has a number of articles that might help you narrow this down; for example see: http://aplawrence.com/cgi-bin/ta.pl?107607

The above is a simple, functional ppp setup. It may be perfectly suitable for your needs. It is actually what I use on my home machine because I prefer manual control over the connection, and it is how I always set up new ppp connections at customer's sites, at least to begin with.

However, most people are going to want transparent (automatically brought up when a connection attempt is made) connections, will probably want to take advantage of higher baud rates, automatic setting of routes, etc. Or you just may have more complex needs due to the nature of your network. You may want to use Morningstar PPP or some other third party offering. The tools to set up such things are all there; this simple setup just gives you the knowledge and confidence that you can make more advanced setups if you need to.

If you need a dynamic setup, there's plenty to confuse you. One of SCO's TA's, for example, tells you that you can't have a transparent ppp without a fixed address from your ISP. That TA relates to 3.2v5.0.0 and has not been updated (as of March 1999). In fact, on 5.0.4 and up, you can have a dynamic transparent ppp setup. For example, to change the ppphosts entry described above to be transparent, it would look like:

192.74.137.5:10.0.2.15 flow=rtscts debug=0 idle=2 reqtmout=3 conf=5 term=2 nak=10 retry=2 mru=1500 accm=0 authtmout=1 mask=255.255.255.0 maxslot=16 uucp=world

The 192.74.137.5 is the address of the ISP; the 10.0.2.15 is just a place holder: when we actually connect, a different ip address will be assigned. All it takes for the link to be brought up is access to 192.74.137.5. Since that's also my DNS provider, any access off the local network is going to cause the link to dial out and connect.

Speaking of DNS, you are going to need to create /etc/resolv.conf (that's correct- no "e", just resolv.conf). This needs to contain something like:

domain mydomain.com
nameserver xxx.xxx.xxx.xxx
hostresorder local bind

You replace the xxx.xxx.xxx.xxx with whatever your ISP tells you to use for DNS- the domain entry doesn't matter unless your machine really is part of a domain; if it's just the one machine, it does not matter what you call it.

Note that changing ppphosts does NOT immedialy cause ppp to start acting differently. You need to send a "kill -1" signal to the primary pppd daemon or shotdown and restart tcp/ip for your changes to be noticed.

Also note that dynamic bringup doesn't always happen instantly. It will take a second or two before your modem even starts dialing.

To get the route control we had in the scripts above, we can add entries to /etc/ppphook.sh. This script gets called everytime the link goes up or down. My changes to that script look like this:

    down|add)
        route flush
        route add 10.1.36.3 127.0.0.1
        exit 0;;
    up|delete)
        if [ "$old_src" != "$new_src" ]
        then
            # change static ("S") routes which point to old_src and ifname
            route flush
            route add 10.1.36.3 127.0.0.1
            route delete default
            route add default $6
            ...

MST PPP has something similar called /usr/lib/mstppp/exec.dialout

Note that the commands above should be directed to a logfile or discarded if you don't want the results appearing on your console screen. On my personal system, I prefer that this happens; on a multiuser system you probably wouldn't.

Dynamic addresses from your ISP

If your ISP changes your address with each connection, you can do something like this:

ADDRESS="`ifconfig ppp0 | grep 'inet ' | awk '{print $2}' | sed -e 's/.*://'`"
route add default $ADDRESS

The ppphook.sh script is supposed to do this for you, but I've found that it doesn't always work quickly enough, so I tend to use this sort of hack anyway.

Dynamic bring-up and Visionfs

By default, Visionfs broadcasts on the network. This tends to keep your dynamic ppp up even if otherwise idle. The Visionfs server "scobox" can be modified using Profile Editor to disable naming (Profile Editor-Server-Edit->Properties->Advanced->Disable Naming). This will stop the broadcast, but it will now be impossible for any windows machine to access "scobox" unless they have persistent network drives mapped to it, or run "//scobox" from the File menus, and have an Lmhosts file referencing "scobox":

If the IP address of "scobox" was 10.1.36.3, you would need C:\WINDOWS\LMHOSTS to look like:

10.1.36.3       scobox  #PRE

Note that the file name is LMHOSTS, not LMHOSTS.TXT or LMHOSTS.SAM (that's a sample file that explains how LMHOSTS works). Watch that if you are using NOTEPAD or WORDPAD to create this.

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Phone and Email Support at Monthly rates

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here