Craig's Linux Notes: Installing SBC/PacBell DSL on Linux

Last modified: 01/01/2007

Disclaimer: I do not work for SBC/PacBell and they did not authorize me or ask me to write this. If you have problems with this page, don't complain to them. Complain to me. My e-mail address is at the bottom of the page.

Upgrading to SBC/Yahoo!
Rather than upgrade to SBC's new Yahoo offering, I switched my ISP to DSL Extreme. For details about why, read below. To read on my further adventures with DSL Extreme, click here.

Contents

Introduction
Escape from SBC Global
Resources
Hardware
Software Installation
Internet Configuration Wizard (internet-druid)
Kernel Drivers
PPP Client
PAP and CHAP
Starting eth0
Starting pppd
Security
Starting pppd with rp3
Speed Tweaks
Stability
Troubleshooting
Troubleshooting ip-up
E-Mail and Newsgroups
SBC/PacBell Web Space
Other SBC Services
Network Time Protocol (NTP) Server
DSL Reliability
Outages That Affected Me

Introduction

In December of 2001, I got tired of the low bandwidth of the conventional phone line (48 Kbs - kilobits per second) and I upgraded to DSL. Both my bandwidth and latency significantly improved. My bandwidth is now an average of 1.2 Mbs - 25 times faster than a 56K modem! I upgraded because I was changing the way I used my home internet connection. Before, I used it infrequently for occasional web and e-mail access with an occasional moderate sized download, and this was acceptable at 48 Kbs (and $30/month cheaper each month). Now, I do significantly more work from home, and I wanted to collaborate on some open source projects (read: unemployment), and I knew that 48 Kbs wasn't going to cut it.

I chose SBC/PacBell as my DSL provider: the price was reasonable, and at the time, my alternate choice (SpeakEasy.net) could not provide a cost-effective connection to my house. Unfortunately, SBC/PacBell does not offer support for Linux, which means that the instructions and software they sent were for MS or Macintosh operating systems, and I was on my own.

Escape from SBC Global

Everything was working fine with SBC Global until they decided to partner with Yahoo. They sent me an e-mail in December of 2002 inviting me to "upgrade" with their browser-based upgrade tool. It didn't work with any of the many Linux browsers I could get my hands on. Their tech support tried to be helpful, but it wasn't their job to change their web site nor support Linux. Months later, their web site still did not work for me, and I reviewed the details of their new plan. I had gripes with it.

My gripes (detail):

  1. Their new plan includes free web hosting, but with GeoCities, notorious for inserting their own advertising onto other people's web pages. GeoCities already offers free web hosting, so I wondered what I was actually paying for. Nothing, it turns out. The service they were offering to me was, as they call it, not "ad-free". (To their credit, they did offer many megabytes of on-line storage for photo albums. But I am not interested in that service.)
  2. Their terms of service states that they own all content on any web page that any user posts on their site forever. And they may modify and redistribute it. Meaning that the web page you are reading now would belong to them. This isn't much of a page, I know, but the principle really offended me. Refer to SBC/Yahoo Terms of Service, Section 11 "Content Submitted", subsection "Grant of License". Beware!
  3. Their price remained the same, $50/month, even though they were offering new users $35/month. How come they did not extend this offer to me? As I was cancelling my service, their representative told me, "Well, I could have lowered your price." Sorry, wrong time to make the offer.
So I switched to another provider: one with genuine web hosting, less avaricious service terms, less expensive, and they support Linux. Click here to read further.

Resources

Note: All of the stuff below is old hat. Ha! "Red Hat", "old hat" -- get it? That's a good one. Anyway, modern installations, either RedHat or Gentoo, have little problem using DSL modems. So unless you are using an old version of Linux, PPP is broken, or have nothing better to do ... what are you doing here?

My DSL ISP is SBC/PacBell. The following web pages were useful references. The first two were most relevant to my situation.

Also helpful:

Despite these excellent resources, I found myself taking notes and having to figure things out, as none of these sites describes my exact situation. These notes are intended to help me diagnose my system in case I have a problem in the future, and perhaps they help you, also.

