Very Computer

Man. . .This seems like it is going to go on forever.

Well, I've configured the proper files, I've contacted my ISP to find out
whether it uses PAP or CHAP, set that stuff up, and I am still running
into trouble.

The problems come when I invoke pppd to connect to the remote host. Now,
let's assume that my user name is "James Fannin", my password is "passwd",
and the ISP's number is "5555555".

I type:
/usr/sbin/pppd /dev/ttyS1 57600 debug user James Fannin connect
"/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: James Fannin assword:
passwd"

This does not work; it prints the pppd help stuff, suggesting I improperly
typed something. I suspect this is because my user name has a space in it,
although I am not certain. When I type only one word in front of "user" my
modem fires up, tries to connect, and I get dropped, which kind of
confirms this theory. Any suggestions or guidance?

I had assumed that this PAP thang with the space was causing my problems,
although it evidently was not; I still cannot connect. I realize that this
subject has been discussed extensively in this newsgroup and even more
extensively on the internet, however I have traversed both to no avail. I
have read the HOW-TOs and messages on the subject and abided by the
instructions, yet I cannot get this foul beast to work. I realize the more
experienced denizens of these newsgroups are surely weary of this stuff,
but please bear with me.

It is my understanding that the following must be done in order to
configure ppp. If I am incorrect at some point, please point it out. . . .

1. Edit resolv.conf and put in your ISP domain name and then your ISP's
Domain Name Server
2. Edit /etc/hosts.conf and make sure it contains the text "order hosts,
bind multi on".
3. Edit /etc/ppp/options so it contains "lock crtscts defaultroute"
4. Find out if your ISP uses PAP, CHAP, or neither.
5. In the case of CHAP or PAP, go into /etc/ppp/pap-secrets (or,
alternatively, CHAP secrets) and type "  'your usename' * 'your password'
*   "
6. And then, finally, invoke the beast that is PPPd and attempt to connect
to the remote hose by typing
"  /usr/sbin/pppd /dev/ttyS1 57600 user 'your username' connect
"/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: 'your username' assword:
'your password'"
7. Pray to God
8. Test your connection by using some sort of internet program or wait a
minute or two to see if your modem gives off the telltale Click of
Disconnection (it strikes terror into my heart).

I was able to finally and thankfully get pppd to work. Thanks every for
your help.

In the end, it turned out that the instructions I previously mentioned
(coupled with the corrections from the other posters) were rather sound.
It appears that I myself had not properly followed them. My problems
evidently resulted from my two word username, which was easily remidied by
placing single quotes (apostraphes) around it in my PAP file and in my
actual invocation of PPPD.

In any case, for those of you who still suffer from pppd woes, I highly
reccomend Mr. Unruh's site "How to Hook up pppd in Linux" at
http://azrael.dyn.cheapnet.net/forum. I found it to be exceedingly
helpful.

  Use the scripts.  Look in the directory /usr/doc/ppp-*.*.*/scripts and
you'll find a few demo scripts.  Copy ppp-on, ppp-off, and ppp-on-dialer
into the /etc directory.  Edit ppp-on.  All you need to change is the stuff
at the very top, just the telephone number, account name, and password.  Add
/etc to your path, and you should be laughing.  I gave a painfully long
account of how to do this, including the permissions and setuids that you
need for non-root users to use ppp, a while back.  Deja-news could probably
find it.  Mind you, *I* could probably find it on my server if I dug around.
If you have trouble, I'll look it up.

Quote:>This does not work; it prints the pppd help stuff, suggesting I improperly
>typed something. I suspect this is because my user name has a space in it,
>although I am not certain. When I type only one word in front of "user" my
>modem fires up, tries to connect, and I get dropped, which kind of
>confirms this theory. Any suggestions or guidance?

  The most irritating thing about unix in general is that it has been around
