Can I Just Shoot The Router Now?

It would appear that D-Link is causing considerable grief for a guy in Denmark who was attempting to provide a public service for Denmark’s internet infrastructure.

A number of D-Link products, so far I have at least identified DI-604, DI-614+, DI-624, DI-754, DI-764, DI-774, DI-784, VDI604 and VDI624, contain a list of NTP servers in their firmware and using some sort of algorithm, they pick one and send packets to it.

This is about as wrong a way to do things as one can imagine. There is no way D-Link can change the list once the product is shipped, unless D-Link can persuade the customer to upgrade the firmware.

The problem is that a lot of these routers are picking GPS.DIX.dk and are eating up his bandwidth (despite the NTP server’s description showing that it’s intended for the local infrastructure and that end-client use is PROHIBITED).

I have no idea how many devices D-Link has sold, but between 75% and 90% of the packets which arrive at my server come from D-Link products via this mechanism.

Up until now, the management has been allowing him to host the NTP server for free, since he’s providing a service (there would normally be a $4400 connection fee).  But because of the traffic, DIX is looking to charge him for the increase in usage. 

Negotiations with the DIX management are ongoing, but the current theory is that I will have to close the GPS.DIX.dk server or pay a connection-fee of DKR 54.000,00 (approx USD 8,800) a year as long as the traffic is a significant fraction of total traffic to the server.

I owe $5000 to an external consultant who helped me track down where these packets came from.

I have already spent close to 120 non-billable hours (I’m an independent contractor) negotiating with D-Link’s laywers and mitigating the effect of the packets on the services provided to the legitimate users of GPS.dix.dk.

Finally I have spent approx DKR 15.000,00 (USD 2,500) on lawyers fees trying to get D-Link to negotiate in good faith.

If I closed the GPS.dix.dk server right now, wrote off all the time I have spent myself, then my expenses would amount to between DKR 45.000,00 and DKR 99.000,00 (USD 7,300 to 16,000) and several hundered administrators throughout Denmark would have to spend time reconfiguring their servers.

If on the other hand we assume I leave the service running and that the unauthorized packets from D-Link products continue for the next five years, the total cost for me will be around DKR 115.000,00 + 54.000,00 per year (approx USD 18,500 + USD 8,800 per year) or DKR 385.000,00 over the next five years (USD 62,000).

All of this is entirely due to D-Link’s incompetent product design and I have no way to mitigate it.

In the end, it’s likely that he’s going to have to move his NTP server, as he’s had no luck in getting D-Link to even acknowledge the problem, much less getting them to pick up the costs for their actions.

Because of Verizon I have one of these DI-604’s, whether I want it or not.  As an interim fix to try to help this guy out I found a public secondary NTP server at Texas A&M and pointed my router at it instead of letting it decide randomly (I also changed it to only check every 8 hours).  I’m tempted to set up an NTP server on my Linux box so that none of this traffic will be flooding internet sites (even if they list themselves as allowing public access), since it appears that the default for the DI-604 is to poll once per hour.  I’ve already got an NTP client daemon running on there to keep the system clock synced, so I suppose it wouldn’t be too hard to add the required server component and just point the DI-604 at it.

Anyhow, this isn’t the only time D-Link has been caught abusing public services.  I recently began investigating to try to see why my DynDns.org host entry wasn’t automatically updating.  The router is supposed to have DynDns support, but I got an email that my host entry was expiring.  In the past, I’d seen this occasionally when my IP address didn’t change for long periods of time.  Since the router didn’t see an address change, it didn’t try to update DynDns.org, and so the host would eventually expire.  I’d usually work around this by forcing a manual update on their website, but this time I noticed that the current address was different than the address in the DNS record.  Some further research turned up the fact that almost all D-Link routers have been blocked by DynDns.org due to abusive updates and incorrect implementation of the protocol (it appears they just “borrowed” an example implementation without bothering to change the User Agent).

So now I’m stuck with a POS router that a) causes headaches for NTP server owners, and b) won’t update DynDns anymore.  But I guess Verizon support is happy that they get to use a “standard” router (with its non-standard Verizon-specific, but still buggy, firmware).  I complained in no uncertain terms to Verizon about this when they sent me a customer survey about Fios.  I don’t know if they’ll ever listen, though.  Perhaps in the meantime Verizon could put up an NTP server and update all these stupid D-Link devices to help mitigate some of the problem.

Link via Slashdot.

Comments are closed.