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
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.
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.
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.
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".
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'.
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.
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
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.
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.
This needed the direct serial port module loaded, since Windows 98 apparently did not by default.
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.
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.
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.
More Articles by Tony Lawrence © 2013-07-19 Tony Lawrence
The danger of computers becoming like humans is not as great as the danger of humans becoming like computers. (Konrad Zuse)
Printer Friendly Version
SCO_OSR5 PPP Setup Copyright © November 1998 Tony Lawrence
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
Printer Friendly Version