Hardware

System: x86 PC
Ethernet card: D-Link DFE-530TX+
  • Included in the DSL kit sent by SBC.
  • The driver for the DFE-530TX+ is 8139too.o.
  • The card was automatically recognized by the operating system.
DSL Modem: Efficient Networks 5360 (external)
  • Included in the DSL kit sent by SBC.
  • The Efficient Networks DSL modem takes a while to initialize itself. I was initially fooled into believing it was defective because I plugged in the power and all the lights lit up green - with no phone or Ethernet plugged in! The manual advises waiting upto 2 minutes after plugging it in.
  • Once the modem has initialized, it takes approximately 2 seconds to log in to the SBC network.
  • SBC uses PPPoE.

Software Installation

Red Hat LogoWhen I first signed up for DSL service, my system was running Red Hat 7.1 (kernel 2.4.2), which does not support DSL all that well. If you have the means, I suggest upgrading to Red Hat 7.2 (kernel 2.4.9) which offers much better support.

If you have a different OS version from me:

Internet Configuration Wizard (internet-druid)

RedHat 7.3 comes with a new Internet configuration utility called internet-druid. Find it here: Main menu > Programs > System > Internet Configuration Wizard.

If you don't have your DSL connection configured yet, it is worth using this utility. It worked for me (could be because my network scripts were already configured?).

The rp3 dialer is a convenient way to start and stop the network connection. Add it to your menu panel with Main Menu > Panel > Add to Panel > Applet > Network > RH PPP Dialer.

Note: Version 1.0.0-1 of the configuration wizard has a bug where it misconfigures timeout, insuring frequent network disconnects. To address this problem, edit the file /etc/sysconfig/network-scripts/ifcfg-interface, where interface is the name you gave to the new interface. Modify the PPPOE_TIMEOUT value to be four times larger than the LCP_INTERVAL value (in my case, I changed it from 20 to 80). This is filed as Red Hat Bug 74388.

That should do it! If you have an earlier system, or are having problems getting the thing to work, read on.

Kernel Drivers

