how to hook up ppp in linux.htm

How to Hook up PPP in Linux

/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.] 
<P>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 
<BR><B>/usr/sbin/pppd /dev/ttyS1 57600 debug user &lt;yourusername&gt; connect 
"/usr/sbin/chat -v &lt;chatstring&gt;"</B> <BR>where &lt;chatstring&gt; is 
whichever chat string successfully got you to this point. (Remember that the 
&lt; and &gt; are not to be included in strings.) <BR>Eg., here would be a line 
for my system <BR><B>/usr/sbin/pppd /dev/ttyS1 57600 debug user unruh connect 
"/usr/sbin/chat -v '' ATDT5551234 CONNECT '\d\c' " </B>
<P>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 <BR>.... sent [PAP AuthReq id=0x1 user="username" 
password="password"] <BR>.... sent [PAP AuthReq id=0x2 user="username" 
password="password"] <BR>.... <BR>with no response from the other side. Try 
putting the line <BR><I>asyncmap 0xa0000</I> <BR>or even 
<BR><I>default-asyncmap</I> <BR>into your /etc/ppp/options file. 
<P>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 <BR><B>setserial 
/dev/ttyS1</B><BR>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. <A 
name=AreYouConnected></A>
<H3>Are you connected?</H3>You are now, I hope, connected via ppp. The 
/var/log/ppp file should have a line like <BR><I>Connect: ppp0 &lt;--&gt; 
/dev/ttyS1</I> <BR>1 Now, run <BR><B>/sbin/route -n</B> <BR>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 <BR><I>sent [LCP ConfReq ... rcvd [LCP ConfAck 
... </I><BR>pppd will also report in the log file your local and the remote IP 
addresses. If so, you are connected. <A name=Connected!></A>
<H3>Connected!!:</H3>At this point you should be connected. You should see lines 
like <BR><I>Jan 16 14:54:50 wormhole pppd[905]: local IP address 
137.82.66.22</I> <BR><I>Jan 16 14:54:50 wormhole pppd[905]: remote IP address 
137.82.47.122</I> <BR>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.) 
<P><B>ppp is now connected. </B><A name=Testing></A>
<H3>Testing Connection</H3>First try to ping the address of the remote host. In 
/var/log/ppp there will be two lines that look like <BR><I>Feb 7 12:52:21 
ppptest pppd[27378]: local IP address 137.82.43.5</I> <BR><I>Feb 7 12:52:21 
ppptest pppd[27378]: remote IP address 142.103.234.16</I> <BR>(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.) 
<P>Again run <BR><B>/sbin/route -n </B><BR>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. 
<P>Then do <BR><B>ping &lt;remoteIPnumber&gt;</B> <BR>eg in the above case this 
would be <BR><B>ping 142.103.234.16</B> <BR>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 <I>Network or Host 
unreachable</I> message.) 
<P>Now, look at those lines that you added to /etc/resolv.conf back at the 
beginning of this script. Do <BR><B>ping &lt;nameserverIP&gt;</B> <BR>where the 
entry in /etc/resolv.conf was <BR><B>nameserver &lt;nameserverIP&gt;</B> 
<BR>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. 
<P>Now try <BR><B>ping 142.103.234.29</B> <BR>(Using that actual number) 
<BR>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). 
<P>Now try pinging some name, eg., <BR><B>ping www.theory.physics.ubc.ca</B> 
<BR>(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. 
<BR>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. 
<P>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. <BR>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.&nbsp; 
<HR>
<BR>&nbsp; <A name=Other></A>
<H3>Various Possible Problems</H3>
<P><A name=remoteIP>The PPP setup</A> 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 <BR><I>:192.168.255.1 
<BR>ipcp-accept-remote </I><BR>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. <BR>You might 
also notify your ISP that maybe they should know their own IP number. 
<P><A name=noTCP>ping works</A> --ie the ping tests above all worked--, but 
telnet, or surfing does not seem to work. <BR>Again your ISP seems to have a 
defective ppp. Try putting the line <BR><I>novj</I> <BR>into /etc/ppp/options. 
This disables compression of the headers on the packets which seems to cause 
problems for some ISPs.. <A name=MiscErr></A>
<H3>Miscellaneous Error messages</H3>There are a few error messages which crop 
up with the newer versions of ppp and the newer (2.2.x) kernels. <BR>On the 
2.3.9 and 2.3.10 versions of pppd, the message <BR><I>modprobe: can't locate 
module char-major-108</I> <BR>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. <BR><BR>You may see a series of 
lines like <BR><I>modprobe: Can't locate ppp_compress-21</I> <BR>or 24 or 26. 
Put the following three lines into <I>/etc/conf.modules (/etc/modules.conf 
</I>on the 2.4.x series of kernels) <BR><I>alias ppp-compress-21 bsd_comp 
<BR>alias ppp-compress-24 ppp_deflate # From original RFC draft <BR>alias 
ppp-compress-26 ppp_deflate # Final standard per ppp-2.3.4 </I><BR>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 these 
compressions. (Modems nowadays do compression, so the advantages of software 
compression are often minimal). 
<HR>
<BR>&nbsp; 
<P><A name=Automation></A>
<CENTER>
<H2>Automation and Cleanup</H2></CENTER>Typing the above command line every time 
you want to connect can get tiring and be prone to errors. It also suffers from 
the problem that it must be run by root, not an ordinary user, and is also 
insecure in that details like passwords are left lying around on the command 
line for anyone who can run the command ps to see. Thus we want to make the 
programs runnable by any user, make them easy to use, and we want to make sure 
that it is at least somewhat secure. <A name=SUID></A>
<H3>SUID</H3>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 <BR><B>chmod a+rx /usr/sbin/pppd</B> <BR>and that 
/usr/sbin/pppd is setuid for root <BR><B>chmod +s /usr/sbin/pppd</B> In 
addition, you may have to make the serial port accessible by your users. 
Assuming that your port is /dev/ttyS1 (COM2) do <BR><B>chmod a+rw /dev/ttyS1</B> 
<BR>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. <BR>(If you have users who you do not want using your 
modems, edit /etc/group and insert a line like <BR><B>ppp::25:&lt;Comma 
separated List of names of users&gt;</B> <BR>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 <BR><B>chown root.ppp /usr/sbin/pppd</B> 
<BR><B>chmod o-rx /usr/sbin/pppd</B> <BR>in addition to the above changes.) 
<BR>Alternatively if you are running <B>mgetty</B> 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) <A name=Script></A>
<H3>Script</H3>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 <I>pppon</I> (to distinguish it from the ppp-on which 
comes with your distribution), while the second will be <I>chatscript</I>. 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 <BR><I>pppon</I> <PRE>===============================================
#!/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"
----------------------------------------------</PRE>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. <BR>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. 
<P>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.) <BR><I>chatscript</I> <PRE>============================================
                      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,