28.4 Troubleshooting PPP Connections

Contributed by Tom Rhodes.

Warning: As of FreeBSD 8.0, the uart(4) driver replaces the sio(4) driver. Device nodes for serial ports have been renamed from /dev/cuadN to /dev/cuauN and from /dev/ttydN to /dev/ttyuN. FreeBSD 7.X users will have to adapt the following documentation according to these changes.

This section covers a few issues which may arise when using PPP over a modem connection. For instance, perhaps you need to know exactly what prompts the system you are dialing into will present. Some ISPs present the ssword prompt, and others will present password; if the ppp script is not written accordingly, the login attempt will fail. The most common way to debug ppp connections is by connecting manually. The following information will walk you through a manual connection step by step.

28.4.1 Check the Device Nodes

When using a custom kernel, make sure to include the following line in your kernel configuration file:

device   uart

The uart device is already included in the GENERIC kernel, so no additional steps are necessary in this case. Just check the dmesg output for the modem device with:

# dmesg | grep uart

You should get some pertinent output about the uart devices. These are the COM ports we need. If your modem acts like a standard serial port then you should see it listed on uart1, or COM2. If so, you are not required to rebuild the kernel. When matching up sio modem is on uart1 or COM2 if you are in DOS, then your modem device would be /dev/cuau1.

28.4.2 Connecting Manually

Connecting to the Internet by manually controlling ppp is quick, easy, and a great way to debug a connection or just get information on how your ISP treats ppp client connections. Lets start PPP from the command line. Note that in all of our examples we will use example as the hostname of the machine running PPP. You start ppp by just typing ppp:

# ppp

We have now started ppp.

ppp ON example> set device /dev/cuau1

We set our modem device, in this case it is cuau1.

ppp ON example> set speed 115200

Set the connection speed, in this case we are using 115,200 kbps.

ppp ON example> enable dns

Tell ppp to configure our resolver and add the nameserver lines to /etc/resolv.conf. If ppp cannot determine our hostname, we can set one manually later.

ppp ON example> term

Switch to “terminal” mode so that we can manually control the modem.

deflink: Entering terminal mode on /dev/cuau1
type '~h' for help

Use at to initialize the modem, then use atdt and the number for your ISP to begin the dial in process.


Confirmation of the connection, if we are going to have any connection problems, unrelated to hardware, here is where we will attempt to resolve them.

ISP Login:myusername

Here you are prompted for a username, return the prompt with the username that was provided by the ISP.

ISP Pass:mypassword

This time we are prompted for a password, just reply with the password that was provided by the ISP. Just like logging into FreeBSD, the password will not echo.

Shell or PPP:ppp

Depending on your ISP this prompt may never appear. Here we are being asked if we wish to use a shell on the provider, or to start ppp. In this example, we have chosen to use ppp as we want an Internet connection.

Ppp ON example>

Notice that in this example the first p has been capitalized. This shows that we have successfully connected to the ISP.

PPp ON example>

We have successfully authenticated with our ISP and are waiting for the assigned IP address.

PPP ON example>

We have made an agreement on an IP address and successfully completed our connection.

PPP ON example>add default HISADDR

Here we add our default route, we need to do this before we can talk to the outside world as currently the only established connection is with the peer. If this fails due to existing routes you can put a bang character ! in front of the add. Alternatively, you can set this before making the actual connection and it will negotiate a new route accordingly.

If everything went good we should now have an active connection to the Internet, which could be thrown into the background using CTRL+z If you notice the PPP return to ppp then we have lost our connection. This is good to know because it shows our connection status. Capital P's show that we have a connection to the ISP and lowercase p's show that the connection has been lost for whatever reason. ppp only has these 2 states. Debugging

If you have a direct line and cannot seem to make a connection, then turn hardware flow CTS/RTS to off with the set ctsrts off. This is mainly the case if you are connected to some PPP capable terminal servers, where PPP hangs when it tries to write data to your communication link, so it would be waiting for a CTS, or Clear To Send signal which may never come. If you use this option however, you should also use the set accmap option, which may be required to defeat hardware dependent on passing certain characters from end to end, most of the time XON/XOFF. See the ppp(8) manual page for more information on this option, and how it is used.

If you have an older modem, you may need to use the set parity even. Parity is set at none be default, but is used for error checking (with a large increase in traffic) on older modems and some ISPs. You may need this option for the Compuserve ISP.

PPP may not return to the command mode, which is usually a negotiation error where the ISP is waiting for your side to start negotiating. At this point, using the ~p command will force ppp to start sending the configuration information.

If you never obtain a login prompt, then most likely you need to use PAP or CHAP authentication instead of the UNIX® style in the example above. To use PAP or CHAP just add the following options to PPP before going into terminal mode:

ppp ON example> set authname myusername

Where myusername should be replaced with the username that was assigned by the ISP.

ppp ON example> set authkey mypassword

Where mypassword should be replaced with the password that was assigned by the ISP.

If you connect fine, but cannot seem to find any domain name, try to use ping(8) with an IP address and see if you can get any return information. If you experience 100 percent (100%) packet loss, then it is most likely that you were not assigned a default route. Double check that the option add default HISADDR was set during the connection. If you can connect to a remote IP address then it is possible that a resolver address has not been added to the /etc/resolv.conf. This file should look like:

domain example.com
nameserver x.x.x.x
nameserver y.y.y.y

Where x.x.x.x and y.y.y.y should be replaced with the IP address of your ISP's DNS servers. This information may or may not have been provided when you signed up, but a quick call to your ISP should remedy that.

You could also have syslog(3) provide a logging function for your PPP connection. Just add:

*.*     /var/log/ppp.log

to /etc/syslog.conf. In most cases, this functionality already exists.