Motorola's NVG510 DSL modem... not very good

A few weeks ago here in the above ground portions of the Gibbs Universal Industries Secret Underground Bunker we got hooked on the British series "Downton Abbey".

The reason I mention this new found delight is that we wanted to watch it on Netflix and the best way to do that was on the Second Generation Apple TV connected to the TV upstairs. I discussed the Apple TV briefly here in Gearhead last September and I realize that the problems I discussed then must have been related to the kind of problems I'm about to discuss.

The reason for choosing that particular TV was that the house isn't hard wired for data and as the Apple TV handles WiFi very well and as my AT&T DSL service was, at the time, stable, all was fine and we happily watched the episodes. For a while.

I've written about my problems with AT&T's DSL service a few times recently (my editor recently threatened me with violence if he has to edit another column on DSL ... luckily we're on different coasts) and it is, in truth, a complete and utter mess. What's more, it appears I'm not alone. I've had more reader responses from those columns than almost anything else I've written, and it seems like when your AT&T Internet service has problems, it's almost always an ordeal.

In my case, my AT&T U-Verse connection is mediated by a Motorola NVG510 DSL modem. This device, customized for AT&T, has an ADSL2/2+ WAN port, a four-port 10/100 Ethernet switch, a 400mW 802.11b/g/n access point, and a single RJ-14 port for VoIP service (if such a thing is available in your area).

Note that Motorola offers no support whatsoever for this device and you cannot get the manual for this product from either Motorola or AT&T. You have to download it from Ron Berman, a PhD student in the marketing department of the Haas School of Business at UC Berkeley, who also explains on his Web site how to download the manual from the FCC's archive of product approvals (Ron also answers a number of support questions about the NVG510 that AT&T fails to address; big props to Ron!).

It came as a non-surprise to me that the product manual as submitted to the FCC by Motorola doesn't exactly describe the product as provided by AT&T! Significantly, command line support, which is detailed in the manual, is completely absent in the delivered product.

So, what of the hardware? Physically, the NVG510 has the usual irrelevant and clumsy "Jetsons" form factor that so many devices in this class have, which means it can't be stacked and can be easily toppled over by the merest tug on any cable connected to it.

Next, the user interface: Quite extraordinarily, much of the NVG510's user interface isn't, and can't be, password protected though other sections of the user interface are protected by what Motorola calls an "access code". The first thing you see when you load the root page in your browser is way more detail than you'd expect, such as the wireless SSID and the network key in plain text!

Wait! It gets better: If you go to the Device page you can see the IP addresses of all network-connected gear, while the broadband page gives you lots of detail about your WAN interface and the Home Network Page shows you everything any hacker could ever want to know about your LAN configuration.

The access code is only required to restart the device, configure the WAN, LAN, firewall, and wireless services, examine the VoIP interface details, and, for no accountable reason, to examine the device's log.

The code is also required to change the access code and, oddly, while the supplied code is simply 10 numeric characters, any code you'd like to use "must contain characters from two of these categories: alpha, numeric, and special characters". Do as we say, not as we do ...

As security goes, this device has no clear strategy and has the feel of something that was left to a junior engineer to design. I'm amazed that this product could have passed the technical selection process for AT&T.

The various entries you might see in the log aren't explained anywhere I can find and, while some of them are decodable, others are not at all obvious. It also looks like the logging system is buggy: All devices that disconnect and then reconnect are almost always listed as reconnecting after however long it was plus 30 days and 16 hours ... for example, here's the log entries for a device that disconnects and reconnects after 18 seconds:

2012-03-13T07:06:36-07:00 L3 sdb[306]: Wi-Fi: Client a4:d1:d2:71:c1:c0 left XXXX

2012-03-13T07:06:36-07:00 L3 sdb[306]: Wi-Fi: Number of clients associated 2

2012-03-13T07:06:54-07:00 L3 sdb[306]: Wi-Fi: a4:d1:d2:71:c1:c0 re-joined XXXX after 30 d 16 h 0 m 18 seconds

2012-03-13T07:06:54-07:00 L3 sdb[306]: Wi-Fi: Number of clients associated 3

Perhaps I'm being picky, but I think the quality of code is always visible in the attention (or lack thereof) to detail in the stuff you see. In the case of the log above, why are days, hours, and minutes abbreviated while seconds is fully spelled out? That's just sloppy thinking.

An old and ongoing problem with the NVG510 concerns DNS resolution. The modem doesn't allow you to change the default DNS servers and either or both of AT&T's DNS servers keep failing to respond ... for example:

2012-03-06T14:37:28-08:00 L3 dnsmasq[2219]: no responses from nameserver '99.99.99.53'

2012-03-06T14:37:28-08:00 L3 dnsmasq[2219]: no responses from nameserver '99.99.99.153'

2012-03-06T14:37:30-08:00 L3 dnsmasq[2219]: nameserver '99.99.99.53' is now responding

2012-03-06T14:37:33-08:00 L3 dnsmasq[2219]: no responses from nameserver '99.99.99.53'

2012-03-06T14:37:33-08:00 L3 dnsmasq[2219]: nameserver '99.99.99.53' is now responding

2012-03-06T15:33:45-08:00 L5 cwmp[1363]: DSLF_WanMgmtChg path[mgmt.cwmp.conn-req] val[0]

2012-03-06T15:33:46-08:00 L4 cwmp[1363]: Resolving ACS URL - Retry 0

2012-03-06T15:33:48-08:00 L3 dnsmasq[2219]: Timer expired. Retry on nameserver '99.99.99.153'

2012-03-06T15:33:49-08:00 L5 cwmp[1363]: Connect to https://cwmp.c01.sbcglobal.net/cwmp/services/CWMP [144.160.14.12:443] Retry 0

2012-03-06T15:33:49-08:00 L5 cwmp[1363]: (SSL) Connect Success: cwmp.c01.sbcglobal.net

2012-03-06T15:33:49-08:00 L5 cwmp[1363]: (SSL) Certificate Verify Success: cwmp.c01.sbcglobal.net

2012-03-06T15:33:50-08:00 L5 cwmp[1363]: Post Inform - reason 6 CONNECTION REQUEST

2012-03-06T15:33:50-08:00 L5 cwmp[1363]: Receive InformResponse

2012-03-06T15:33:50-08:00 L5 cwmp[1363]: Post 0

2012-03-06T15:33:51-08:00 L5 cwmp[1363]: Receive GetParameterValues

2012-03-06T15:33:51-08:00 L5 cwmp[1363]: Post GetParameterValuesResponse (chunk-length - 10472)

2012-03-06T15:33:51-08:00 L4 cwmp[1363]: Continue GetParameterValuesResponse (chunk-length - 10808)

2012-03-06T15:33:51-08:00 L4 cwmp[1363]: Continue GetParameterValuesResponse (chunk-length - 3550)

2012-03-06T15:33:51-08:00 L4 cwmp[1363]: Continue GetParameterValuesResponse (chunk-length - 0)

2012-03-06T15:33:52-08:00 L5 cwmp[1363]: Closing connection on HTTP 204

2012-03-06T15:33:52-08:00 L5 cwmp[1363]: (SSL) Closing Connection: cwmp.c01.sbcglobal.net

2012-03-06T15:35:23-08:00 L3 dnsmasq[2219]: no responses from nameserver '99.99.99.53'

2012-03-06T15:35:23-08:00 L3 dnsmasq[2219]: no responses from nameserver '99.99.99.153'

2012-03-06T15:35:23-08:00 L3 dnsmasq[2219]: nameserver '99.99.99.153' is now responding

Ron Berman has a FAQ entry on this topic and a page devoted to it.

It's thought that the cause of the problem is the modem's DNS forwarder (a free, open source implementation called dnsmasq) is configured with a timeout that is, under some circumstances, too short. This means that devices that use the DHCP configuration defined by the modem's DHCP server will query the modem's DNS forwarding service. This will, in turn, occasionally fail to resolve the query and will either fail the site as a whole or fail to load parts of a Web page such as the images.

The really annoying thing about the NVG510's DHCP implementation is that it can't be configured to tell clients to use any DNS server other than its own version of dnsmasq! To get a more reliable DNS resolution you have to either set up each client with a static network configuration or use some other machine on your network as a DHCP server.

As if the ridiculous DNS problems weren't enough, I also found a problem with the NVG510's WiFi service which is, to date, inexplicable. Randomly, as far as I can figure out, devices connected via WiFi will lose their connections and, when you try to re-connect, they'll just say they can't do such a thing.

The modem doesn't report a problem and the table of wirelessly connected devices just shows them all as "off", but after stopping and restarting the WiFi service (restarting the entire modem isn't required), wireless devices can immediately reconnect.

I've sent copious notes and dumps of the NVG510's log to AT&T but, so far, no solution or even acknowledgment of the existence of either the DNS or WiFi problems have been forthcoming after more than one week.

The Motorola NVG510 DSL modem and AT&T support both get a Gearhead rating of 1 out of 5.

So, I couldn't rely on wireless if I wanted to watch "Downton Abbey" without interruption, so what's a chap to do? Find out in next week's thrilling installment ...

Gibbs is watching in Ventura, Calif. Tell him your sightings at gearhead@gibbs.com and follow him on Twitter (@quistuipater) and on Facebook (quistuipater).

Read more about anti-malware in Network World's Anti-malware section.