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 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, and also work with the 2.2.x or 2.4.x series of kernels as well. Similarly, they work with versions of pppd at least from version 2.3.3 on (up to 2.4.1 by now).(For the 2.4.x kernels you must use pppd version 2.4.1 or later.) In fact some of the features below only work with later versions of pppd and I would urge you to upgrade to the latest version. You can get the latest pppd from ftp://ftp.samba.org/pub/ppp. You may be able to get versions from ftp://cs.anu.edu.au/pub/software/ppp/ but these sites may not be up to date.
Unfortunately the man page for pppd has gotten out of date, and a number of options have been added/subtracted without proper documentation. For a latest man page for pppd 2.4.1 written by James Carlson ( who ported pppd to Solaris and is the Solaris maintainer), see pppd-jc.8
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 142.103.234.29).) 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.)
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
SUSE has now gone over to using syslog-ng instead of syslogd. While it does give much more room for fine tuning exactly what and how you want things logged, it comes with a much more complex setup. As far as I can tell from the docs for syslog-ng, you need to add the following lines to the /etc/syslog-ng.config or /etc/syslog-ng/syslog-ng.conf file
destination ppp { file("/var/log/ppp"); };
filter f_ppp {facility(daemon) and facility(local2);};
log { source(src); filter(f_ppp); destination(ppp); };
and then restart the syslog-ng daemon. (killall -1 syslog-ng)
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 ....]
alias tty-ldisc-3 ppp alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate
LOOKUP ppp MODLOADOtherwise you can create the device with
alias /dev/ppp ppp_generic alias char-major-108 ppp_generic alias tty-ldisc-3 ppp_async alias tty-ldisc-14 ppp_synctty alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate
You have now set up the critical files on your system and you know that
you have 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 obscure 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.]
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.
For those with an interest, This command starts pppd on the terminal /dev/ttyS1 and sets the computer to modem speed at 57600 bps, tells pppd to log debugging messages to the file listed under daemon.* in /etc/syslog.conf, and says to use the program chat to connect. The chat program is told (-v) to log its debugging messages to the file listed under local2.* in /etc/syslog.conf, wait for nothing, send the command AT to the modem, wait for an return answer of OK, send the dialing command ATD5555555 to the modem, wait for CONNECT, then wait one second (\d) and then do NOT send anything-- especially not any carriage return back to the modem (\c). This last bit is important as for many ISPs if you send a carriage return, then assume you want to log on and give you a logon script, which can totally confuse everything.
[ 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 for setserial 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) but it may have begun the ppp negotiations. We can 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. If this starts ppp negotiations, it indicates that you have a Win NT RAS server as your ISP. If so, 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.
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) (the one
supplied by all distributions do, and the source code pppd2.4.1 enables
this automatically), 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.van-dijk.net/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.]
Note that the Windows 98 server only uses the ms-lansman version of the chap
80 protocol(See Andrew Sun's comments on this). Many
versions of pppd have not been compiled to support this version. Thus, you must
either download the source for pppd (see the above sources) and compile pppd with
make -DMSLANMAN
try to get the system to use the pap authentication, or (preferably) flee from
that ISP as quickly as you can.
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.
See the PPPTP- client
Project which includes patches for chap 81 and MPPE support and docs
for setting up a PPTP client
.
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> *
unruh * dontyouwish *
If you have accounts on multiple systems, then you will have to replace
the second item (first *) with the 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 = "www.theory"]
where ... is a long string of random numbers and letters. That name
(www.theory 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
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.29
(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 www.theory.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 www.theory. 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.
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.
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..
=============================================== #!/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).
Note that pppd will interpret anything on the link as resetting the
idle timer. Thus, and LcpEcho request (sent out by some ISPs to see if
you are still alive) will reset the timer and stop the idle timeout from
ever operating. However as of the 2.4.x series of kernels, the ppp
kernel has the option of active filtering which will disregard certain
items coming down the ppp line for purposes of the idle timer. The
kernel must have been compiled with the
PPP_FILTER
option. Whether yours has been depends on the distribution.
For a variety of scripts, which can be of help in a some
situations, see C Kite's site
http://users3.ev1.net/~ckite/public_html/download/index.html
In particular
For dialing a number of ISPs in a row if they are busy who all
use chap or pap authentication:
http://users3.ev1.net/ckite/public_html/download/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://users3.ev1.net/ckite/public_html/download/SecurID.gz
For another "SecurID" type one time password patch see http://users3.ev1.net/ckite/public_html/download/chatbypipe.tar.gz
For a discussion on RAS callback for Linux ppp, see
http://users3.ev1.net/ckite/public_html/download/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.beginnerslinux.org -> Connecting to the Web
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.
.
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 Mar 23, 2002