Giannis Mast/rgis wrote:
>
> I have a problem with my MOTOROLA MC 143450 RDK MODEM.
> I am calling to an ISP and i can get in i'm writing the username and
> password and i choose PPP protocol for my internet connection . After then i
> get lots of unknown words like "@#%&)&#^$%&^$" and my connection breaks
Hi Giannis,
I did not find this easy either I have attached a How To which may
help you do EXACTLY what it says and you have a good chance of sucess.
It may be necessary to check with your ISP that they support PPP.
Regards,
Colin Close
Greetings From Cold, Wet England.
Title: How to Hook up PPP in Linux
How to hook up PPP
in Linux
W.G. Unruh
[EMAIL PROTECTED]
or as an HTML version at http://axion.physics.ubc.ca/ppp-linux.html
This document is copyright W. Unruh. It may be copied freely as a whole for non-commercial purposes, but must retain the indication of authorship. If you want to include it in a collection for sale, please contact the author. Furthermore, any alterations must have the permission of the author.
Reason for Document
The key problem in hooking up a PPP link to an Internet Service Provider (ISP) is that the ISP's seem to compete with each other as to who can find another obscure way of authenticating users. Thus we have login, PAP, CHAP 05, CHAP80, CHAP80-lanman, CHAP81, ... and combinations of these. The chief difficulty of connecting to an ISP is discovering which technique is actually being used by the ISP in an orderly way. Since few of them know anything about Linux, and since few of them even understand what technique they actually use, this procedure should allow you to set up without their help, or to understand what their help means if it is given.
The following has a number of steps to connecting to your ISP. The temptation is to skip steps. This is a bad idea, as it will almost certainly lead to grief. Do each step and you will succeed, and you will also learn something about your system in the process.
These instructions were developed with the 2.0.x versions of the Linux kernels, But they also appear to work with the 2.2.x series of kernels as well. Similarly, they were developed on ppp version 2.3.3, but appear to work with the newer versions of ppp as well. In fact some of the features below only work with later versions of pppd. You can get the latest pppd from ftp://linuxcare.com.au/pub/pppor ftp://cs.anu.edu.au/pub/software/ppp/
INDEX
- Initial Setup
- What does ISP Want?
- Testing Connection
- Various Possible Problems
- Automation
- Stopping PPP
Initial Setup
For much of this document, the steps are essentially independent of your ISP.
Many ISPs do not know their own systems, and their advice must often be taken
with a grain of salt. Thus, the document below shows you how to find out what
your ISP wants, independent of what your ISP says he wants. However, for the
first step you cannot do without your ISP. You must get a username and a
password from your ISP-- which usually means that you must open an account with
them and pay your money. It is worth asking them to make sure that they tell you
exactly what form that user name must take when you sign on. For example some of
them demand that you use your full email address with them as your username,
rather than simply the name itself. Others demand additional additions to the
bare username. Try to get them to be as specific as possible about exactly what
you need to use.
You also need to get the ISP's Domain Name Server (DNS-IP)
address. (This is an address in Internet Protocol (IP) format, which is four
numbers each less than 256 separated by dots (eg 137.82.43.58).) Often they will
give you more than one. Occasionally an ISP will refuse. In that case they may
supply the DNS dynamically instead. Using ppp version greater than 2.3.7 will
allow you still to sign on with them as described below.
Having that
information, log on as root (use root as the user name when you log on), or,
after you have logged on as a user, run
su
and enter your root
password at the prompt.)
Modem
Make sure that you know which port your modem is on. The two programs at modem-chk.html can help you to determine which port your modem is on. COM1 (serial port 1) is /dev/ttyS0. COM2 is /dev/ttyS1, etc. In the following I will assume /dev/ttyS1. Change for your situation. It is preferable to use the ttyS ports rather than the cua ports or the modem port. The cua ports will disappear in future releases of Linux, and the /dev/modem port hides what you are actually doing and can lead to conflicts with other programs which use the serial ports.[Note that if your modem is a winmodem, it will not work under Linux. --Hewever see http://www.linmodems.org/--- It is probably a winmodem if it is a PCI modem, less so if it is an ISA and improbable if it is an external modem (but USB external modems at present do not work). It is also improbable if it is not a 56K modem.]
See http://www.o2.net/~gromitkc/winmodem.htmlfor
a listing of known winmodems.
For some advice on buying modems for Linux,
see
http://www.math.sunysb.edu/~comech/tools/CheapBox.html#modem]
Message Logging
In order to figure out what is happening while you
are trying to log on to your ISP, you must turn on debugging and log the debug
messages to some file. The key programs are pppd, and a program it uses, called
chat. We will store those debugging messages in a file called /var/log/ppp. (You
can use any file you wish, including /var/log/messages. Some distributions are
now installing a directory called /var/log/ppp (Eg, The Corel distribution does
this). If yours does, you must use a different name, eg, /var/log/ppplog. Use
that name instead everywhere this document talks about /var/log/ppp.)
In order that your system will record the debugging information from both
these programs, do the following:
cp /etc/syslog.conf
/etc/syslog.conf.orig
to make sure you have a copy of a good version in
case you mess up the next command. If you have trouble, copy back the original
version.
Edit /etc/syslog.conf and add the lines
local2.* /var/log/ppp daemon.* /var/log/ppp(Some versions of syslogd (eg on SunOS) demand that those be tabs not spaces between the two parts on each line. Some editors refuse to insert tabs and convert them to spaces. The syslogd shipped with most recent distributions of Linux do not seem to care, but Be warned.)
Then, to tell syslogd to actually log the information, do
killall -1
syslogd
Resolver Information
The computers on the internet are referenced by
numbers called IP numbers. However, people, being bad at remembering numbers,
use names instead (eg, axion.physics.ubc.ca instead of 142.103.234.16). The name
resolver is a program that asks another computer, the nameserver, to translate
internet names to IP numbers which your computer can actually use. In order
that, once you are connected, you are able to actually resolve host names,
edit /etc/resolv.conf and add a line (or lines) like
nameserver
111.222.333.444
Instead of 111.222.333.444 use the Domain Name Server IP
address (DNS-IPaddress) which your ISP gave you. If they gave you two numbers
enter another nameserver line with the second address.
It can also be useful
to include a line line
domain ISP.domain.name
where
ISP.domain.name is the domain name of your ISP. For example, my /etc/resolv.conf
file looks like
domain physics.ubc.ca nameserver 137.82.43.9 nameserver 137.82.1.1[Note: Do NOT put leading zeros on any of those numbers. They will not work. 137.082.43.9 is a different number from 137.82.43.9]
Edit /etc/host.conf and make sure the line
order hosts, bind
is in there.
Also check /etc/nsswitch.conf and make sure a line like
hosts: files dns
is there. (that line may also contain other
options like nis, which will do no harm)
Also make sure that all of these files are readable by everyone.
chmod
a+r /etc/resolv.conf /etc/host.conf /etc/nsswitch.conf
No Default Route
Your computer passes messages for addresses it does
not know to the default route. ppp assumes that there can only be one default
route on any system. This is almost always the route to ISP's computer. However,
if pppd finds that a default route already exists, it will not set up one to
your ISP, causing problems (nothing gets through). In order that you not have
any conflicts between the routing across ppp and onto some network you have, run
/sbin/route -n
(or you can also run
/bin/netstat -nr
which does the same thing)
while not connected via ppp, and look for a
default entry. (First entry in line is 0.0.0.0). This almost certainly should
not be there. (Unless you already have a hookup to the internet via an ethernet
connection, you do not want such a default route.) Unless you know that your
computer has an ethernet connection to other computers already, the only thing
there should be a route to 127.0.0.1 or 127.0.0.0 If there is such a default
route (line starting with 0.0.0.0), and you want the ppp interface to be your
default route, (the usual situation), run
/sbin/route del default
Also find out what was setting that wrong default route, and stop it from
doing so. (If you cannot figure out what is doing so, put that line
/sbin/route del default
at the end of whichever of /etc/rc.local
or /etc/rc.d/rc.local exists on your system.)
PPPD module support
Now check to see if the module support for ppp
is set up properly. Run
/usr/sbin/pppd
You should get a line of
garbage which repeats about 10 times and then the command exits. This is good.
Skip to the PPPD Options section.
If you get nothing and the command return
to the prompt after a few seconds, this is probably OK as well, but try
/usr/sbin/pppd `tty`
where those are backward apostrophes (under
the ~ on the US keyboard). This should give you the lines of garbage. If you do
get this line of garbage, skip the next section. If you do not get that line of
garbage, it is probable that the module support is not set up properly.
Setting up module support
If you did not get that line of garbage, but instead get "permission denied", you are not running as root. Log on as root and try again.If you get a message saying that your kernel does not support ppp, do not recompile the kernel. This error message is a grab bag error message which the pppd program produces almost anytime something goes wrong. What it almost certainly means in the 2.0.x series of kernels is that you are not running kerneld.
To test if kerneld is running, run the command
ps aux|grep kerneld|grep -v grep
It will produce output if kerneld is running. If kerneld is running (or you have the 2.2.x kernels which use kmod instead) and you get this error message, try doing
insmod slhc
insmod ppp
and try again. ( these load the modules permanently and you may have to put those lines into the file rc.local (/etc/rc.d/rc.local on RedHat and in various places under /etc on other distributions)
(If none of this works, then there are more severe problems that this note cannot solve.)
Assuming that you find that kerneld is not running, then on a Redhat system, run
/etc/rc.d/init.d/kerneld start
or even just
/sbin/kerneld
(which should work on any Linux system).
[ If kerneld was not running, you will need to make sure that it is set to
run each time you switch on your system. Unfortunately every distribution has a
slightly different way of starting up daemons at bootup. In Redhat, also make
sure that there are lines like S01kerneld as links to /etc/rc.d/init.d/kerneld
in each of the directories /etc/rc.d/rc1.d to /etc/rc.d/rc5.d in RedHat. On
other systems, you may need to put a line like
/sbin/kerneld
into
/etc/rc.local, or /etc/rc.d/rc.local, or ....]
Hostname
One final item, especially for Redhat systems, make sure
that your give your machine a name (any single word name you want). You can set
it with
hostname <yourhostname>
But you also want to change
it permanently. In Redhat/Mandrake, put the line
HOSTNAME=<yourhostname>
into /etc/sysconfig/network. On
other systems I am not sure, but you could always put the hostname command at
the end of your rc.local file. This is not essential to running ppp, but if you
do not do it, you will find yourself unable to run any X application while
running ppp.
PPP Options
You have now set up the critical files on your system and you know that you
have a an operational pppd. You now need to set up the ppp options so that you
can get debugging information when you try to connect, and so that it is
minimally usable.
Edit /etc/ppp/options so it contains
lock
crtscts
defaultroute
noauth
[note that if
you are in the unlikely situation that you already have a working default route
to an ethernet, omit the defaultroute option. If you are not sure, put
that option in.]
[Also other options can be used. In general do not do so
unless advised to do so. More harm is done by putting in too many un-understood
options than by putting in too few. If you have a local ethernet, and if your
ISP demands that they assign your IP address for the ppp connection, then also
use
noipdefault
You could also put in a line containing
debug here but we will use it explicitly on the command line.]
Figuring out how your ISP wants to log you on
In a separate window set up a running tally of the entries to the log file
with
tail -f /var/log/ppp
This will report in the window what is
logged to the /var/log/ppp file as it is logged. It sometimes scrolls by too
fast to see-- then use the window bar to scroll back in the output. We are now
going to systematically go through the options to find out what your ISP wants.
During these experiments you may occasionally find that your pppd has not died
(or you want to kill it). Just do
killall pppd
to kill it.
Occasionally pppd will leave a lock file behind if it has been killed. If this
is the case, do
rm /var/lock/LCK..ttyS1
where you replace ttyS1
by whichever serial port your modem uses.
Immediate PPP:
First run (all on one line)
/usr/sbin/pppd
/dev/ttyS1 57600 debug connect "/usr/sbin/chat -v '' AT
OK ATD5555555 CONNECT '\d\c'"
(Note that that is
doubled apostrophe ' after the chat -v, not a single double quote mark ".)
This will not produce a ppp connection, but it should dial your phone,
(where 5555555 is to be replaced by your ISP's phone number). (Note that I use
57600 as a conservative option for modem speed. If you are on a sufficiently
fast system, and you have a new 56K or 33.6K modem, this should almost certainly
be changed to 115200. However, I will stay conservative here to make sure it is
not modem speed problems which are causing grief.)
[ If it does not dial your phone, then you will have to figure out on which
port your modem is on, and perhaps send your modem some init string. For example
to tell most modems to reset themselves to factory default, do the following
(again all on one line)
/usr/sbin/pppd /dev/ttyS1 57600 debug connect
"/usr/sbin/chat -v '' 'AT&F0' OK ATD5555555
CONNECT '\d\c' "
instead. You can add anything else you
need to send to the modem either instead of the &F0 or after it.]
http://www.56k.com/inits/ contains modem
initialisation strings for a large variety of modems.
[If there is a significant length of time between the log entry for the "send
AT" "expect OK" lines and the resulting "got it" in the /var/log/ppp file, the
modem is using a different interrupt line (IRQ) than the kernel is expecting.
Try using the setserial command as follows:
setserial /dev/ttyS1
autoconfig auto_irq
If this corrects the problem put that line into
/etc/rc.local or /etc/rc.d/rc.local or...]
(Although the man page and the
setserial usage blurb state that the parameter is autoconfigure, the
program actually uses autoconfig instead-- one of Linux's charms.--thanks
to M. Cook for pointing this out.)
I will assume that this dialed your phone. This will NOT connect you to your
ISP via ppp unless your ISP is incompetent (there is as yet no authentication).
However we can now use the debugging output of this command to determine what
kind of authentication your ISP wants.
Which Authentication Scheme?
Look at the end of /var/log/ppp (eg do
less /var/log/ppp
To page back, use ^B (control B) The space bar
will page forward. Or if you ran the tail -f command above look at the end of
its output.) You should see a bunch of messages from chat, telling you what it
sends and what it receives from the far end. (In this case it will end when chat
receives the CONNECT string
got it (CONNECT)
from your modem)
Then pppd will start reporting, and will probably give some error message.
One possibility is the message containing the line
Problem: all had bit 7
set to 0
This means that your ISP was not expecting you to negotiate ppp
at this point. It almost certainly means that your ISP wants you to log on
first.
You may at this point get no response from the far system at all-- ie, your system sends out LCP Config Requests and gets no response. Try replacing the '\d\c' in the above line with the word CLIENT, and try again. This indicates that you have an Win NT RAS server as your ISP. In all of the discussions below, continue to replace `\d\c' with CLIENT.
Alternatively, One of the lines at the end of /var/log/ppp reported to be
from pppd had something that started out with rcvd and then had something
in it that looked like
<auth pap>
or
<auth chap
...>
(as an example here is one of mine
Jan 15 23:10:28
wormhole pppd[511]: rcvd [LCP ConfReq id=0x1 <mru 1524> <asyncmap
0xa0000> <auth pap> <pcomp> <accomp> < 13 09 03 00 c0 7b
63 d6 e6>] )
This means that they are ready to negotiate ppp and want
to use pap (chap) authorization, not login authorization. If so, go down below
to the PAP/CHAP authorization section.
Login Authorization?
So. let us assume that they want login
authorization (you got the "bit 7" error message). Try (on one line)
/usr/sbin/pppd /dev/ttyS1 57600 debug connect "/usr/sbin/chat -v
'' ATD5555555 CONNECT '' ogin:
<yourusername> assword: <yourpassword>"
where
<yourusername>; is your user name on the remote machine , and similarly
for <yourpassword>. (Note that the <> surrounding the works
yourusername and yourpassword are not to be included in your script. Note again
that those are doubled apostrophes ' not single double quotes " inside the chat
-v script, but are double quotes " surrounding it.)
Again look in /var/log/ppp.
You should see chat logging you in (sending
your remote name and your password). If not, look at what chat received from the
far end to get a clue as to what they expected. For example on some machines the
login request comes via a Name: or Username: request instead of Login:. In that
case, change the "ogin:" to "ame:" instead in the above command line.
If
both your username and your password got sent (both show up on the lines in
/var/log/ppp) but you got a login rejection, check to make sure that you have
the right password and username for the remote system.
If it logged you in but again you got a message saying the 7 bit is all zero,
your ISP is expecting something else from you after you logged in. This is most
likely a, ppp or a pppd command. Insert a
"" ppp
or
"" pppd
at the end of the chat string. In one case they put in a
request "Do you want PPP? y/n" In that case put in
"PPP? y/n" "\dy"
at the end of the chat script instead. (The \d tells chat to wait one
second, to make sure that the remote computer is ready to receive your "y". (Try
one of these. If it does not work, the lines in /var/log/ppp from chat will give
you a clue as to what was expected).
Occasionally, your ISP will want both login authorization and PAP or CHAP authorization. You will see this by the <auth pap> or <auth chap ...> in the pppd lines in /var/log/ppp file after you have logged in. In this case go to the PAP/CHAP section and follow those directions as well.
If, in the var/log/ppp file you see a line giving your local and the remote
IP address, you are connected and skip the next section.
PAP/CHAP
Let me assume that in one of the various lines in
/var/log/ppp, there was the phrase <auth pap> (<auth chap ...>).
This means that the remote system wants to use PAP (CHAP) authentication. Let me
first make a digression on the types of CHAP authentications.
Types of CHAP
In the case of CHAP , there is an extra number after
the <auth chap ..>, indicated by the dots, which indicates which
type of CHAP authentication they are using (Yes, there are different types). The
05 one (or md5) is standard, and your system will have no problem with it. The
types 80 (also called m$oft) and 81 are special Microsoft types. Your pppd will
state in /var/log/ppp if it does not support them with error messages like--
unknown digest type or Unknown CHAP code 80 received..
Your pppd
(certainly in the 2.3.x series) can and may already support type 80 (m$oft). In
this case you are OK. The only thing to beware of is that the username in
chap-secrets file and in the user option to pppd may need the special domain
addition.
Similarly if you see something like
.... < auth 0xc027
01 ....> ...
in one of the lines from the far end, they want a
patented version of PAP called Shiva PAP (or SPAP). Because of those patents,
Linux does not support it. This is probably an NT server, and should also accept
other versions of authentications if properly set up (a big if).
If your
version of pppd does not support type 80 (m$oft), it may be possible to
recompile your pppd from source to support the type 80 chap. I leave that
exercise to you.
Read the file
README.MSCHAP80 from the
pppd source for hints. Also see the file http://www.xs4all.nl/~diedvdyk/PPP-NT-HOWTO/PPP-NT-HOWTO.html
Often a server will first try to see if you are willing to use the chap 80
but if your system does not agree, they will fall back to asking for either chap
05(md5) or pap.
Finally note that there are two separate type 80 (m$oft)
chap implementations. The older, obsolete standard is Microsoft's lanman
standard. Microsoft's newer is the default NT standard. If your ISP uses the
older standard, (and you can only find that out from them) and your pppd has
been compiled to support type 80 and this MSLANMAN option, then you can persuade
pppd to use the older one by use of the ms-lanman option to the pppd command.]
If your ISP uses type 81 and refuses to use anything else, yell at them for
using this new Microsoft non-standard. If they refuse to use anything else (eg
chap 05 or chap md5) then note that efforts are being made to also support
MSChap 81 in Linux. There is a patch for pppd 2.3.8 at http://www.moretonbay.com/vpn/download_pptp.html
(see the PPP2.3.8 Patch) which is part of the VPN for Linux PPTP Server
project. At present this is still beta level software. .
Setting up PAP/CHAP
You now need to make sure that the remote system gets the proper PAP/CHAP authentication. There are two steps here.
a) Edit the file /etc/ppp/pap-secrets (/etc/ppp/chap-secrets).
You will
now add a line to this file. The first entry in the line is your user name on
the remote system. The second is a *. The third is your password and the fourth
can also be a *. Thus there will be a line like
<yourusername> * <yourpassword> *
eg.
unruh * dontyouwish *
(This means that this line is the pap (chap) secret for user <yourusername> on any remote system (*) and <yourpassword> is that secret. Also the connection can use any IP address-- the second *.)
The second entry (first star) may have to be replaced by the name of the remote system if your ISP told you to do so or you have accounts on many ISPs. The last star may have to be removed. But this line as written should work for a single ISP.
If you have accounts on multiple systems, then you will have to replace the
second item (first *) with the a name for the remote system so your system knows
which secret to use for that particular remote system. There are three options
for that name.
(i)You can ask your ISP for a name.
(ii)You can look
in /var/log/ppp for a line like
pppd[1155]: rcvd [CHAP Challenge id=0x1
<...>, name = "axion"]
where ... is a long string of random
numbers and letters. That name (axion in this case) is the name the remote
system thinks of itself as. chap 80 (Microsoft chap) does not report the remote
system name.
(iii)Or you can assign the remote system an arbitrary name,
put the option
remotename <TheNameYOuDecidedOn>
after the
pppd command.
Whichever option you choose, use that name as the second field
in the line in the chap-secrets file (or pap-secrets).
If your ISP uses NT, you may have to add a domain name to your username. Thus, in both the chap secrets file and in the "user" option to pppd, instead of <username>, use <domainname/username> instead. (or in some cases it has been reported as <domainname\\username>) You will have to get the domainname from your ISP.
[Note that PAP or CHAP also has the option for symmetric authentication,
where your machine also requires authentication of the remote system. For most
home user systems, this will not be used--your ISP will refuse to agree to
authenticate themselves-- and the above is sufficient. If in your /var/log/ppp
file you see your system asking the remote system for authentication-- ie a line
like
Jan 15 23:10:28 wormhole pppd[511]: sent [LCP ConfReq ... <auth
pap> ...
ie your system sent (not received) a request (ConfReq) for pap
authentication, then your system wants the other side to authenticate
themselves, which they will almost certainly refuse to do. Put the line
noauth
into your /etc/ppp/options file and remove any options
like +chap, +pap, require-pap, require chap, auth from the
/etc/ppp/options file or from the pppd command line. Some new versions of pppd
may, by default, require the the remote system to authenticate themselves, and
will thus need the noauth option.]
b) In both the case of PAP and CHAP you also have to use the "user" option to
pppd, to let the remote machine and your machine know what your user name is for
PAP/CHAP authentication when looking up secrets in the pap-secrets or
chap-secrets files. By default pppd uses the name of your local machine, which
is probably not your user name on the remote machine. So now try
/usr/sbin/pppd /dev/ttyS1 57600 debug user <yourusername> connect
"/usr/sbin/chat -v <chatstring>"
where <chatstring> is
whichever chat string successfully got you to this point. (Remember that the
< and > are not to be included in strings.)
Eg., here would be a line
for my system
/usr/sbin/pppd /dev/ttyS1 57600 debug user unruh connect
"/usr/sbin/chat -v '' ATDT5551234 CONNECT '\d\c' "
Occasionally the remote system is broken, and after they have asked for PAP
authentication, they seem to refuse to listen to your systems sending them the
requested information. The symptom will be your system sending a whole string of
PAP authentication attempts
.... sent [PAP AuthReq id=0x1 user="username"
password="password"]
.... sent [PAP AuthReq id=0x2 user="username"
password="password"]
....
with no response from the other side. Try
putting the line
asyncmap 0xa0000
or even
default-asyncmap
into your /etc/ppp/options file.
Occasionally you may find, in reading /var/log/ppp, that the remote end
cannot seem to hear you. Your side sends requests to the far side, and the far
side keeps sending back the same requests to you. The session will terminate
after a while. You may have a misconfigured serial port. Run
setserial
/dev/ttyS1
and make sure that the UART listed is actually the same as the
one on your serial or modem card. Almost all newer computers ( since the mid
90s) use the 16550A UART. This is different from the 16550 UART or 16450.
Are you connected?
You are now, I hope, connected via ppp. The
/var/log/ppp file should have a line like
Connect: ppp0 <-->
/dev/ttyS1
1 Now, run
/sbin/route -n
and look for a
default (0.0.0.0) option on the ppp0 link (ppp0 is the last item in the line,
and 0.0.0.0 is the first). If so, success, you are connected. If not, you now at
least have the far end negotiating for a ppp connection. Your /var/log/ppp file
should now have lines which read
sent [LCP ConfReq ... rcvd [LCP ConfAck
...
pppd will also report in the log file your local and the remote IP
addresses. If so, you are connected.
Connected!!:
At this point you should be connected. You should see
lines like
Jan 16 14:54:50 wormhole pppd[905]: local IP address
137.82.66.22
Jan 16 14:54:50 wormhole pppd[905]: remote IP address
137.82.47.122
in /var/log/ppp. (The above two lines are from my own
system. The addresses, names, dates and times will vary for yours, but the form
should be the same.)
ppp is now connected.
Testing Connection
First try to ping the address of the remote host.
In /var/log/ppp there will be two lines that look like
Feb 7 12:52:21
ppptest pppd[27378]: local IP address 137.82.43.5
Feb 7 12:52:21
ppptest pppd[27378]: remote IP address 142.103.234.16
(Note that these
are for a particular connection on my system. The numbers will differ on yours)
These two lines give your and the remote computer's IP numbers for the duration
of the connection. (They may well change the next time you connect.)
Again run
/sbin/route -n
and look for an entry in which the
first entry is that remote IP address, and the last entry is ppp0. It must be
there for the connection to work.
Then do
ping <remoteIPnumber>
eg in the above case this
would be
ping 142.103.234.16
You should get back a sequence of
lines about one every second. This shows that your connection to that remote
host is OK, and that you have a connection to it. Type ^C (control-C) to stop
ping. (Sometimes the remoteIPnumber does not respond to pings because of the way
the ISP has set it up. Do not worry yet unless you get a Network or Host
unreachable message.)
Now, look at those lines that you added to /etc/resolv.conf back at the
beginning of this script. Do
ping <nameserverIP>
where the
entry in /etc/resolv.conf was
nameserver <nameserverIP>
Again you should get a series of responses. If you do not, they may not
support ping on those machines. However, if you get a response saying that the
host or network is unreachable, there is definitely something wrong, either with
your setup or with the nameserver address they gave you.
Now try
ping 142.103.234.16
(Using that actual number)
which should work (unless of course there is something wrong with my
machine. In which case try other IP numbers.) If none of these work, then there
is some problem with your connection (eg default route problems).
Now try pinging some name, eg.,
ping axion.physics.ubc.ca
(which is the location where this page is kept). The key thing is that ping
reports back on its first line with the IP address of axion. If it did so, it
means your nameserver is working. If the previous one worked, but this one does
not, then you either forgot to follow the initial instructions on this page
about setting up the file /etc/resolv.conf, or your ISP has nameserver problems.
Try a few more names of machines that you know. If all of these tests have
passed, try running Netscape and connecting to some page. Everything, I hope,
now works.
If not, collect all of the details you can (eg the output in /var/log/ppp--
making sure that you remove your passwords from that file) and ask for help in
comp.os.linux.networking, alt.os.linux.dial-up, or alt.comp.linux.isp.
As
politeness, look in the archives on www.dejanews.com since your problem may
already have been answered ( many times). When you ask for help or search, make
your subject and description as specific as possible. "Nothing works" as a
symptom is very very hard for anyone to suggest fixes for.
Various Possible Problems
The PPP setup returns the error "Could not determine
remote IP address". This means that your ISP has a damaged implementation of
ppp, which does not know (or refuses to report) who it is. So you need to assign
your ISP an IP number. Put the lines
:192.168.255.1
ipcp-accept-remote
into the /etc/ppp/options file. These assign your
ISP the IP number 192.168.255.1 (a "reserved" IP number) since they refuse to
tell you theirs, and also tells pppd to accept their version if at this point
they wake up and finally send you an IP address for themselves.
You might
also notify your ISP that maybe they should know their own IP number.
ping works --ie the ping tests above all worked--, but
telnet, or surfing does not seem to work. On the 2.3.9 and 2.3.10 versions of pppd, the message You may see a series of lines like
In this case, where the remote ISP wants you to log in, the chat script is
most complex. I will also add some extra features to the chat script to make it
more robust than the minimal commands I used above. (The lines starting with #
are comments which may safely be removed or left in.) The other possibility is that the ISP uses PAP/CHAP authorization. In this
case the pppon script needs the "user" option. You can put it into the file
permanently (eg, if you will ever only use a single ISP) or, as in the
following, you can allow it to be given as an option to pppd. When you have created the above scripts, (perhaps with the debug option for
pppd in pppon and adding a -v after the chat command so you can see what goes
wrong if something is wrong with the script--- just remember to remove both of
these once you have finished testing), copy them to their final home.
mv pppon /usr/bin Note that we have made the chatscript readable only by the user. This is
important since it may contain the user's password (in the logon case).
Since pppd tries to hang up the modem by switching the DTR line to the modem,
the modem must be set up to reset the modem when this occurs. The modem will
eventually hang itself up if pppd stops, but it takes a while (a minute or so at
times). thus it is useful (but not crucial) that you set up your modem to use
the DTR line to reset the modem. You must look up the command in your
documentation for your modem. For the three different modems I have, the command
is &D3 (Reset modem on ON to OFF transition of DTR). So you would add
&D3 to the modem initialisation string in the chat script files. Ie, the
line One useful safety net (against running up huge bills with your ISP and making
your family angry at your hogging the phone) is that pppd has an option to hang
up the connection if no traffic has gone across the ppp network in a certain
amount of time. Enter the line
Again your ISP seems to have a
defective ppp. Try putting the line
novj
into /etc/ppp/options.
This disables compression of the headers on the packets which seems to cause
problems for some ISPs..
Miscellaneous Error messages
There are a few error messages which crop
up with the newer versions of ppp and the newer (2.2.x) kernels.
modprobe: can't
locate module char-major-108
is displayed in the log file. Ignore this.
These versions of pppd use some new features of the ppp kernel drivers in the
development kernels on linux if they are available. This message says ppp cannot
find these features. This is fine as these versions of ppp also work perfectly
well with the older (2.0.x and 2.2.x) kernels.
modprobe: Can't locate
ppp_compress-21
or 24 or 26. Put the following three lines into
/etc/conf.modules
alias ppp-compress-21 bsd_comp
alias
ppp-compress-24 ppp_deflate # From original RFC draft
alias ppp-compress-26
ppp_deflate # Final standard per ppp-2.3.4
Again these error messages
cause no harm, except ,in the unlikely event that the remote side supports these
compression modes, you will not be able to use them. (Modems nowadays do
compression, so the advantages of software compression are minimal).
Automation and Cleanup
SUID
To allow ordinary users (or usually you as an ordinary user) to
use ppp, some changes need to be made. Just make sure that the pppd file is rx
permission for users
chmod a+rx /usr/sbin/pppd
and that
/usr/sbin/pppd is setuid for root
chmod +s /usr/sbin/pppd In
addition, you may have to make the serial port accessible by your users.
Assuming that your port is /dev/ttyS1 (COM2) do
chmod a+rw /dev/ttyS1
Note that some programs (like linuxconf or mgetty) like to change the
permissions of the serial port back to a more protected form. So, don't run
linuxconf or mgetty, or get used to having to keep resetting the permissions of
the serial port. Alternatively, get one of the more recent versions of pppd (eg
2.3.9). If you put the port (eg., /dev/ttyS1) into /etc/ppp/options, instead of
on the pppd command line as I do in the scripts below, pppd will connect to the
port as root, rather than as user. Then you do not have to worry about the
permissions on the port.
(If you have users who you do not want using your
modems, edit /etc/group and insert a line like
ppp::25:<Comma
separated List of names of users>
where the List of users is a comma
separated list of the users you want to allow use of ppp. The group number -- 25
in the above example-- is arbitrary, but should not be the same as any other
group in /etc/group. Then do
chown root.ppp /usr/sbin/pppd
chmod o-rx /usr/sbin/pppd
in addition to the above changes.)
Alternatively if you are running mgetty put your modem users into
the group uucp, which should already be defined in /etc/group. (mgetty keeps
resetting the ownership and permissions of the device, eg, /dev/ttyS1, to have
group uucp, and no rw permissions for ordinary users)
Script
Let us now automate the running of pppd by writing two
scripts. The first script file will contain the commands, while the second will
contain the expect/send pairs that you have found that chat needs to log you on.
The first file I will call pppon (to distinguish it from the ppp-on which
comes with your distribution), while the second will be chatscript. The
pppon script is simple, but comes in two versions. The one for the case in which
you discovered that your ISP expected you to log on
pppon ===============================================
#!/bin/sh
#This script is for the case where you log on to your ISP
/usr/sbin/pppd /dev/ttyS1 57600 connect "/usr/sbin/chat -f $HOME/chatscript"
----------------------------------------------
In this case I have assumed
that each user will keep their chatscript in their home directory. Replace $HOME
with the path if you want it kept elsewhere.
It is important to note that I
have removed the -v from the chat command and the debug option from the pppd
command. This is important as otherwise your password will be recorded in the
/var/log/ppp file-- a bad idea.
chatscript ============================================
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
#The above lines indicate conditions for chat quitting
"" AT
'OK-\d\d+++\d\d\c-OK' ATH0
# The A-B-C form of the expect sequence means that it is to expect A,
# if A does not arrive, send B and then expect C.
# So this line means-- expect OK, if it does not arrive, wait two
# seconds,(each \d is a one second wait) send +++
# wait for two more seconds and then do not send a carriage return.
# Finally again wait for OK again. If it arrives, send ATH0
# The +++ is in case your modem has not hung up. You may want to know if your
# modem is not hanging up, if so, remove this whole line.
OK 'AT&F\\Q3\\V1&D3M1#CC1'
# These are various controls sent to my particular modem. CHANGE FOR YOURS!
#The &F , &D3 and M1 seem to be quite generic for setting the modem
# with factory defaults, allowing the DTR line to reset the modem
#(Used when pppd shuts itself down), and M1 allows the speaker on while the
#call is being established, but off after the remote system has answered.
#USR/3COM Sportster modems require &F1 instead of &F.
# \Q3, \V1, and #CC1 are almost certainly peculiar to my particular
# modem.
# Note that a backslash must be doubled to get through. This sequence
# should also always be enclosed in single quotes
# because of the special characters like &.\,#.
OK ATD8765432
CONNECT ""
ogin:--ogin: unruh
# Again the A-B-C, except the middle B to be sent if ogin: is not
# received is nothing except a carriage return
assword: "dontyouwish"
---------------------------------------------------------------\
If in your determination of what your ISP wanted, you found you had to
expect other text (eg 'PPP? y/n') and send a response, insert those onto the end
of this file. Also, since your username, password and phone numbers are highly
unlikely to be as in this script, change those.
pppon ==============================================================
#!/bin/sh
if [ "$1" = "" ] ;then
echo "Usage: pppon username"
exit 1
fi
/usr/sbin/pppd /dev/ttyS1 57600 user $1 connect "/usr/sbin/chat -f $HOME/chatscript"
----------------------------------------------------------------
This
script asks for your username on the remote system as part of the options to the
pppon. You could replace the lines between the if and fi and just
put the username in instead of the $1 in the pppd command line if you wished.
It is important to note that I have removed the debug option to pppd.
Under especially PAP, using debug will store your PAP password in the
/var/log/ppp file, which is not what you want. Additionally, erase your
/var/log/ppp file at this point to remove the possibility of anyone reading the
password in that file.
The chatscript here is simpler, since you do not need
to log on (for an explanation of the various lines in this script, look at the
above example where I set up a sample chatscript for the case the ISP expects
you to log on first).
chatscript ===============================================================
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
"" AT
OK-\d\d+++\d\d\c-OK ATH0
OK 'AT&F\\Q3\\V1&D3M1#CC1'
OK ATD8765432
CONNECT '\d\c'
# The \d means wait a second, the \c means do not send a carriage
# return (sending a carriage return at this point almost always confuses
# the ISP)
--------------------------------------------------------------------
chmod a+rx /usr/bin/pppon
chown
<user> chatscript
su <user>
mv chatscript
$HOME
chmod go-rwx $HOME/chatscript
Extra Security
When you are connected to the internet via ppp,
others are also connected to you, and this could open you to break-ins while you
are connected. To help alleviate this, put the line
ALL: ALL
into
the file /etc/hosts.deny and
ALL: 127.0.0.1 127.0.0.0
into
/etc/hosts.allow. This will disallow all external hookups by anything to your
machine. If you want more detailed control, read
man 5 hosts_access
For example, if you have an internal ethernet network you obviously want to
allow them, but not others to log on to your system.
Stopping PPP
killall pppd
This sends a signal to the pppd program telling it
to shut down. pppd shuts itself down by dropping the DTR line to the modem, and
by running the commands in /etc/ppp/ip-down and /etc/ppp/ip-down.local. The
biggest problem with the above is that the command may not work unless you are
logged in as root. (I have had this trouble for a while, others, including me
now, have not.) If the above does not work (ie your ppp connection stays up and
your modem does not hang up after a minute or so) you will either have to log on
as root and then run the above command, or you can use a "wrapper" so that any
user can run the above command as root. This wrapper is a C program which makes
running the command as suid root safe. The details are given on the web page
http://axion.physics.ubc.ca/ppp-kill-wrapper.html
OK 'AT&D3'
should be added just before the line where you dial
up your service provider.
idle 1800 into /etc/ppp/options file. This
will hang up the phone if there has been no traffic for 1800 seconds (30 min).
Change that number (1800) if you want this idle option to work more quickly (or
slowly).
You might want your system to do demand dialing-- ie, to have your system phone
your ISP on its own every time you (or your computer) wants to connect. (This is
especially handy if you have a number of computers connected to yours and yours
acts as the gateway via PPP to the outside world). To do so use the program
diald from http://www.loonie.net/~eschenk/diald.html
See http://www.r-senior.demon.co.uk/linux/diald.html
for instructions)
To have others connect to your machine, (ie, to have
yourself act as an ISP), use mgetty from
http://alpha.greenie.net/mgetty/. Also get the guide http://www.swcp.com/~jgentry/pers.html
to setting up dial in access.
Here, http://axion.physics.ubc.ca/mgetty-point.html
are also a number of links to documentation to getting mgetty up and running
(including with multiple incoming telephone lines).
For a variety of scripts, which can be of help in a some situations, see C
Kite's site http://www.inetport.com/~kite.
In
particular
For dialing a number of ISPs in a row if they are busy. This is
for ISPs who all use chap or pap authentication. http://www.inetport.com/~kite/chap-many2one.gz
For a patch to chat (although this is by now an old version of chat) to
allow use of SecureID see: http://www.inetport.com/~kite/SecurID.gz
For another "SecurID" type one time password patch see http://www.inetport.com/~kite/chatbypipe.tar.gz
For a discussion on RAS callback for Linus ppp, see http://www.inetport.com/~kite/RAScb.gz"
These scripts have not been tested by me, so use at your own risk.
Finally, if it is really kppp which you want to run, see http://www.crosswinds.net/~beginnerslinux/internete.html
A really big helping of thanks to [EMAIL PROTECTED] for a lot of help in whipping this page into shape. Thanks also to [EMAIL PROTECTED] for helpful improvements to this document. Finally, but not least, I would thank James Carlson and Clifford Kite from whose posting on comp.protocols.ppp and elsewhere I have learned a lot of what I know about ppp.
This document was written by mailto:[EMAIL PROTECTED]. I would appreciate any feedback you can give, especially if your ISP has some other strange way of authenticating you. Also if anything in this document is ambiguous, hard to follow, or wrong, please let me know.
Good Luck in your connection.
Last modified May 2, 2000