so long in the hands of computer geeks that there is now 18 different ways
to do everything.  So you grab one HOWTO file and it says to do this with
these files and it should work.  It doesn't, so you grab another HOWTO and
it says to do a totally different thing with totally different files and
somehow that's going to achieve the same end.  It drives me nuts.  All I
know is that the ppp scripts in /usr/doc/ppp-*.*.*/scripts work for me with
very minimal screwing around.

--

Caledon, Ontario, Canada (just NW of Toronto).

Raiser of animals.  Weldor of metals.  Driver of off-road vehicles.
Writer of FAQs.  Keeper of the faith, and all around okay guy.

<http://www.beeline.ca/personal/mike>

  Doh!  I meant /etc/ppp.  In supplication for this error, I have dug
through my server and found the original message that I alluded to, and it's
reproduced below.

----------

  I'm a relatively new linux user.  I used it a long time ago in the pre 1.0
days, when ole' Linus was pumping out kernels at a rate of about 3 per day
8-)  but I'm really not a unix expert.  However, I will tell you how I
solve problems like this in RedHat, and maybe it will help.
  Some of this information is very basic.  Please don't be insulted; I just
decided to spell it all out so that any newbies listening might be helped in
the right direction.
  First, do an "rpm -q ppp".  In my case it shows that I'm runing
ppp-2.3.3-4.  Since it showed a response, I know that that's what the
package is called. It didn't say "package <whatever> is not installed".
  So now I do an "rpm -ql ppp |less".  This lists all of the files that came
in the RPM package.  This shows me where the documentation is stored, and
where all of the executables are stores.  I do this so that I know what all
of the executables are called so that I can do "man <suchandsuch>" to get a
quick low-down on what each of them do.  In this case I see three
executables, all in /usr/sbin.  They are chat, pppd, and pppstats.  A quick
'man' of each executable tells me that chat is used to talk to the modem,
pppd is the resident daemon which stays active while you are using ppp, and
pppstats just prints out the statistics.
  Now that I have a vague handle on how the application works, I look at the
documentation.  To be honest, I found the documentation rather hard to
grasp.
  One thing that I didn't pick up from the documentation is that all of the
script files that you normally use, namely ppp-on and ppp-off and
ppp-on-dialer, are not installed.  They are sitting in the /scripts
directory of the ppp documentation directory where you can't really use
them.  The documentation said you needed these files.  When I typed "whereis
ppp-on" I didn't get an answer.  So I ran "rpm -ql ppp |less" again and
looked a little harder, and there they were in that scripts directory.
  So I logged in as root and copied the three scripts into my /etc/ppp
directory.  The only one you should need to edit is the ppp-on script.  I
has a location for your account name, and password, and the telephone number
of your ISP.  That is all you should have to worry about.
  Now, if you were only using PPP as root, then you would be pretty much
done.  I'm not a security stickler, and I don't much care if I have stuff
lying around with universal privilege, but I won't claim that my
laissez-faire attitude to security is the *right* attitude.  This is how I
set up my ppp permissions so that I could use it from my normal operating
account.  The less security-inept out there might have a better way to do
it, but this way works, but it assumes that you have already copied
/usr/doc/ppp-<version>/scripts/ppp* to /etc/ppp:
  login as root
  edit /etc/profile and add /etc/ppp to the execution path
  cd /etc/ppp
  chmod 755 ppp*   <- this sets permission to execute the scripts
  chmod 6755 /usr/sbin/pppd  <- this actives the set user ID bits.  This is
                                the part that a lot of security-conscious
                                people would probably worry about.
  chmod 755 /usr/sbin/chat  <-  chat doesn't need the set user ID bits set
                                because it is run by pppd which has
                                root access.

 After doing this, and logging out and back in to update your path
environment variable, you should be able to type 'ppp-on' to activate the
link to your ISP.  You'll hear the modem start dialing unless you've set it
with ATM0 or L0 or whichever that one is that shuts off the speaker.
Anyway, just type ppp-off to shut it down.

  Hope this helps.

