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.

See also

Networking 101

Advanced TCP

Routing

CIDR

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 /Opinion/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:

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:

(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.

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 "xyz") 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

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".

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

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.

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:

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.

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.

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.

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

If you do not, you'll see

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 https://aplawrence.com/cgi-bin/ta.pl?arg=105424

Note that if you are using Morningstar PPP (this article does not cover Morningstar but SCO 5.0.7 includes a license for it), the logs are different. See https://aplawrence.com/cgi-bin/ta.pl?arg=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: https://aplawrence.com/cgi-bin/ta.pl?arg=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:

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:

You replace the xyz.xyz.xyz.xyz 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.

All packets are significant for pass

That was a warning message you might see from pppd.

My only comment would be this:

If you intended this as a warning (and yes, it is a worthwhile warning), why wouldn't you preface it with "WARN" or "WARNING" at the least?

Even better might be "WARNING - no packets are filtered".

Visionfs causes constant ppp connections

Early Visionfs had broken nsm* binaries. You could upgrade or download patches from SCO.

Morningstar PPP had the same issue. See Morning Star PPP - Stop Launch at boot:

1) /usr/lib/mstppp/Autostart - contains a line with the
parameters for the 'pppd' command. Each possible connection
starts with /usr/lib/mstppp/dialout plus parameters. Note
the '\' command is used to allow insertion of LF's to
promote readability. If the connection includes the 'up'
parameter - there's your answer. If the connection includes
the 'auto' parameter the dialout is a function of 2) below.

2) /usr/lib/mstppp/Filter file contains rules on
what packet types trigger dialout, are allowed to
traverse the interface, affect idleout timing, and
are logged. See man 'ppp.Filter'. Specify 'debug 1' in
/usr/lib/mstppp/Autostart and checking /usr/adm/pppd.log
will identify what packet type caused the 'bringup'.
 

Dynamic bringup of ppp loses first packet

The proposed workaround was to list the primary nameserver twice in /etc/resolv.conf. The cause is that he first DNS lookup caused PPP to bring up the connection, but then IP address was changed by the server you dialed into, and so the source address of that packet was wrong, and the answer gets lost on the way back.

PPP over serial (no modem)

I can remember setting up ppp like this over serial wiring inside one building - the old RS232 wiring was in place and they didn't want the expense of CAT5, so we did it this way.. a bit strange, but it worked.

The server runs the PPP daemon. The client logs into the server and starts a PPP session, creating an nstant network.

See How to manually configure SCO PPP for incoming/outgoing connections. and How to configure PPP for bi-directional dynamic bring up with OpenServer 5?.

This post covers some of that (although it's using a modem):

This is an interesting contrast between ease of use and control. I don't think the original poster was being at all unreasonable, but the idea of abandoning the automatic methods seemed to baffle the engineer at first.

Today's systems often exhibit similar feature lock-in and seldom give the user complete control of behavior. It's also somewhat rare to find a technical product manager willing to respond directly to posted problems on a public newsgroup, but it was a very different world back then.

	From: evanh@sco.COM (Evan Hunt)
	Newsgroups: comp.unix.sco.misc
	Subject: Re: Manual dial-up PPP
	Date: 9 Apr 1999 22:12:08 GMT
	References: <7eh97e$d81$4@towncrier.cc.monash.edu.au>
	
	
	Don't blame me, I voted for K.Lentin@cs.monash.edu.au.
	>Why leave my private passwords on my employer's machine?
	>
	>Why waste phone calls when a perfectly good serial link exists on which to
	>run ppp.
	>
	>[...]
	>We paid over $10,000 for this operating system and
	>it's pppd is either so stupid or so insane that it can't do something as
	>simple as start up and talk to a serial port? Either I'm wrong or the world
	>is very stuffed.
	
	I didn't say pppd couldn't do it, just that I didn't understand
	why you wanted it to.  It's designed to bring the link up silently
	when you request IP connectivity; I regard that as a good, useful
	design.  Wanting to manually dial the phone and type your password
	every time seems like a hassle, a feature few people would desire.
	The fact that you're the first person to ask for this feature in the
	three years I've been responsible for MSTPPP on SCO platforms, suggests
	that I may have been correct in that evaluation. :)
	
	I can think of two ways to do this.  Here's the simpler one:  Set
	up your modem so it doesn't hang up when it gets an EOF.  I forget
	how to do that, but there's an AT command sequence that allows it--
	perhaps someone else could help out here?
	
	Create a script called "startppp" on the remote side that runs pppd
	for you with all the necessary options.  Configure MSTPPP on the local
	side with no phone number, the specific name of the serial port you'll
	be using, and a chat script that just calls "startppp"--something like
	this:
	
	    1.2.3.4 Any tty1A 115200 N/A "" "" "" startppp
	
	When you want to start up a PPP link, you use kermit to connect to
	your modem and dial the phone.  Without logging out or entering
	"ATH", quit from kermit.  The modem should remain connected.  Run
	pppd with either the "dedicated" or "auto up" option, on that same
	serial port.  PPP should treat the modem as if it were a fixed serial
	link--connect, run "startppp", negotiate with the remote PPP daemon,
	and establish a link, without bothering to dial.
	
	I've never tested this, but I can't think why it wouldn't work.
	
	Here's the more complicated way:  Write a dialer program, based on
	atdialer.c in /usr/lib/uucp, which dials the modem for you.  When it
	connects, your program should pop up a terminal window so that you can
	log in.  AFter you've done so, you can close the window, and then your
	dialer program would pass control of the terminal back to the calling
	process, just as atdialer already does.
	
	Put your new dialer program into /usr/lib/uucp, and put its name
	into the first field of /usr/lib/mstppp/Devices.  MSTPPP will then
	call your program whenever it wants to dial the phone, so you'll get
	an opportunity to type your password.  The Systems file should look
	very much like the other one, except with "ACU" instead of "tty1A".
	
	-- 
	                  Evan Hunt   -   evanh at sco dot com
	
	

