Lets try actually going through this article:
Troubleshooting ISP Connection Problems
Open an x terminal and command:
su -
<enter root password>
tail -f /var/log/messages
Open a second root x terminal as before and command:
killall pppd
Place both x terminals where you can see both at once.
In the second x terminal, paste this all on one line:
Code:
/usr/sbin/pppd /dev/ttySL0 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:
Code:
/usr/sbin/pppd /dev/ttySL0 57600 debug connect "/usr/sbin/chat -v '' 'AT&F0' OK ATD5555555 CONNECT '\d\c' "
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/messages file, the modem is using a different interrupt line (IRQ) than the kernel is expecting. Try using the setserial command as follows:
Code:
setserial /dev/ttySL0 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.
Which authentication scheme?
Look at the end of /var/log/messages.
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.
Then 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 \d\c with CLIENT.
Or, if one of the lines at the end of /var/log/ppp reported to be from pppd and had a line that started out with rcvd and then had text that looked something like
<auth pap>
or
<auth chap ...>
(As an example, here is one of mine
Code:
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, skip ahead to the PAP/CHAP authorization section.
Login authorization
So ... Let's assume that they want login authorization (you got the bit 7 error message). Try (on one line)
Code:
/usr/sbin/pppd /dev/ttySL0 57600 debug connect "/usr/sbin/chat -v '' ATD5555555 CONNECT '' ogin: <yourusername> assword: <yourpassword>"
where <yourusername>; is your user name on the remote machine, and similarly for <yourpassword>. Note that the <> surrounding the words 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.
Again look in /var/log/messages.
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 Name: or 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/messages) 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 ppp or "" 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.
PAP/CHAP
If in one of the lines in /var/log/messages, 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.
Types of CHAP
With CHAP, there is an extra number after the <auth chap ..>, 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/messages if it does not support them with error messages like -- unknown digest type or Unknown CHAP code 80 received..
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.
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 pppd command.]
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.
Setting up PAP/CHAP
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 /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> *
For example,
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 *.)
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/messages 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.
* 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 user name. 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 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/messages file you see your system asking the remote system for authentication -- such as a line like
Jan 15 23:10:28 wormhole pppd[511]: sent [LCP ConfReq ... <auth pap> ...
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
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 itself, and will thus need the noauth option.]
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 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:
Code:
/usr/sbin/pppd /dev/ttySL0 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.)
For example, here would be a line for your system
/usr/sbin/pppd /dev/ttySL0 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
asyncmap 0xa0000
or even
default-asyncmap
into your /etc/ppp/options file.
Occasionally, when you read /var/log/messages, 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
Code:
setserial /dev/ttySL0
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.
Are you connected?
You are now, I hope, connected via PPP. The /var/log/messages file should have a line like
Code:
Connect: ppp0 <--> /dev/ttySL0
Now, run
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.
Connected!
At this point you should be connected. You should see lines like:
Jan 16 14:54:50 wormhole pppd[905]: local IP address 137.82.66.22
Jan 16 14:54:50 wormhole pppd[905]: remote IP address 137.82.47.122
in the /var/log/messages 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.
HTH.
