Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. (Helen Keller)
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
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
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
The next step is to get your ISP's name into the
# sample entry
world Any ACU 38400 16177399753 ogin: xyz/rppp sword: xyzxyzxx
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
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
Device Type ACU wanted
mlock tty1A succeeded
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
device status for fd=5
F_GETFL=2, iflag=`12005', oflag=`0', cflag=`62277', lflag=`0', line=`0'
cc=`177', =`34', =`10', =`25', =`1', =`0', =`377', =`377'
Welcome to The World (2-a slot:1/mod:4)
Trying 126.96.36.199 ...
Connected to 188.8.131.52.
IRIX System V.4 (world)
Welcome to The World - To create an account login as new, no 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: firstname.lastname@example.org
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'
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
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
By the way, if you are not using PAP or CHAP, you are
going to see messages in /var/adm/syslog saying things
Jul 23 17:44:25 scobox pppd: can't get passwd for local host
Jul 23 17:44:25 scobox pppd: getppphostent: no local host ID
These just mean that you aren't configured for that: they aren't
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
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"
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"
ifconfig ppp0 && route add default world.std.com
ifconfig ppp0 && exit 0
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.
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.
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?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
The 184.108.40.206 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 220.127.116.11. 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:
hostresorder local bind
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
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:
route add 10.1.36.3 127.0.0.1
if [ "$old_src" != "$new_src" ]
# change static ("S") routes which point to old_src and ifname
route add 10.1.36.3 127.0.0.1
route delete default
route add default $6
MST PPP has something similar called
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:
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
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".
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.
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)
Subject: Re: Manual dial-up PPP
Date: 9 Apr 1999 22:12:08 GMT
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
>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
18.104.22.168 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.
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.
From: Steve Fabac <email@example.com>
Subject: Re: HP Print servers over PPP connection
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.
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.