linux/ConfigureDSLOnFedora written at 01:47:15; Add Comment
How to configure a (PPPoE) DSL connection on a normal Fedora 14 Gnome desktop
The first and most important thing to know is that you should completely ignore what you'd think is the right way to do this. Trying to use what you find at System → Administration → Network for this (if there's anything there) is somewhere between useless and actively counterproductive, even though it can be used for at least some other network configuration things.
(This is system-config-network. If you installed Fedora 14 from scratch instead of upgrading from a previous Fedora version you may not have it installed, in which case I strongly recommend that you keep it that way.)
Instead what you want is hiding inside the network manager applet (nm-applet). Click on the applet, then VPN Connections → Configure VPN. Yes, really. You will get a tabbed widget open to the VPN tab; switch to the DSL tab instead.
(This widget is also where you can expunge all of those wireless networks that you connected to once in order to see what they were, and now you never want to touch them ever again and certainly don't want your machine to try to associate with them every time it sees them. How handy it is that nm-applet puts it in such an obvious place as configuring VPNs, gives you no other access to it, and has no help that you can see if you are, perhaps, not connected to the Internet. It's almost as handy as system-config-network, which is an achievement that Gnome should be proud of.)
Now you need to set some DSL PPPoE parameters.
In Toronto at least, DSL identifiers are in the form '<id>@<something>', where the second part specifies your ISP; I believe that I've seen this called the (DSL or authentication) realm that your ID is in, and I believe it's conventional for the realm to look like a domain name, eg bell.ca. In the nm-applet widget, this all goes in the Username field, the Service field is usually blank, and you put your password in the Password field. As usual, tick the 'Show password' box so that you can actually make sure you're entering the password right. Finally, pick a useful name to put in the Connection name field at the top.
(I also set the 'Send PPP echo packets' option in the PPP tab, and it's possible that this is important.)
If you're doing this with the machine completely disconnected, don't be surprised when your new DSL connection doesn't show up in the network manager applet's list of available networks. It's smart enough to know that a PPPoE DSL connection depends on having a connected physical network and not list them if there isn't one.
You can have multiple PPPoE DSL connections defined (with different names).
The network manager applet stores almost all of this information in gconf under the key /system/networking/connections/<N>, where <N> is some number; you can directly edit or remove things in the traditional manner. I believe that passwords are stored in the depths of the Gnome keyring system.
I am not sure I know all of the places where system-config-network
stores information, but one of them is in files under
(I'm writing this down now because if I didn't and I ever needed it again, I would hate myself very much.)
Sidebar: Toronto's special test DSL realm
At least in Toronto, there is a special test DSL user and realm that exists on every DSL service point; it is user 'test@test' with password 'test'. If your local system and the DSL service point are working properly, establishing a PPPoE DSL connection with this identity will give you an (unroutable) IP address; what local and remote addresses you see depends on what DSL service point you're using, and Bell techs can use this information to identify what exact bit of Bell equipment you're being connected through.
(I don't know if this special test user is handled by your DSLAM or by something somewhat upstream of it.)
This test user makes a useful check to see what's broken during local troubleshooting. If you can get a connection as test@test but your regular DSL connection doesn't work, it's almost certainly your ISP's problem (or a problem between Bell and your ISP). If you can't even get connected as test@test, the problem is closer to home; local software, bad DSL signal, or things gone sufficiently wrong inside Bell's systems.
(You can also use it for basic performance testing for things like packet loss and packet timings, and for pinpointing the likely source of connection stability problems.)
Of course none of this is very important if you're using Bell as your DSL ISP, but why on earth would you want to do that? If you're reading this (and are in Toronto), there are much better choices.
* * *
Atom feeds are available; see the bottom of most pages.