Unfortunately there is no one standard procedure for logging on to an ISP. Although each ISP uses a slightly different variation, the following procedure steps through various possibilities to help you discover what your ISP wants. Note that your ISP may have been "creative" and found some other way to confuse the users. This technique should still help you figure out what your ISP really wants.
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 what is logged to the
/var/log/ppp file. It sometimes scrolls by too fast to see, so use the window bar to scroll back through 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
pppd has not died, or that you want to kill it. Just enter
to kill it. Occasionally
pppdwill leave a lock file behind if it has been killed. If this is the case, do the following
ttyS1 with whichever serial port your modem uses.
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 is a 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 replaced with your ISP's phone number. Note that I use 57,600 as a conservative option for modem speed. If you are on a sufficiently fast system, and you have a new 56-Kbps or 33.6-Kbps modem, this should almost certainly be changed to 115,200. However, I will stay conservative here to make sure it is not modem speed problems that are causing you grief.
If it does not dial your phone, then you will have to figure out which port your modem is on, and perhaps send your modem an initialization string. For example, to tell most modems to reset themselves to factory default, do the following instead, again all on one line
/usr/sbin/pppd /dev/ttyS1 57600 debug connect "/usr/sbin/chat -v
'' 'AT&F0' OK ATD5555555 CONNECT
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 initialization strings for a large variety of modems.
If there is a significant length of time between the log entry for the "send AT" and "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.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.
Look at the end of
/var/log/ppp by typing
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.
pppd will start reporting, and will probably give an 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 remote system at all -- your system sends out LCP Config Requests but 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 Windows NT RAS server as your ISP. In all of the discussions below, continue to replace
Or, if one of the lines at the end of
to be from
pppd and had a line that started out with
rcvd and then had text that looked something like
<auth chap ...>
(As an example, here is one of mine:)
Jan 15 23:10:28 wormhole pppd: 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, skip ahead to the PAP/CHAP authorization section.
bit 7error message). Try (on one line)
/usr/sbin/pppd /dev/ttyS1 57600 debug connect "/usr/sbin/chat -v
'' ATD5555555 CONNECT '' ogin:
<yourusername> assword: <yourpassword>"
<yourusername>; is your user name on the remote machine, and similarly for
<yourpassword>. Note that the <> surrounding the words
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
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 it expected. For example, on some machines the login request comes via a
Username: request instead of
Login:. In that case, change the "
ogin:" to "
ame:" instead in the above command line.
If both your user name 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 user name 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
"" pppd at the end of the chat string. Sometimes ISPs 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 this 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 should skip the next section on PAP and CHAP.
If in one of the lines in
/var/log/ppp, there is the phrase
<auth pap> (
<auth chap ...>), this means that the remote system wants to use PAP (CHAP) authentication. Let me first explain the types of CHAP authentication.
With CHAP, there is an extra number after the
..>, the dots indicate 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..
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. Note that most distributions have been compiled to support this as delivered. I leave recompiling the
pppd source as an exercise to you.
Read the file README.MSCHAP80 from the
pppd source for hints. Also see the PPP-NT how-to file
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 -- you can only find this out from them -- and your
pppd has been compiled to support type 80 and the MSLANMAN option, then you can persuade
pppd to use the older one by adding the
ms-lanman option to the
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 (such as 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.co m/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.
You now need to make sure that the remote system gets the proper PAP/CHAP authentication. There are two steps here.
First, edit the file
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 *
(This means that this line is the PAP (CHAP) secret for user
<yourusername> on any remote system (
<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 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.
You can ask your ISP for a name.
You can look in
/var/log/ppp for a line like
pppd: rcvd [CHAP Challenge id=0x1 <...>, name = "axion"]
... 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.
Or you can assign the remote system an arbitrary name, put the option
remotename <TheNameYOuDecidedOn> after the
Whichever option you choose, use that name as the second field in the line in the
chap-secrets file (or
If your ISP uses NT, you may have to add a domain name to your user name. Thus, in both the CHAP secrets file and in the "user" option to
pppd, instead of
<domainname/username> instead. (or, in some cases, it has been reported as
<domainname\\username>) You will have to get the domain name from your ISP.
[Note that PAP and CHAP also have 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 itself -- and the above is sufficient. If in your
/var/log/ppp file you see your system asking the remote system for authentication -- such as a line like
Jan 15 23:10:28 wormhole pppd: sent [LCP ConfReq ... <auth
your system sent (not received) a request (
ConfReq) for PAP authentication, your system wants the other side to authenticate themselves, which they will almost certainly refuse to do. Put the line
/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 itself, and will thus need the
Second, 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
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>"
<chatstring> is whichever chat string successfully got you to this point. (Remember that the
> are not to be included in strings.)
For example, 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 system's request for information. The symptom will be that your system will send 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
Occasionally, when you read
/var/log/ppp, it may seem that the remote end cannot 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
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.
You are now, I hope, connected via PPP. The
/var/log/ppp file should have a line like
Connect: ppp0 <--> /dev/ttyS1
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, 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 that 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.
At this point you should be connected. You should see lines like
Jan 16 14:54:50 wormhole pppd: local IP address 184.108.40.206
Jan 16 14:54:50 wormhole pppd: remote IP address 220.127.116.11
/var/log/ppp file. 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.
Bill Unruh works for the Advanced Research Department of the Canadian Institute for Physics and Astronomy.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.