-------------

--

Caledon, Ontario, Canada (just NW of Toronto).

Raiser of animals.  Weldor of metals.  Driver of off-road vehicles.
Writer of FAQs.  Keeper of the faith, and all around okay guy.

<http://www.beeline.ca/personal/mike>

Quote:> Man. . .This seems like it is going to go on forever.

> Well, I've configured the proper files, I've contacted my ISP to find out
> whether it uses PAP or CHAP, set that stuff up, and I am still running
> into trouble.

> The problems come when I invoke pppd to connect to the remote host. Now,
> let's assume that my user name is "James Fannin", my password is "passwd",
> and the ISP's number is "5555555".

> I type:
> /usr/sbin/pppd /dev/ttyS1 57600 debug user James Fannin connect
> "/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: James Fannin assword:
> passwd"

> This does not work; it prints the pppd help stuff, suggesting I improperly
> typed something. I suspect this is because my user name has a space in it,
> although I am not certain. When I type only one word in front of "user" my
> modem fires up, tries to connect, and I get dropped, which kind of
> confirms this theory. Any suggestions or guidance?

Typically, when a program requires a single parameter, and that parameter
contains white space, you can use quotes to make it a sigle argument. ie:

/usr/sbin/pppd /dev/ttyS1 57600 debug user "James Fannin" connect
"/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: James Fannin assword:
passwd"

Good Luck,
Kevin

The problem is that those are old scripts which assume that
authentication proceeds via logon. However many ISPs nowadays do not use
login authentication. They use PAP or CHAP, and those scripts do not do
much for that situation.So if you are lucky they work, if not you are
again left high and dry.

Quote:>>This does not work; it prints the pppd help stuff, suggesting I improperly
>>typed something. I suspect this is because my user name has a space in it,

Yes, that would be a problem. But if you enclose it in quotes (
/usr/sbin/pppd /dev/ttyS1 115200 user 'your user name' connect ....)
it should be OK.
Make sure that you use the same quotes in your pap or chap secrets file

'your user name'   * 'your password'  *

Quote:>know is that the ppp scripts in /usr/doc/ppp-*.*.*/scripts work for me with
>very minimal screwing around.

You were lucky you have an old fashioned ISP who uses login
authentication. The problem comes when even teh ISP does not know what
they use (Joe, who left three months ago, set it all up and wrote the
software to allow a Win95 box to connect. But nobody now knows or cares
what it was he did). There are systematic ways of finding out what to
do even without your ISPs help.
Some will actually use both login and pap or chap, and a few will use
Microsofts brand new non-standard version of chap (chap 81) in which
case you are really out of luck. The problem is that none of the
standard scripts cover all the bases. Each will work for some people and
not for others-- those for whom it works will swear by it, and those for
whom it does not will curse the world, not realising that it is their
ISP which is different. It was because of this that I wrote the page
http://axion.physics.ubc.ca/ppp-linux.html
to try to present a systematic attack on the problem.

A script which did what that page suggests would be nice, but not
trivial towrite. wvdial claims to do it, but I, and others, have not
been able to get it to work (I don;t know why). It is also a compiled
program, and altering how it works is non-trivial.

Quote:>Typically, when a program requires a single parameter, and that parameter
>contains white space, you can use quotes to make it a sigle argument. ie:
>/usr/sbin/pppd /dev/ttyS1 57600 debug user "James Fannin" connect \

"/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: James Fannin assword: passwd"
                                                  ^^^^^^^^^^^^
You had better put quotes around this as well-- 'James Fannin'
or it will send James after it receives ogin: and then expect Fannin,
which is liable never to happen.

The first few steps seemed ok, but what you should really do is try to
start the connection manually, using minicom, like it says in the
HOWTO. Based on what happens there, you should be able to make the
scripts without too much trouble.

