After you have connected the modem and it's getting sync, then you're ready
to configure Linux and verify your connection to your ISP. Although I will
refer to a Linux System, you could conceivably connect any type of 10baseT
device to the modem. This includes a router, hub, switch, PC, or any other
system that you wish to use. We'll just cover the Linux aspects here.

Before you connect to your ISP, make sure you understand
all security issues of having a direct connection to the Internet via DSL.
Depending on your ISP, most outside users can access your system, and you
should setup any firewalls, deactivate ports/services, and setup any
passwords prior to connecting your machine to the world. See the Security section below, and the links section for more on this very
important topic. Do not make this an afterthought! Be ready.

Before we get too far into the final stages of installing and
configuring our system, let's look at how various DSL ISPs set up
their networks. It will be very important for you to know how your ISP does
this, as there is more than one possibility and the steps involved are quite
different for each. This may not be the kind of thing the ISP is advertising,
and since you are not using Windows, you may not have access to the setup
disk that the ISP provides. If you're not sure, ask the ISP's tech support
staff, or better, find other knowledgable users of the same service.

To muddy the waters even more, some ISPs may be offering more than one kind
of service (over and above the various bit rate plans). Example: Verizon
(formerly Bell Atlantic) originally offered static IPs with a Bridged
connection. Now all new installs use PPPoE with dynamic IPs. For installation
and configuration purposes, this is very different.

The two most common DSL network implementations are Bridged/DHCP and PPPoX.
Both have mechanisms for obtaining an IP address and other related networking
configuration details so we shouldn't have to worry about this. But there are
indeed other, less common, means of connecting. Our job will be finding the
right client, and doing what we have to, to get it up and running. The most
common ones are discussed below.

Important! You need to know beforehand how your ISP is
setup for connecting to his network. To re-iterate, the two main
possibilities are Bridged/DHCP and PPPoE. These are mutually exclusive
implementations. And there are indeed other possibilities as well. So you will
need to know exactly what this is beforehand. And it must be the right one or
you will waste a lot of time and effort. You cannot choose which one either.
It is a matter of how the ISP is doing his network. Note that PPPoE can run
over Bridged networks, so just knowing whether you are Bridged or not, is not
necessarily good enough. If your provider is giving you a router, there is a
good chance that the router's firmware will handle all of this for you.

If you are subscribing with one of the Baby Bells in the U.S., you can
count on that being PPPoE, and thus you will need a PPPoE client.

There are a few provider specific FAQs and HOWTOs in the Links section below.

In the good old days of a year or two ago, purely "Bridged"
connections were the norm. PPPoE had not been invented yet. This type of
network puts you on a local subnet just like a big LAN. You are exposed to
much of the local subnet traffic, especially ARP and broadcast traffic. The
typical means of authenticating in this set up, is via DHCP.

DHCP is a standard, established networking protocol for obtaining an IP
address and other important network parameters (e.g. nameservers). This is a
standard, well documented networking scheme and is very easy to set up
from the end user's perspective. It is also a very stable connection. You
can actually unplug the modem for say 10 minutes, plug it back in, let it
re-sync, and the connection is still there -- same IP and everything.

The main alternative now is PPPoX, meaning either PPPoE (PPP over Ethernet)
or PPPoA (PPP over ATM, aka PPPoATM). Both of these related protocols are
currently being deployed, but at the moment, PPPoE seems to be the more
common of the two. PPPoX is a relative newcomer, and, as the name implies, is
a variation of Point-to-Point Protocol that has been adapted specifically for
DSL networks.

There are several PPPoE clients for Linux (see
below). PPPoX simulates a dialup type environment. The user is
authenticated by user id and password which is passed to a RADIUS server,
just like good ol' dialup PPP. A routable IP address, and other related
information, is returned to the client. Of course, no actual dialing takes
place. The mechanics of how this is handled, will vary from client to client,
so best to RTFM closely. Typically you will set up configuration files like
pap-secrets, etc.

It is worth noting that PPPoE will also work on non-ethernet devices like USB,
provided the correct drivers are installed.

From the ISPs perspective, PPP is much easier to maintain and troubleshoot.
From the end user's perspective, it is often more work to set up, often uses
more CPU, and the connection is maybe not as stable. So anyway, this seems to
be the coming trend. Many of the large telcos around the world, especially
the RBOCs (Baby Bells) in the U.S., have committed to PPPoX already. Setting
up a PPPoX connection is completely different from setting up a bridged/DHCP
connection.