The PPP driver in the 7.1 kernel does not support PPPoE. You need to either (a) rebuild the kernel with the PPPoE driver, or (b) compile the PPPoE driver as a module and dynamically load it into the kernel. I chose the first option because the I had trouble compiling the drivers as modules (note: probably due to a different kernel version number added to the modules I compiled myself. PPPoE support is included in the 7.3 kernel, so no recompilation is needed).

  1. Install the kernel sources. Mine were kernel-source-2.4.2-2.i386.rpm. Read the Kernel How-to before you proceed.
  2. Copy one of the configurations in the configs subdirectory to ".config". This file will contain your configuration in case you want to add something later, so perform the copying step only once.
  3. Run "make xconfig" and load the new configuration file. Set:
  4. "Save and Exit".
  5. Run "make dep".
  6. Run "make clean".
  7. Run "make bzImage" (takes a while).
  8. "cd /boot" (or where ever your boot partition is).
  9. Rename "vmlinuz-2.4.2-2" to "vmlinuz-2.4.2-2.original" in case you have to recover (now would be a good time to have Tom's Root Boot handy).
  10. Copy "/usr/src/linux-2.4.2/arch/i386/boot/bzImage" to "vmlinuz-2.4.2-2".
  11. Run "lilo".
  12. Reboot.
  13. Run "depmod -a".

PPP Client

The standard ppp daemon does not support PPPoE, either. Download the source from Michal Ostrowski's PPPoE page. Build according to Michal's instructions, summarized here:

  1. Run "./configure".
  2. Run "make".
  3. As root, run "make install".
  4. Create the "/etc/ppp/options" file and put into it:
      5. lock
      plugin pppoe.so

PAP and CHAP

PPP authenticates with either the PAP or CHAP protocols. CHAP is more secure because it does not transmit passwords, however it seems that SBC uses only PAP. This does not overly concern me, as the password is transmitted only within SBC's network, not over the Internet.

To establish my initial connection, I used the initial account supplied by SBC. The account name and password are shown in SBC's "after your hardware is installed" instructions under the "Macintosh registration" section. This account seems to permit access to SBC's internal network only, and not to the Internet at large. The entry in my /etc/ppp/pap-secrets file looks like this: 

dslreguser    eth0    reguser

After successfully connecting and creating my SBC account, I added this line to my pap-secrets file:

my-account@sbcglobal.net   eth0   my-password

I used mkpasswd to make a hefty mess. I also put the same line in my chap-secrets file just in case SBC switches to CHAP in the future (you can force CHAP authentication with the "refuse-pap" option when starting pppd).

Both files should be readable only by "root" (make the permissions the same as for "/etc/shadow").

Starting eth0

Start eth0 with "ifconfig eth0 up". Verify that eth0 is up with "ifconfig". It should show something like:

eth0  Link encap:Ethernet  HWaddr 00:50:BA:AF:F6:A0
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      ...

If the second line shows an IP address, you have a problem.

To start eth0 at boot, put the following into "/etc/sysconfig/network-scripts/ifcfg-eth0":

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

Starting pppd

Start pppd with the command (all on one line):

pppd eth0 name dslreguser \
     usepeerdns defaultroute \
     ipparam ppp0 \
     nodetach debug

(It seems that when using PPPoE, pppd assumes the link name will be "ppp0", and I was unsuccessful trying to override its choice. If you have an existing configuration for ppp0, such as for a conventional phone line, rename these files now so they will not conflict.)

You should see output like this, and the connection should establish within a few seconds (notation in italics):

Plugin pppoe.so loaded.
PPPoE Plugin Initialized
  Client initialized; begin kernel init
Sending PADI
HOST_UNIQ successful match
HOST_UNIQ successful match
Got connection: 23e
Connecting PPPoE socket: 00:10:67:00:b5:6a 3e02 eth0 0x807db48
using channel 5
Using interface ppp0
Connect: ppp0 <--> eth0
Couldn't increase MTU to 1500.
Couldn't increase MRU to 1500
  Kernel driver initialized; establish connection with peer.
  The MTU and MRU are limited to 1492 (see the DSL HOWTO).
sent [LCP ConfReq id=0x1 <magic 0x6df8503b>]
rcvd [LCP ConfAck id=0x1 <magic 0x6df8503b>] 00 ...
  Peer has been signaled that someone is trying to establish
  a connection. Notice that the reply message from the peer
  has the same id and magic values as the original request.
  The reply does not always immediately follow the request.
rcvd [LCP ConfReq id=0x94 <mru 1492> <auth pap> <magic 0x13de4ba0>] 00 ...
sent [LCP ConfAck id=0x94 <mru 1492> <auth pap> <magic 0x13de4ba0>]
  Peer requested PAP authentication, and local system
  acknowledged request.
Couldn't increase MRU to 1500
sent [PAP AuthReq id=0x1 user="dslreguser" password=<hidden>]
rcvd [PAP AuthAck id=0x1 ""] 00 ...
  Local system sent authentication data, and the peer accepted it.
  If the user or password were incorrect, the peer would respond
  with AuthNak, and would then terminate the connection.

  The local system then requests addresses for DNS's,
  runs the /etc/ppp/ip-up script,
  and then is quiet except for occasional keep-alive messages.

Confirm the connection with the following:

  1. Run "ifconfig". It should show eth0 as before, and should also show something like this for ppp0:
    2. ppp0  Link encap:Point-to-Point Protocol
          inet addr:64.175.243.235  P-t-P:64.112.203.254  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          ...
  2. Run "ping" to the "P-t-P" address shown on the second line above. For my connection , ping were in the range 4-15 msec.
  3. Verify the route tables with "route -n". Output should look something like this. Notice the two entries for ppp0: one has the P-t-P address in the "destination" column, and the other has the same address in the "Gateway" column (missing these? Got the "defaultroute" option?)
    4. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    67.112.203.254  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
    127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
    0.0.0.0         67.112.203.254  0.0.0.0         UG    0      0        0 ppp0
  4. Verify that your local system received DNS addresses by checking the contents of the file "/etc/ppp/resolv.conf". There should be at least one line beginning with "nameserver" and containing an IP address (missing this? Got the "usepeerdns" option?)
  5. Verify gateway functioning by trying to ping one of the DNS addresses. "Network unreachable" means something is wrong with the route table.
  6. Verify domain name server operation by trying to look up a name. Try "host www.sbcglobal.net". If you fail to get an acceptable response, try "host www.sbcglobal.net dns-address". If this works, then you have a resolver problem. Compare your "/etc/resolv.conf" and "/etc/ppp/resolv.conf" files - if they are not similar, you need to debug your "ip-up" script operation. See Troubleshooting ip-up below. (Got the "ipparam ppp0" option?)
  7. At this point, you should be able to start your web browser and follow SBC's registration instructions. It seems, however, that when you authenticate as "dslreguser" you are blocked from accessing sites outside of the SBC network, so you will not be able to visit sites on the Internet.
  8. After registering, add your account info to the pap-secrets file (see PAP and CHAP above).
  9. Disconnect and then reconnect with the pppd option "name my-account@sbcglobal.net" instead of "name dslreguser". SBC warns that it may take upto 2 hours for this to work following initial registration. For me it was less than 10 minutes.

That's it!

Security

Read the com.os.linux.security FAQ. Do what it says. I'm not giving details of how my system is protected, except to say that it is. OK, I'll give some details: read this.

I disconnect my system from the network when I am not using it. Currently, my system has no business accessing the Internet when I am not present. See the following section: Starting pppd with rp3.

Starting pppd with rp3

I decided that I do not want a full-time DSL connection. Nervous about crackers. Rather, I wanted to manually control my connection. I was already familiar with the rp3 dialer and Gnome applet from using PPP over a conventional modem, and I wanted to use the same thing for DSL. Here's how:

  1. Create an empty file named "/etc/ppp/peers/ppp0".
  2. Create a file named "/etc/sysconfig/network-scripts/ifcfg-ppp0". Put the following into it:
    3. DEVICE=ppp0
    DEVNAME=ppp0
    NAME=DSL
    MODEMPORT=eth0
    USERCTL=true
    ONBOOT=no
    BOOTPROTO=none
    PERSIST=no
    HARDFLOWCTL=no
    DEMAND=no
    PPPOPTIONS="ktune user my-account@sbcglobal.net"
    PEERDNS=yes
    (Note the quotes used for PPPOPTIONS.)
  3. Add an rp3 applet to the panel (Main Menu > Panel > Add to Panel > Applet > Network > RH PPP Dialer). As part of the installation, it will present a list of interfaces. Select "DSL" from the list.
  4. Make sure pppd is not already running.
  5. Click the button to start DSL!

If the DSL connection does not start, then it is probably because incorrect options are being used with pppd. You need to figure out what they are. Use "ps aux", or, my current favorite, "pstree -lp" to find the pppd process ID. Then review the command line arguments in /proc/pid/cmdline. Try them yourself on the command line.

Note: the rp3 dialer broke with Red Hat 7.2. Seems to be fixed in Red Hat 7.3.

Speed Tweaks

According to DSL Reports, speed tweaks seems to be a favorite topic for Windows systems. I did not modify any settings on my system. According to the speed test at DSL Reports, my connection "rocks!" According to their bandwidth evaluation test, my TCP receive window (RWIN) is way too large: currently 63,360, and they recommend between 14,520 and 37,752. However, my system has all of the latest protocol tweaks enabled by default, including one that automatically sizes the receive window, so I left it alone.

My understanding of the receive window is that too large a window can increase overall transfer time because of excessive resends in the case of data corruption. But during the test there were no resends, so my connection looks pretty clean. Also, I went to another site, downloaded a 10 Mb file, and averaged 1.2 Mbs, 80% of the maximum bandwidth. Plenty fast, so I'm not worried about my receive window.

Stability

The PPPoE kernel driver is experimental. The morning after first using it, I found my system crashed. Coincidence? Time will tell.

... time passes ...

Prodigy's web site complained about my old Netscape 4.5 browser, so I upgraded to Netscape 6.2.1. Then the misery started. Since then, X has crashed several times. That's really what I'm complaining about. PPPoE, on the other hand, has been solidly reliable.

Note: With Red Hat 7.3, I am still using Netscape 6.2. Apart from slowly consuming ever increasing amounts of virtual memory, it has been pretty reliable.

Troubleshooting

Troubleshooting ip-up

After pppd establishes a connection, it invokes the /etc/ppp/ip-up script, which in turn invokes the /etc/sysconfig/network-scripts/ifcfg-ppp0 script, which in turn configures the /etc/resolv.conf file necessary for the resolver to work. If the parameters passed to the ip-up script are incorrect, the resolv.conf file will not be configured correctly. You can verify the parameters by creating an other script called "/etc/ppp/ip-up.local" with the contents:

#!/bin/bash
# Saves arguments in a file for debugging.
( echo "n-args: $#";
  echo "iface-name: $1";
  echo "tty-dev: $2";
  echo "speed: $3";
  echo "local-ip-addr: $4";
  echo "remote-ip-addr: $5";
  echo "ipparam: $6";
  echo "all: $@"; ) > /etc/ppp/local.params

Verify that pppd is invoking the ip-up script (it will tell you so when invoked with the "debug" option), then look in the file "/etc/ppp/local.params". There should be 6 arguments.

E-Mail and Newsgroups

When you create a new account with SBC, you will be given the names of several SBC servers. Write them down somewhere. To access e-mail, your account name is "my-account@sbcglobal.net" - that's right: "@sbcglobal.net" is part of the name.

SBC/PacBell Web Space

SBC/PacBell DSL is supposed to come with 15 Mb of web space - where was it? They had not given me a URL for my page. I visited the SBC/PacBell main page and their help page looking for clues. My web space was not evident.

Finally found it. My main URL is "http://pages.sbcglobal.net/my-account /index.html". Use Prodigy's "Building Blocks" web page creator at http://pages.sbcglobal.net to create an initial page and/or FTP to pages.sbcglobal.net and use the account name "my-account@sbcglobal.net".

Other SBC Services

Network Time Protocol (NTP) Server

July 2006: Servers named below are no longer available.

SBC claims they don't have an NTP server. Won't admit it, in any case. Regardless, an alert reader found it using the following steps. The server is named "ntp.pbi.net" and is stratum 3. Access is currently open (at least to customers on their internal network), though someday it may not be.
  1. dig sbcglobal.net NS gives the names of SBC's public name servers, currently ns1.swbell.net and ns1.pbi.net
  2. Guess the name ntp.pbi.net
  3. Confirm with ntptrace ntp.pbi.net
  4. Confirm access with ntpdate -dq ntp.pbi.net
(Use ntpdate in an IP scanning script to see which machines within specific IP ranges respond.) Alternatively, use one of the public NTP servers listed on the NTP web page instead. Stratum 2 is probably just fine for a DSL connection. For details on setting up NTP, see my clock notes.

DSL Reliability

A friend of mine used SBC DSL for a while, and had a terrible experience with them. So they were not my first choice. But I went with them anyway, as my other options were far less attractive. And the service has been very reliable and consistent. No complaints from me! (except for not supporting Linux).

The advice she gave to me was to not be tempted by SBC's occasional introductory offers. In my case, I was paying $50/month for the DSL, and a few weeks after my service was turned on, they called me and asked whether I was interested in receiving DSL for an introductory low price of $30/month for several months. As I already had a one year service contract with them, I declined. My friend later advised me that had I taken their offer, I would have entered the darkest circle of PacBell Hell, where service outages are rapid and remedy is unobtainable, from which there is no escape, save dumping their service altogether. Whew! Glad I gave it a miss.

Outages That Affected Me

Generally, the DSL has been very reliable. But after having DSL installed, I had some trouble with my regular voice phone service.

Copyright © 2002 Craig Lawson
Index no-thank-you-spam-i-am@i-hate-spam.spam.spam Document made with Nvu