Please do not link directly to this page. This page has been temporarily broken apart from the magazine to reduce bandwidth. In a couple months this article will be merged with the magazine. Instead please link to the following url:
[ Back to the June 2000 Troubleshooting Professional Magazine ]
The best means of testing a modem is to use a comm terminal to send it an AT, and see if it responds with an OK. This described later in this article, when Kppp's modem screen terminal button is discussed.
Kppp is an incredibly smart "front end" to the pppd daemon. Although the documentation doesn't term it this way, kppp has at least four events: Pre-connection, post-connection, pre-disconnection and post-disconnection. During the pre and post connection events, it uses your configuration information to create a default route, a gateway, modify the /etc/resolv.conf file for proper DNS resolution, modifying your /etc/ppp/pap-secrets or /etc/ppp/chap-secrets filesk, run the pppd daemon, and many, many more things. During disconnection these things are backed out. Kppp also takes charge of PAP or CHAP negotiations. Kppp is an extremely well thought out front end to pppd that makes connection to the 'net almost trivial.
It's a routing problem, and we'll discuss the solution later. For now, if you see the first error message, click the detail box, say "yes" to turning on debug if necessary, click the OK on the "debug added" info screen, and finally get to the actual error. If the text of the error is "The remote system is required to authenticate itself but I couldnt find any secret (password) which would let it use an IP address.". The solution is below the error message images.
If you get such an error message, use the route command to determine
whether you have a default route. Kppp adds your ISP assigned IP as a default
route, but it fails if a default route already exists.
[root@mydesk /root]# /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.10 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 192.168.168.200 192.168.168.200 255.255.255.255 UGH 0 0 0 eth0 192.168.168.201 192.168.168.201 255.255.255.255 UGH 0 0 0 eth0 192.168.100.0 192.168.100.10 255.255.255.0 UG 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.200.0 192.168.100.1 255.255.255.0 UG 1 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 eth0 [root@mydesk /root]#
/sbin/route del defaultThe preceding command must be done as root, of course. Now the route -n command produces a list without a default (destination 0.0.0.0) route:
[root@mydesk /root]# /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.10 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 192.168.168.200 192.168.168.200 255.255.255.255 UGH 0 0 0 eth0 192.168.168.201 192.168.168.201 255.255.255.255 UGH 0 0 0 eth0 192.168.100.0 192.168.100.10 255.255.255.0 UG 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.200.0 192.168.100.1 255.255.255.0 UG 1 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo [root@mydesk /root]#
Now try kppp, and the error message will almost certainly disappear,
although of course there could be other errors. Once you've connected and
logged in with kppp, the route -n command will reveal the ISP gateway address:
Destination Gateway Genmask Flags Metric Ref Use Iface 18.104.22.168 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.100.10 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 192.168.168.200 192.168.168.200 255.255.255.255 UGH 0 0 0 eth0 192.168.168.201 192.168.168.201 255.255.255.255 UGH 0 0 0 eth0 192.168.100.0 192.168.100.10 255.255.255.0 UG 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.200.0 192.168.100.1 255.255.255.0 UG 1 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 22.214.171.124 0.0.0.0 UG 0 0 0 ppp0 [root@mydesk /root]#
You can also do an ifconfig command to see your ppp0 status:
[root@mydesk /root]# ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:126.96.36.199 P-t-P:188.8.131.52 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 [root@mydesk /root]#
If for some reason you ever need your machine's IP address, use the
following script (I call it pppaddr):
ifconfig ppp0 | grep inet | cut -f 2 -d':' | cut -f 1 -d' '
I'd like to thank Darren Humphrey of Trainme, and various other members of the LEAP-CF mailing list, for that cool command.
The reason I've discussed this error and the route and ifconfig diagnostic tests is because this error is extremely hard to track if you don't know its root cause. Now we'll continue to configuring your kppp:
Select the correct modem device, and unless the ISP doesn't have hardware flow control (or unless your modem is ancient and can't handle hardware flow control), choose CRTSCTS for flow control. Line termination typically defaults to CR, with other choices LF and CR/LF. Take the default for the time being, and you might want to change it (typically to CR/LF) if things don't work, especially if you don't get an OK response to an AT command.
The connection speed is NOT NECESSARILY the speed of your modem. Modern communications involves data compression, meaning that if your modem is really operating at 56K and uncompressing into your serial port, your serial port could easily be getting twice as much data as the 56K would imply. Modern serial ports based on the 16550 UART chip or better can do 115,200bps, which is why the connection speed is set at that. If your serial ports use the older 8250a or 16450 UARTs, you'll need to set it down. For troubleshooting purposes you may wish to temporarily set down even a 16550 or better based serial port, but once the problem is fixed you should be able to set it up to 115,200 again.
Leave the lock file checkbox checked so another device can't grab the serial port while the connection is on, and 60 seconds is a good modem timeout figure.
The best procedure is probably to start by clicking the query modem button, which returns various strings from the modem that help you identify the modem. Next, use the terminal, starting by typing AT, to which the modem should respond OK. Other diagnostic steps are discussed later in this article. Finally, define the modem commands to the best of your ability. If you have documentation for your modem be sure to read it and define the strings as appropriate.
The first thing that happens after you enter this screen is that the status area at the bottom of the screen says "initializing modem". A few seconds later it will either report "Modem Ready" or "Sorry, the modem doesn't respond". The latter likely means one of three things:
Once you get a good initialization you'll probably see an OK get printed on your screen. Now try typing AT and then the Enter key. If everything's as it should be (and usually it isn't at first :-), you'll see the AT, then on the next line you'll see the modem respond with OK. As mentioned, if you don't get either, check to make sure you've got the right serial port on the device tab. If you don't see the AT that you type, but the modem does repond with an OK, you don't have local echo. Type ATE1 and then Enter, and from then on you should start seeing the echo. Also experiment with the line termination on the device tab screen. Occasionally problems require you to flip the little pin switches on the modem, but that should be a last resort. If the modem works elsewhere, chances are you don't need to flip the switches. If you do flip the switches, make sure you first write down their initial configuration!
Once you can get an OK back from the modem, try for a dial tone. Type ATDT and then Enter, and you should get a dial tone. If you don't check to make sure that the Modem Volume control on the modem screen is not set to silent, make sure it's got the right volume command (my kppp for my modem defaulted the loud command to an illegal one). Make sure your modem's telco connection is connected to a known good working phone line, and that nobody is talking on that line. Substitute a phone for the modem and verify you get tone.
Once you can get tone the next step is to dial your ISP. Simply type ATDT and then the ISP's phone number, followed by the Enter key. The modem should dial, and then you should hear the typical whistles of a modem negociation. With most ISP's you'll obtain a prompt for username, and then one for password. Put in the correct values, pressing Enter each time. Remember, on username and password case is important.
Some ISP's need a Ctrl-C to put them in the mode necessary to send you
a username and password prompt. Try that. Also, some ISP's can only to
PAP or CHAP and hence don't send human readable prompts for username and
The Dial screen describes dialup procedures for your ISP, including a name (in case you have multiple ISP accounts or phone numbers), the phone number, the authentication type which can be PAP, CHAP, login script or terminal emulation.
Terminal emulation means at the proper moment a terminal program pops up with the ISP's actual interface. In my opinion this is too manual to be useful, and should be avoided. PAP is very widespread, simple to use and configure, so it's what's described here. CHAP is an authentication scheme somewhat similar to PAP, but from what I understand more secure. Login script is an chat script with responses necessary to log into the ISP.
For best security, do not check the Store password checkbox. However, if you have sole access to the computer and don't feel anyone else is capable of accessing it, even via VNC across the net, your life is simpler if you check it. Also, if you use a different password for this than others, checking it prevents you accidentally typing in a differnent password (like the one for your online bank account), thereby inadvertently disclosing it.
My experience (your mileage may vary), is that the Execute Program fields do not work as advertised, so I've left them blank. Theoretically (though I could not get this to happen), one could use them to restore a default route after disconnecting. I was unable to accomplish this.
The Arguments button enables you to input custom arguments to the pppd daemon, and is discussed next.
The kppp documentation says that you should not check Auto-configure
hostname from IP unless you know what you're doing and have a darned good
reason, so I didn't try it. I found it unnecessary for a good and reliable
I did something different. I have a running DNS server on my desktop (it's a slave DNS to my main Linux server's master DNS server). My DNS has the typical caching file, so it can send DNS resolution requests up the DNS tree. As my computer obtains resolutions for specific domains, it stores them in a local cache, which is *much* faster than even cached resolutions on the ISP's DNS servers. The result is that on the 80% of domains I hit regularly, lookup is almost instantaneous. On the 20% I don't regularly visit resolution is about 5 seconds, give or take. I like it that way. By not checking Disable existing DNS Servers during Connection, my Internet DNS lookups get done by my caching DNS on my desktop machine.
You might wonder why I don't also enable my ISP's DNS server IP's so that on the 20% seldom used domains I get a quick response directly, while on often used domains I get my instant cache. Doesn't work! What the DNS address list really does is get temporarily appended to my /etc/resolv.conf list of DNS servers. Since it's appended rather than prepended, that means my local caching DNS will do the work anyway. Even if you find a way to prepend, instead of appending, the DNS address list, it would nullify the advantages of the local caching.
To the best of my knowledge, the Domain name: field should contain the
*local* domain in which your desktop computer resides. My office LAN is
at domain.cxm (192.168.100.0/24) for handy documentation.
Remember, what this screen is used for is to change your /etc/resolv.conf for the life of the connection, and restore it to its pre-connection state upon disconnection.