Since the traffic on the wire from the DSLAM to the modem is typically ATM, a
raw ATM connection would seem to make sense. While possible, this is rare, if
it exists at all in the U.S, and would require a modem in addition to a PCI
ATM card, such as the Efficient Networks 3010. Recent 2.4 kernels
do have ATM support. (See the Links section for
more information.)

This may be a viable solution at some point, but it is just not
"there" yet, mostly because this is more costly to implement.

The most common configuration is a DSL modem in "bridging" mode.
Both PPPoX and DHCP can use this setup. In this scenario, the WAN interface
typically means your NIC. This is where your system meets the outside world.
(If you have a router see below for router
specific instructions.) So essentially we will be configuring the NIC,
typically "eth0" since it is an ethernet interface.

With PPPoX, once the connection comes up, there will be a
"ppp0", or similar, interface, just like dialup. This will
become the WAN interface once the connection to the PPP server is up, but for
configuration purposes we will we be concerned with "eth0"
initially.

A "static" IP address is an IP that is guaranteed not to change.
This is the preferred way to go for those wanting to host a domain or run
some type of public server, but is not available from all ISPs. Note that
while there are some noteworthy benefits to having a static IP, the
disadvantage is that is more difficult to remain "invisible". It
is harder to hide from those with malicious intentions. Skip this section if
you do not have a static IP, or if you have a router, and the router will be
assigned the static IP.

Configure the IP address, subnet mask, default gateway, and DNS server
information as provided by the ISP. Each Linux Distribution (Redhat, Debian,
Slackware, SuSE, etc.) has a different way of doing this, so check on your
distro's docs on this. Each may have their own tools for this. Redhat has
netcfg for example. You can also do this manually using
the ifconfig and route commands. See
the man pages on these or the Net HOWTO for more
information and specifics. A quick command line example with bogus IPs:

ISPs that have Bridged networks typically use DHCP to assign an IP addresses,
and authenticate the user. All distributions come with one or more DHCP
clients. dhcpcd seems to be the most common.
pump comes with Redhat based distributions as of Redhat
6.0. The DHCP client will obtain an IP "lease" from the ISP's
server as well as other related information: gateway address, DNS servers,
and network mask. The lease will be "renewed" at regular
intervals according to the ISP's configuration.

You will want the DHCP client started on boot, so use your distribution's
means of doing this. There generally is little to configure with DHCP as it
is fairly straightforward and easy to use. You may need to tell it which
interface to listen on if the NIC is something other than
"eth0". You can also start it from the command line to get
started. See the respective man pages for more.

Unless you have a static IP, the ISP will need some way to know who you are
when you connect. There are two ways this authentication process is
accomplished with DHCP. The first and most common method is via the MAC (or
hardware) address of the network device. Typically this would be the NIC. The
MAC address is a unique identifier and can be found among the boot messages,
or with ifconfig, and looks something like
00:50:04:C2:19:BC. You will need to give the ISP the MAC
address before your first connection.

The other DHCP authentication method is via an assigned hostname. In this
case, the ISP will have provided you with this information. Your DHCP client
will need to pass this information to the server in order for you to connect.
Both dhcpcd and pump accept the
"-h" command line option for this purpose. See the client's man
page, or your distribution's documentation, for specifics.

Note

If your ISP uses MAC address authentication, and you change your network
device (e.g. NIC), you will need to register the new address with the ISP or
you won't be able to connect.

PPPoE (PPP over Ethernet) is an alternate way for ISPs to control your
connection, and is becoming increasingly popular with ISPs. Setting this up
is quite different, and may be a little more work than with static IPs or
DHCP above. Recent distro releases are now shipping PPPoE clients. If this is
not the case for you, then you will have to download one. Check any Linux
archive site like http://freshmeat.net, etc. or look below.

Some of the current GPL PPPoE clients available:

The Roaring Penguin (rp-pppoe): http://www.roaringpenguin.com/pppoe/,
by David F. Skoll. Reportedly very easy to set up, and get started with.
This is a popular Linux PPPoE clients due to it's reputation for ease of
installation, and is now being bundled with some distributions. rp-pppoe
works as a user-mode client on 2.0 and 2.2 kernels, and in kernel-mode
on 2.4 kernels.