PPP hooks

I'd bet dollars to donuts that the "sh_hook" was a security hole.

Not that anyone is doing PPP on SCO any longer, of course.

At least I hope no one is..

Anyway, For SCO PPP, look for "sh_hook" in the man page for ppphosts. For Morningstar PPP, use the dialout and exec.dialout scripts created by Internet Manager.

Linux to sco ppp chap

SCO PPP could do CHAP, MSCHAP or PAP.

PAP is not encrypted, but that might not matter on a local network where you are giving the local machines access anyway.

Windows 98 ppp direct serial cable

This needed the direct serial port module loaded, since Windows 98 apparently did not by default.

PPP Routing

	From: Steve Fabac <smfabac@att.net>
	Newsgroups: comp.unix.sco.misc
	Subject: Re: HP Print servers over PPP connection
	References: <91tofi$134$1@slb6.atl.mindspring.net> 
	
	
	1) Each machine should be on a separate LAN: I.E. 192.168.1.X is one
	LAN. 192.168.2.X is another LAN. 
	
	2) the PPP link between the two machines is a THIRD LAN and must have
	a different network address than either of the two machine's LAN's:
	PPP-machine-one: 192.168.20.1 and PPP-machine-two: 192.168.20.2.
	
	Then your route table on machine one should have:
	192.168.2        192.168.20.1        UH         10     6680  ppp0
	
	And on machine 2:
	192.168.1        192.168.20.2        ...        ...     ..... PPP0
	
	Make sure that your print servers have the local machine's IP is set as
	the "gateway" for its network, and make sure that both machines are
	set to forward all packets. 
 

Incoming ppp logins

I cannot imagine why anyone would need this today, but if you do, be sure to see ettyaccts, atdialer, fax modem recognition also.

Sco's /etc/gettyacts defined what getty will see for various protocols. It would then not start up if it saw those strings.

What does "speed index 0" in ppd.log mean?

38,400 baud. Way back when, there was nothing above 19.2K, so that's tables stop. No big deal when higher rates came, except that older applications expected that there were no more than 16 possible speeds, all of which could be expressed as a 4 bit number. The upper bits stored other stuff, so it couldn't be changed. Since nobody used 0, 1 or 2, those were repurposed to mean the higher baud rates.. yep, really :-)

Before high speed internet, we were stuck with expensive T1's or slo-o-o-w modems. A 56K network was a heck of a lot better than a 38.4! For quite a few years, my High Speed Modems for SCO Unix (and other modem tips) was the most popular page here by far - I doubt it gets any hits at all now other than from search engines.

I can't imagine why you'd need this, but here is a post about PPP at 57600 on SCO Unix.

Got something to add? Send me email.

Have you tried Searching this site?

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.

Contact us