Troubleshooting Professional Magazine
Copyright (C) 2000 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

Webmasters:
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:
http://www.troubleshooters.com/tpromag/200006/200006.htm#_kppp

[ Back to the June 2000 Troubleshooting Professional Magazine ]

Your Linux Desktop Internet Connection

By Steve Litt

A computer's not much good without an Internet connection. This article is designed to show you how to connect your Linux box to the 'net, and to give you enough theory to troubleshoot any problems you might encounter.

Hitting Your Modem

Before you test your Internet connections, you'll probably want to verify that you can interact with your modem from your Linux keyboard and monitor. This ONLY tests the modem. It does not test authentication or data, and it certainly doesn't test your PPP system for TCP/IP to serial conversion.

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 Configuration

This section is designed to make it easy to get on the net with kppp. The kppp program is similar to Windows' "dial up networking", except it incorporates the modem rather than having the modem as a separate module. This is one case where Windows is more modular than Linux.

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.

Watch Out for the "Remote System Can't Authenticate" Error

This is an error that's very hard to troubleshoot. So I'll tell you the root cause right now.

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.

The pppd daemon died unexpectedly! KPPP could not prepare a PPP log. The debug option has been added. The remote system is required to authenticate itself but I couldnt find any secret (password) which would let it use an IP address.

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]#

In the preceding, note the default route (destination 0.0.0.0) 192.168.100.1. That default route must be removed before kppp will work correctly. The command to use is:

/sbin/route del default

The 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 114.1.1.1 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 114.1.1.1 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:114.37.3.191 P-t-P:114.1.1.1 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:

The kppp Initial Screen

On a typical KDE equipped system you obtain the kppp initial screen by choosing start:internet:kppp from the menu system. The main use of this screen is to connect to your IPS (by clicking the connect button). But you can also click the help button to get a online docs for kppp, and you can click the setup button to set up your online commmunications.

When you click the setup button you're brought to the kppp configuration screen, which is discussed next.

The kppp Configuration Screen

The kppp configuration screen is your center of operations for all Internet connection configuration. Broadly speaking, there are two categories of Internet connection configuration: ISP account setup, which is accessed by choosing an account on the Accounts tab, and local host setup, which is configured with the Device, Modem and PPP tabs. The graph and about tabs are not discussed in this article, and can usually be safely ignored.

In the preceding screen, clicking the Device tab brings up the device configuration screen. Read on.

The kppp Device Screen

This is where you configure the computer port connected to the modem. It's typically a serial port, /dev/ttyS0 for the first serial port (com1 in the DOS world), or /dev/ttyS1 for the second serial port (com2 in the DOS world). It could also be /dev/modem, which is typically a symbolic link to the actual serial port. If you're using DSL you'd use a different device.

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 kppp Modem Screen

This is the screen you use to define the modem, with its commands and startup. Because this is often the most challenging part of any connection, it also gives you buttons to query the modem for its information, and to bring up a terminal with which you can manually throw modem commands at the modem and see how it responds.

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 kppp Modem Query Screen

This screen appears a short time after you click the Query Modem button on the modem screen. Before this screen appears, you should see your modem lights flashing (assuming you've taken my advice and used and external modem). After a second or so of the modem lights blinking, the modem query screen gets filled in. On the modem query screen, notice the ATI 3 string, which describes the modem. That can be important if you don't know what kind of modem you have. The rest of the strings can prove valuable in troubleshooting, but you'll need some advanced modem documentation to use them.

The kppp Modem Terminal Screen

This screen appears after you click the Terminal button on the modem screen. This is a diagnostic terminal emulator you can use to send commands to the modem and see what the modem returns. Do not attempt to go further until you can use the kppp Modem Terminal Screen to operate your connection manually.

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:

The init string defined in the modem commands screen is wrong.
You're hitting the wrong com port -- try switching between /dev/ttyS0 and /dev/ttyS1.
Your modem is not powered up or your serial cable doesn't connect the modem to the serial port on the computer.

The first explanation is unlikely because kppp defaults the reset string to ATZ, which is pretty standard for most modems.

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 password.

The kppp Modem Commands Screen

The modem terminal and modem query screens are diagnostic tools designed to ease your completion of this form, the Modem Command Screen. It's fairly self-explanetory. To the extent possible, try to use the kppp defaults. When changing anything, make a record of it so you can "put it back". Before changing anything, verify the need in the terminal screen.

The kppp PPP Screen

The PPP screen configures kppp itself. What happens when the connection is successful? Do you leave kppp up after disconnection? My observation so far is that this screen involves primarily cosmetics.

The kppp Dial Screen

When you click the Accounts tab on the preceding several screens, highlight one of the accounts in the list (there may be only one), and click the edit button. You're then brought to the Edit Account dialog box, with tabs titled Dial, IP, DNS, Gateway, Login Script, and accounting. The distinction between this dialog box and the screens previously discussed is that all the tabs on this dialog box describe your ISP's configuration, whereas the screens previously discussed describe your desktop computer's configuration.

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 PPP Arguments Screen (accessed through dial screen)

You can pass arguments to the pppd daemon through this screen by typing the arguments in the text box and clicking add. My experience is that when you use PAP this is unnecessary, because kppp automatically passes needed args to pppd, and does all the other little tasks necessary for correct running of the daemon and connection to the ISP.

The kppp IP Screen

Here's where you tell pppd (via kppp) whether the ISP gives you a dynamic IP or a static one, and if static you can put it in. Kppp is smart enough that it takes the dynamic address and issues a default route command to properly enable routing.

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 connection.

The kppp DNS Screen

Ahhh, DNS. Can't live with it, can't live without it. READ THIS TEXT CAREFULLY, as the screenshot I've given does not reflect the typical desktop situation. In the typical desktop situation you'd have the primary and secondary DNS IP that your ISP gave you inside the DNS Address list, and you'd check Disable existing DNS Servers during Connection. Doing the typical desktop configuration of this screen would make its DNS just like that in Windows dialup networking.

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.

The kppp Gateway Screen

When cruising the 'net, you must use your ISP's box as your default gateway. How else could you get the correct routing for absolutely any URL on the 'net. To do this simply select "Default Gateway" and check "Assign the Default Route to this Gateway". The latter causes kppp to issue a route command installing a route to the ISP's box for the life of your connection.

The kppp Login Script Screen

Don't use this unless you choose to use Login Script authentication. Leave it blank for PAP or CHAP auth. If you use a logon script, simply make all the Expect strings identical to your ISP's prompts and messages, and your Send strings what you'd send to such prompts and after such messages.

Steve Litt can be reached at Steve Litt's email address.

[ Back to the June 2000 Troubleshooting Professional Magazine ]