If you still have trouble with ppp, make sure the debug switch is
activated (or that it's in the options file) so that you can check
/var/log/ppp.log for help. Likewise, when you're working on your chat
script, set the -v switch on it, so that info will go to the same
place. (make sure you turn both of these off when you're done though,
since they can sometimes make for some extensive log files, depending
on your setup.)
--

Jon-o Addleman

Quote:>The problem is that those are old scripts which assume that
>authentication proceeds via logon. However many ISPs nowadays do not use
>login authentication. They use PAP or CHAP, and those scripts do not do
>much for that situation.So if you are lucky they work, if not you are
>again left high and dry.

  Well, maybe I'm just lucky that my ISP doesn't use PAP or CHAP, or maybe
if they did then I would have had a working connection a lot sooner.  All I
know is that this works, and it's virtually the only thing that does.  I had
to set KPPP for login scripting as well; PAP only worked some of the time,
the login scripting works *every* time.  There's something to be said for
that.

Quote:>A script which did what that page suggests would be nice, but not
>trivial towrite. wvdial claims to do it, but I, and others, have not
>been able to get it to work (I don;t know why). It is also a compiled
>program, and altering how it works is non-trivial.

  As I've griped before, it annoys me that there are several ways to do
everything, instead of one right-and-proper-and-works way.  It seems that
every HOWTO and .doc you read has a different way of going about whatever it
is you're trying to do.  Very frustrating for the newbie.

--

Caledon, Ontario, Canada (just NW of Toronto).

Raiser of animals.  Weldor of metals.  Driver of off-road vehicles.
Writer of FAQs.  Keeper of the faith, and all around okay guy.

<http://www.beeline.ca/personal/mike>

  Or servers.  Many ISPs have multiple name servers.  I also added a search
line to mine, so that my resolv.conf looks like this:

domain headwaters.com
search headwaters.com
nameserver 209.135.75.2
nameserver 209.135.75.4

Quote:>2. Edit /etc/hosts.conf and make sure it contains the text "order hosts,
>bind multi on".

  I don't have a hosts.conf.  My ppp works.  I would have to assume that it
is not a mandatory file.

Quote:>3. Edit /etc/ppp/options so it contains "lock crtscts defaultroute"

  I don't have an /etc/ppp/options, either.

Quote:>4. Find out if your ISP uses PAP, CHAP, or neither.

  I have pap-secrets and chap-secrets, but they're empty; assumably my ISP
doesn't use pap or chap.

Quote:>6. And then, finally, invoke the beast that is PPPd and attempt to connect
>to the remote hose by typing
>"  /usr/sbin/pppd /dev/ttyS1 57600 user 'your username' connect
>"/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: 'your username' assword:
>'your password'"

  I just type "ppp-on" and I'm done.  "ppp-off" to close the connection.

Quote:>7. Pray to God
>8. Test your connection by using some sort of internet program or wait a
>minute or two to see if your modem gives off the telltale Click of
>Disconnection (it strikes terror into my heart).

  Use "ping <nameserver>" from the console prompt for testing.  In my case I
use "ping 209.135.75.2", but of course you would have a different
nameserver.

--

Caledon, Ontario, Canada (just NW of Toronto).

Raiser of animals.  Weldor of metals.  Driver of off-road vehicles.
Writer of FAQs.  Keeper of the faith, and all around okay guy.

<http://www.beeline.ca/personal/mike>

Quote:>It is my understanding that the following must be done in order to
>configure ppp. If I am incorrect at some point, please point it out. . . .
>1. Edit resolv.conf and put in your ISP domain name and then your ISP's
>Domain Name Server
>2. Edit /etc/hosts.conf and make sure it contains the text "order hosts,
>bind multi on".

That is /etc/host.conf, not /etc/hosts.conf

Quote:>3. Edit /etc/ppp/options so it contains "lock crtscts defaultroute"
>4. Find out if your ISP uses PAP, CHAP, or neither.

Actually you can find out for yourself, especially as the ISP help line
may not know what you are talking about.

Quote:>5. In the case of CHAP or PAP, go into /etc/ppp/pap-secrets (or,
>alternatively, CHAP secrets) and type "  'your usename' * 'your password'
>*   "

No " " around the whole thing.

Quote:>6. And then, finally, invoke the beast that is PPPd and attempt to connect
>to the remote hose by typing
>"  /usr/sbin/pppd /dev/ttyS1 57600 user 'your username' connect
>"/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: 'your username' assword:
>'your password'"

Uh, no. You are mixing both login authentication and pap/chap
authentication. Usually (although not always) it is one or the other,
not both. Also, no " at the beginning of the line
 ( ie not " /usr/sbin/pppd ...... )

Quote:>7. Pray to God
>8. Test your connection by using some sort of internet program or wait a
>minute or two to see if your modem gives off the telltale Click of
>Disconnection (it strikes terror into my heart).

Roughly right.But of course the devil is in the details.

Try reading
axion.physics.ubc.ca/ppp-linux.html

Quote:>The first few steps seemed ok, but what you should really do is try to
>start the connection manually, using minicom, like it says in the
>HOWTO. Based on what happens there, you should be able to make the
>scripts without too much trouble.

Actually no. This was true when most ISPs used login authentication, but
is not true today when many use PAP/CHAP -- eg AutoPPP under mgetty.
The minicom login will in fact lead you astray. Many isps will present a
login screen but when you try to use it is does nothing. It is of use
only for the sysadmins, not plebs like you or me. We are to use PAP/CHAP
right after the CONNECT message.

Yes, you are lucky. I have seen a number of ISPs where it seems you
canlogin, but you cannot. You are left in a limbo if you try. They want
PAP CHAP right after the CONNECT message. In fact Linux with mgetty and
AutoPPP works exactly like that. If youtry to login to a Linux box using
AutoPPP there is a very ood chance you will be out of luck.

The ISPs right now are in transition. Win supports PAP CHAP as the
default, and most ISPs are switching over. Sometimes they have an
intermediate scheme where both work, but then they suddenly pull the
plug on login authentication, and leave people in the lurch.

Quote:>  As I've griped before, it annoys me that there are several ways to do
>everything, instead of one right-and-proper-and-works way.  It seems that

I'm sorry, what is the "right and proper" way? Every ISP uses a
different authentication scheme. I have seen one who demanded both login
authentication and then after that PAP authentication. Until all the
ISPs in the world get together and decide on one way of authenticating
(not likely to happen soon. Microsoft for example is threatening to
introduce still another completely incompatible scheme), there simply is
no "right and proper" way.

My page was an attempt to give a logical and consistant way of stepping
through all the options to see which one worked. If you have a shortcut
which worked for your ISP, that is great. However, I assure you your
scheme will NOT work for all ISPs.

Quote:>every HOWTO and .doc you read has a different way of going about whatever it
>is you're trying to do.  Very frustrating for the newbie.

I agree. And the problem is that most of those HOWTOs were written a
couple of years ago when login authentication was almost universal. That
has changed. Now many use PAP or CHAP05 or CHAP 80 (or even CHAP81--
Microsofts latest stupidity). And often they do not know themselves what
they use. Probably someone did once, but they have left the
organisation. Or they simply follow some directions they got from MS (or
from mgetty) on how to set up their system, and have little idea what
they are actually doing. So the linux user, who cannot simply download
or be given some incomprehensible package to log onto the ISP as the
Win9x user can, has to figure out what the ISP is doing in order to log on.

Most of the scripts and the HOWTOs make assumptions about what the ISP
wants (or tell the user to find out by asking the ISP what they want-- a
silly suggestion since most ISPs do not know), and for ISPs for whom the
assumptions are right, the scripts are great and work well. For the
others, they do not work, and intense frustration results.

That frustration grows when they are told in newsgroups to use script X
or Y or Z, and when they try it fails for their ISP.