Wednesday, December 15, 2010

More about the D-Link DSL-520B

NOTE:  This is an update of my previous posting on December 6 titled "at&t Elite DSL and the D-Link DSL-520B"

(Revised Dec. 15 @ 11:18pm)

I have some updated information about the DSL-520B that I would like to share.

Using ddclient with the DSL-520B

I discovered the magic setting that allows this DSL modem to "bridge" the IP acquired during PPPoE to the host using DHCP.  However, it is riddled with problems (see below) and so I am not recommending this method.

Therefore, I needed a way to reliably acquire the IP address from the DSL modem in a way that ddclient (most common Dynamic DNS update client for UNIX-like operating systems) could understand.  The way to do this (in the ddclient.conf file) is to set-up the following as the method for obtaining the IP address:

use=fw
fw=192.168.1.1/wancfg.cmd?action=view
fw-skip=PPPoE
fw-login=admin, fw-password={your-modem's-admin-password}

That's it.  What this does is cause ddclient to log-into the DSL modem, grab a copy of the HTML that contains the status of the WAN configuration (which contains the PPPoE-obtained IP address), then looks for an IP address that follows the word PPPoE.  Thanks much to the information in the Sourceforge forums for ddclient for this info.

Bridging The PPPoE-obtained IP

I hesitate to actually include this here because it functioned so badly that it had me scratching my head trying to figure out what in heck was happening.  The magic option is under Advanced Setup -> WAN, then edit the WAN interface configuration.  Keep pressing Next until you reach the page that says PPP Username and Password.  There, you will see a check-box that says "PPP IP extension".  Check this box.  This will also cause the "Enable NAT" and "Enable Firewall" on the next couple of pages to be grayed-out, since the device is unable to do so effectively (not really, see below).

What I found when I enabled this option is that it would sometimes work.  I'm a computer guy, and I don't like anything that sometimes works.  This usually means there's a bug, but since I have no way of effectively getting access to the inner workings of the DSL modem, I can't really figure out or fix what the trouble is.  That being said, my guess is that this is due to the use of the bridge (br0) interface which is known to have trouble with DHCP under Linux.  Why they use br0 in the first place is a mystery to me, but whatever the case, they're using it wrong, because DHCP sometimes doesn't work and almost always crashes the DHCP client (dhcpcd) on my machine when the modem is power-cycled.  Ugly ugly ugly.

Security Ugliness

Speaking of ugly, I must mention a bit of ugliness that could only be left in a production device by someone with a screw loose.  When I was looking through the iptables configuration inside the DSL-520B, I found two interesting DNAT mappings:  One mapped port 2525 to port 25 (telnet), and the other mapped port 8080 to port 80 (http), on 192.168.1.1.  What does this mean?  Well it means that anyone could, from outside my LAN, connect to the IP externally visible to the world on port 2525 or 8080 and get my DSL modem's telnet or web server respectively.  WTF?!  Now surely you changed all your passwords from the default, didn't you?  Never mind that...what about someone accessing the DSL modem and exploiting some latent bug that turns up a few months from now?

At NO TIME should there EVER be external access granted to a device like this by default.

Needless to say, I removed those entries manually, and am looking to see if there's any way that they can be turned-off permanently through the web-based configuration menus.  I will update this as soon as I figure it out...

Update:  This actually isn't quite as bad as it originally seemed.  It seems that this is a "feature" of being in "IP Extension" mode.  Since I am now back in NAT mode, I am not seeing this problem.

No Speed Issues...with the DSL modem at least

The problems with my DSL speeds not being what I expect are not due to the DSL modem, and the DSL-520B appears to be working the way it should.  It turns out that my DSL provider (at&t/SBC) has not yet deployed ADSL2 in my neighborhood and I'm still running on G.dmt (the older ADSL standard).  I was able to connect my old Adtran DSL modem (only a bridge) and connect that to a Netgear router with PPPoE capability.  I ran my speed tests on dslreports.com again, and they came out identically to the ones done with the D-Link DSL modem by itself.

The speed problems are due to something within at&t...and I will need to call them about that.

Updated Conclusions about the DSL-520B

While I do plan on continuing to use the D-Link DSL-520B, it will be with some caution.  My Adtran DSL modem maintains no statistics to speak of, and only supports G.dmt.  While the DSL-520B hardware seems solid, the firmware in this modem is clunky and really needs an update and some bugfixes.  There is some discussion about OpenWRT being released for the BCM-63xx hardware, and that would theoretically make it usable on the DSL-520B (which is really a 96338 board with 2M flash and 8M of memory).  However, I am concerned about destroying my DSL modem - especially with no way of backing-up the old image (yet).

Is it better than the Motorola DSL modem that self-destructs over time?  Yes and no.  I don't think that the DSL-520B is on a self-destruct course, but the Motorola modem that at&t sells is definitely easier to configure and less problematic firmware-wise (although I may be able to find some holes in that platform also, given some time...).

No comments: