|
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.
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://cs.anu.edu.au/pub/software/ppp/
See http://www.o2.net/~gromitkc/winmodem.html
for a listing of known winmodems.
For some advice on buying modems for Linux, see
http://www.math.sunysb.edu/~comech/tools/CheapBox.html#modem]
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
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
[ 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 ....]
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.
[ 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.
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.
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.
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 *.)
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.
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.
ping works --ie the ping tests above all
worked--, but telnet, or surfing does not seem to work.
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..
On the 2.3.9 and 2.3.10 versions of pppd, the message
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.
You may see a series of lines like
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).
=============================================== #!/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.
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.)
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.
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.
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.
===============================================================
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)
--------------------------------------------------------------------
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
chmod a+rx /usr/bin/pppon
chown <user> chatscript
su <user>
mv chatscript $HOME
chmod go-rwx $HOME/chatscript
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
OK 'AT&D3'
should be added just before the line where you dial up your
service provider.
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
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).
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
A really big helping of thanks to staehle@nevalue.net for a lot of help in whipping this page into shape. Thanks also to pacman@cqc.com 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.
Good Luck in your connection.
Last modified Jan 31, 2000