how to hook up ppp in linux.htm

How to Hook up PPP in Linux

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.) 
<P>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. 
<P>[ 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) <BR><B>/usr/sbin/pppd /dev/ttyS1 57600 debug connect 
"/usr/sbin/chat -v &nbsp; '' &nbsp; 'AT&amp;F0' &nbsp; OK &nbsp; ATD5555555 
&nbsp; CONNECT &nbsp; '\d\c' "</B> <BR>instead. You can add anything else you 
need to send to the modem either instead of the &amp;F0 or after it.] <BR><A 
href="http://www.56k.com/inits/">http://www.56k.com/inits/</A> contains modem 
initialisation strings for a large variety of modems. 
<P>[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: <BR><B>setserial /dev/ttyS1 
autoconfig auto_irq</B> <BR>If this corrects the problem put that line into 
/etc/rc.local or /etc/rc.d/rc.local or...] <BR>(Although the man page for 
setserial and the setserial usage blurb state that the parameter is 
<I>autoconfigure</I>, the program actually uses <I>autoconfig</I> instead-- one 
of Linux's charms.--thanks to M. Cook for pointing this out.) 
<P>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. <A 
name=Which></A>
<H3>Which Authentication Scheme?</H3>Look at the end of /var/log/ppp (eg do 
<BR><B>less /var/log/ppp</B> <BR>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 <BR><I>got it (CONNECT)</I> <BR>from your modem) 
<P>Then pppd will start reporting, and will probably give some error message. 
One possibility is the message containing the line <BR><I>Problem: all had bit 7 
set to 0 </I><BR>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. 
<P>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. 
<P>Alternatively, One of the lines at the end of /var/log/ppp reported to be 
from pppd had something that started out with <I>rcvd</I> and then had something 
in it that looked like <BR><I>&lt;auth pap&gt;</I> <BR>or <BR><I>&lt;auth chap 
...&gt;</I> <BR>(as an example here is one of mine <BR><I>Jan 15 23:10:28 
wormhole pppd[511]: rcvd [LCP ConfReq id=0x1 &lt;mru 1524&gt; &lt;asyncmap 
0xa0000&gt; &lt;auth pap&gt; &lt;pcomp&gt; &lt;accomp&gt; &lt; 13 09 03 00 c0 7b 
63 d6 e6&gt;] </I>) <BR>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. <A name=Login></A>
<H3>Login Authorization?</H3>Let us assume that they want login authorization 
(you got the "bit 7" error message). Try (on one line) <BR><B>/usr/sbin/pppd 
/dev/ttyS1 57600 debug connect "/usr/sbin/chat -v &nbsp; ''&nbsp; 
ATD5555555&nbsp; CONNECT &nbsp; ''&nbsp; ogin:&nbsp; &lt;yourusername&gt;&nbsp; 
assword:&nbsp; &lt;yourpassword&gt;"</B> <BR>where &lt;yourusername&gt;; is your 
user name on the remote machine , and similarly for &lt;yourpassword&gt;. (Note 
that the &lt;&gt; 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.) 
<P>Again look in /var/log/ppp. <BR>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. <BR>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. 
<P>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,<B> ppp</B> or a <B>pppd</B> command. Insert a <BR><I>"" ppp</I> <BR>or 
<BR><I>"" pppd</I> <BR>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 <BR><I>"PPP? y/n" "\dy"</I> 
<BR>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). 
<P>Occasionally, your ISP will want <B>both</B> login authorization and PAP or 
CHAP authorization. You will see this by the <I>&lt;auth pap&gt;</I> or 
<I>&lt;auth chap ...&gt;</I> 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. 
<P>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 name=PAP></A>
<H3>PAP/CHAP</H3>Let me assume that in one of the various lines in /var/log/ppp, 
there was the phrase &lt;auth pap&gt; (&lt;auth chap ...&gt;). This means that 
the remote system wants to use PAP (CHAP) authentication. Let me first make a 
digression on the types of CHAP authentications. <A name=Types></A>
<H4>Types of CHAP</H4>In the case of CHAP, there is an extra number after the 
<I>&lt;auth chap ..&gt;</I>, 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--<I> 
unknown digest type</I> or <I>Unknown CHAP code 80 received.</I>. <BR>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. 
<P>Similarly if you see something like <BR><I>.... &lt; auth 0xc027 01 ....&gt; 
...</I> <BR>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). <BR>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. <BR>Read the file <BR><A 
href="http://www.theory.physics.ubc.ca/README.MSCHAP80">README.MSCHAP80</A> from 
the pppd source for hints. Also see the file <A 
href="http://www.van-dijk.net/PPP-NT-HOWTO/PPP-NT-HOWTO.html">http://www.van-dijk.net/PPP-NT-HOWTO/PPP-NT-HOWTO.html</A> 
<BR>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. <BR>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.] 
<BR>Note that the Windows 98 server only uses the ms-lansman version of the chap 
80 protocol<A href="http://axion.physics.ubc.ca/mschap.txt">(See Andrew Sun's 
comments on this)</A>. 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 <BR><B>make -DMSLANMAN</B> <BR>try to get the 
system to use the pap authentication, or (preferably) flee from that ISP as 
quickly as you can. <BR>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. <BR>See the <A 
href="http://pptpclient.sourceforge.net/">PPPTP- client Project</A> which 
includes patches for chap 81 and MPPE support and docs for setting up a PPTP 
client . <A name=Settingup></A>
<H4>Setting up PAP/CHAP</H4>
<P>You now need to make sure that the remote system gets the proper PAP/CHAP 
authentication. There are two steps here. 
<P>a) Edit the file /etc/ppp/pap-secrets (/etc/ppp/chap-secrets). <BR>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 <BR><PRE>&lt;yourusername&gt;     *     &lt;yourpassword&gt;        *
</PRE><BR>eg. <BR><PRE>unruh                *       dontyouwish             *
</PRE><BR>(This means that this line is the pap (chap) secret for user 
&lt;yourusername&gt; on any remote system (*) and &lt;yourpassword&gt; is that 
secret. Also the connection can use any IP address-- the second *.) <BR>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. 
<P>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. <BR>(i)You can ask your ISP for a name. <BR><BR>(ii)You can look 
in /var/log/ppp for a line like <BR><I>pppd[1155]: rcvd [CHAP Challenge id=0x1 
&lt;...&gt;, name = "www.theory"]</I> <BR>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. <BR><BR>(iii)Or you can assign the remote system an arbitrary name, 
put the option <BR><I>remotename &lt;TheNameYOuDecidedOn&gt;</I> <BR>after the 
pppd command. <BR>Whichever option you choose, use that name as the second field 
in the line in the chap-secrets file (or pap-secrets). 
<P>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 
&lt;username&gt;, use &lt;domainname/username&gt; instead. (or in some cases it 
has been reported as &lt;domainname\\username&gt;) You will have to get the 
domainname from your ISP. 
<P>[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 <BR>Jan 15 23:10:28 wormhole pppd[511]: sent [LCP ConfReq ... &lt;auth 
pap&gt; ... <BR>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 
<BR><I>noauth</I> <BR>into your /etc/ppp/options file and remove any options 
like <I>+chap, +pap, require-pap, require chap, auth</I> from the