PPPoEd: http://www.davin.ottawa.on.ca/pppoe/ by Jamal Hadi Salim is
another popular Linux client and is also bundled with some
distros. This is a kernel based implementation for 2.2 kernels. A setup
script is now included so no patching is required, making installation
quick and easy. Also, less CPU intensive than user space alternatives like
rp-pppoe (2.0/2.2 kernels).

PPPoE Redirector: http://www.ecf.toronto.edu/~stras/pppoe.html. This is a redirector
which allows the use of PPPoE with pppd-2.3.7 or later. No recompiling of
other system components are required. It is meant as an interim solution
until the 2.4.x series, which will include kernel support of PPPoE/A. (Does
not seem to be under active development at this time.)

2.4.x kernels include native PPPoE support. The PPPoE for 2.4 page is
http://www.shoshin.uwaterloo.ca/~mostrows
[link is dead, sorry, can't find new page] and is by Michal Ostrowski, the maintainer for kernel PPPoE. This
includes detailed instructions for installing and configuring kernel
mode PPPoE.

EnterNet is a non-GPL'd PPPoE client from NTS, http://www.nts.com, that is being
distributed by some ISPs as the Linux client. It does come with
source code but the it is not available for free download. (I haven't
found anyone that is impressed by this one.)

Depending on which client you have chosen, just follow the
INSTALL instructions and other documentation included
with that package (README, FAQ, etc.).

Once a PPPoE client connects, your connection should look something like the
below example from Roaring Penguin, where "eth0" is connected to
the modem:

PPPoE adds 8 bytes of extra overhead to the ethernet frames and the correct
initial maximum setting for the ppp0 interface MTU is 1492. If the MTU is
set too high, it may cause a fubar packet fragmentation scenario, known as
the Path MTU Discovery blackhole where the two ends of the connection fail
to communicate. A typical symptom would be the failure of some web pages to
load properly, and possibly other annoying problems. You may need to also
set the MTU for interfaces on any masqueraded LAN connections MTU to 1452.
This does not apply to PPPoA, bridged, or routed configurations, just PPPoE!
See rfc2923 for a technical explanation.

Actually, for PPPoE the real setting should be at least 8 bytes less (the
extra PPPoE protocol overhead) than any interface between you and the
ultimate destination. All routers normally would be set to 1500, thus 1492 is
correct from your end. But, it may happen that somewhere a router is
configured at a lower setting, and this can cause problems, especially
with web pages loading, and other traffic failures. The way to test this is
to keep dropping the MTU until things 'work'.

PPPoA (PPPoATM, or PPP over ATM) is a cleaner solution than PPPoE since most
of the work is done in hardware, and since the raw DSL traffic is ATM. There
is no user space client necessary to manage the connection as with PPPoE, and
the additional ethernet protocol layer is not required. Authentication is
still the same: user id and password to connect, but the mechanics are
different since no ethernet encapsulation takes place.

PPPoA is either done completely in hardware or is implemented as a device
specific driver. There is no such thing as a generic PPPoA software client
like there is for PPPoE. There is an ATM patch for 2.2 kernels, support for
ATM in the 2.4.x kernel, and a project based on the Efficient Networks 3010,
as well as other ATM cards. The ATM on Linux homepage is here: http://linux-atm.sourceforge.net/. And even more info is at http://www.sfgoth.com/~mitch/linux/atm/pppoatm/ from the kernel
developer of this project. Existing PPPoA implementations are hardware/driver
based, and Linux PPPoA modem drivers are scarce as hen's
teeth at this time. The above modem does not seem to be available through
normal retail channels. This may be a problem, if this is the only protocol
an ISP delivers, and an external modem that supports PPPoA is not available.

If PPPoA is your ISP's only option, you might consider one of the
router/modems that can handle PPPoA connections, and let the hardware handle
everything.

Alcatel SpeedTouch Home ethernet modems (supersedes the Alcatel 1000)
support both bridged and PPPoA connections. The modem itself handles the
PPPoA protocol internally. When in PPTP/PPPoA mode (as opposed to RFC1483 bridging
mode), Linux will connect to the modem via PPTP (MS VPN). The Linux PPTP
homepage is http://cag.lcs.mit.edu/~cananian/Projects/PPTP/,
and works well with this modem.
In addition to installing pptp, your kernel must also have support for PPP.

The modem has internal configuration pages than can be reached by pointing
a browser to the default IP address of http://10.0.0.138. (You will of course
have to have your NIC set up for a 10.0.0.0 network with similar IP such
as 10.0.0.1, in order to reach the modem's configuration pages.) For PPPoA,
the connection type is 'PPTP'. You will have to get the other settings from
your provider if the defaults do not work. Settings such as 'VPI/VCI' and
'encapsulation' can vary from provider to provider. Of course, if the modem
is coming from your provider, all this should be already configured.

The next step is to configure pptp, which is done by
configuring the pppd files
/etc/ppp/pap-secrets (or
chap-secrets) and /etc/ppp/options.
This is where the username and password is entered. For example:

/etc/ppp/pap-secrets:

# client secret server IP address
login@isp.com * my_password_here *

and /etc/ppp/options:

name "login@isp.com"
noauth
noipdefault
defaultroute

Once everything is configured properly, it should be just a matter of
starting pptp, pointing it to the modem's address:

#pptp 10.0.0.138

Note

Alcatel supplies many sub-models of these modems. These features may not be
available on all models, or may be altered from the defaults. This is
something to be aware of, if buying a used modem.

Some ISPs are providing "routers" as the connection device.
Essentially these are mini routers with built in modems. These are all
ethernet based devices too, so Linux should be good to go here as well.
Again, a compatible, working NIC should be all that is required to make this
work.

A "router" has many advantages. The better ones can handle the
connection management, IP encapsulation, and authentication, as well as
providing a means of segregating your LAN from outside traffic, and possibly
other features too. In short they can do it all. One big advantage is that
they can handle whatever protocols your ISP requires in order to connect.

If the ISP is requiring PPPoX, then this makes life a little easier since you
will not have to install or configure any additional software just to use
their network. The modem's firmware will handle this. The downside is that
most of these do not have the flexibility of a Linux router, or other
software solution. Of course, you could set up a Linux router behind the
router, and have the best of both worlds. The ones with more and better
features are also going to cost significantly more.

While the physical installation of a router is very similar to the modem
installation (see above), the router configuration itself is different
since your first "hop" will be the router's interface and not
the ISP's gateway. Routers will actually have two interfaces -- one that you
connect to from the LAN side, and one that connects to your ISP on the WAN
side. Your point of exposure here is the WAN interface of the router.

The router will also have a pre-configured, private IP address that you will
connect to from the LAN side. This will be your gateway. The public IP
address will be assigned to the WAN side interface. Typically these devices
also act as DHCP servers for the LAN side as well. So possibly all you have
to do is to start a DHCP client such as dhcpcd or
pump (Redhat based distros) to get up and running. Just
make sure the modem/router is syncing first. The appropriate steps and
configuration should be in the owner's manual, or available from your
provider.

If you are a PPPoX customer, and the router is handling this part of the
connection, then you will have to configure at least your user id and
password before connecting. If a Bridged/DHCP customer, you should just have
to activate DHCP on the router, and possibly register the MAC (hardware
address) of the router with your provider. Some routers have "MAC
cloning" which means that they will report the MAC address of the
attached NIC. If static IP, then you will have to configure this as well.

If you need to access the router directly, you will need to know the
manufacturer's default setting for its IP address. See the owner's manual, or
ask your provider. You will then have to set your NIC's interface to the same
network as the router. For instance, if the router has an IP of 10.0.0.1, set
your interface's address to 10.0.0.2 (typically eth0), and netmask to
255.0.0.0.

If everything is in working order, the router should respond to pings. How to
configure this permanently will vary from distro to distro. So check your
distribution's documentation. Now you should be able to ping the
modem/router, and, if all is well, beyond. Then use telnet or a web browser
to do any further configuration of the router.

Even if the ISP is not offering any router options, there are quite a few
available from third party manufacturers such as Netgear, Linksys, Cisco,
Zyxel, Cayman, Alcatel and others. These will have all the features already
mentioned and maybe more. Just make sure it matches your provider's DSL. This
is one good way around the PPPoX bugaboo.

Some manufacturers may be marketing these as having "firewall"
capabilities. In some cases, this amounts to nothing more than basic NAT
(Network Address Translation or masquerading). Not a full, true firewall by
most measures. Be sure to read the fine print before buying and make sure you
know how much real firewalling is included.

Everything should be in place now. You probably have already tested your
connection. You should be seeing ping roundtrip times of 10-75 ms to the ISP's
gateway. If something has gone wrong, and you cannot connect, either
retrace the above steps, or see the Troubleshooting
Section below.