Amulet Devices Voice Remote for Windows Media Center

Amulet Devices Blog

LinkSys DMA extenders fall off the grid

Sun, November 7, 2010 by

On November 4, members of The Green Button reported that their Linksys DMA 2100 & 2200 extenders were freezing on power-up and would no longer connect to Windows Media Center.

Some diligent investigation by several users revealed the problem: the extenders were attempting to connect to a central Linksys server which Cisco (owners of Linksys) had recently taken offline. The firmware handles this badly by refusing to continue until the connection succeeds.

UPDATE: As of November 9, Cisco has resolved the problem with the US firmware server, and it is now back online. The original article remains below, in case this occurs again.

Thankfully, there is a straightforward workaround: unplug the network cable, reset the unit, go into the network settings on the DMA and manually configure them, setting the DNS server entry to 127.0.0.1 or 0.0.0.0. This prevents the extender beginning the connection attempt and circumvents the problem.

One user reported configuring their router to block the Linksys from accessing the DNS server, but this was less successful – it allowed the Linksys to connect to Media Center, but after a while it would lockup.

TGB user azieba (a network engineer in real life) figured out the details, by creating a fake Linksys server with the same IP address on his private network. The DMA is attempting to connect to the web address http://us-firmware.linksys.com/fw2.php. This resolves to the server 66.161.11.85 which is no longer responding so eventually the connection times out. It will retry every 30-45 seconds, which eventually causes the firmware to run out of memory or sockets, causing a lockup.

I use the Linksys DMA 2100 to stream Media Center to my bedroom — while we don’t support Amulet’s voice recognition on the DMA, it’s still a very handy low-cost way of getting Media Center into other rooms. So, I was keen to see it was affected by the same problem.

In fact, it’s still working fine! I decided to find out why, so I pulled out my own network sniffer.

When my DMA starts up, it attempts to connect to a different server: emea-firmware.linksys.com which resolves to 195.33.130.67. EMEA is Europe, Middle East and Asia, so LinkSys appear to use a different server for models sold outside the US (I bought mine in Germany). Presumably this is to try and keep the servers relatively close to the units connecting to them.

For interest, here is what happens when my DMA 2100 connects successfully to emea-firmware.linksys.com (I expect US units behaved similarly with the US server, until recently):

POST /fw2.php HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------20452003411409721520290712528
Content-Length: 489
Host: emea-firmware.linksys.com:80
Connection: close
User-Agent: KiSS/0.0.8

-----------------------------20452003411409721520290712528
Content-Disposition: form-data; name="xml"; filename="xmlreq.xml"
Content-Type: text/xml
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<UPDATE protocolversion='1'>
<UPDATEREQUEST version='1.1.12' brand='Linksys' model='DMA2100' playerid='n16h0t0l6esa' sku='EU'>
.<FIRMWARE firmwarebay='1' md5='E0020F6EBFCAFF622FE754CAA9988B10' />
</UPDATEREQUEST>
</UPDATE>
-----------------------------20452003411409721520290712528--

And this is the response received:

HTTP/1.1 200 OK
Date: Sun, 07 Nov 2010 09:17:18 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/5.1.2
Content-Length: 231
Connection: close
Content-Type: text/xml

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<UPDATE protocolversion='1'>
 <UPDATERESPONSE version='1.1.12' title='re-affiliation no longer required after connection loss'
severity='Normal'>
 </UPDATERESPONSE>
</UPDATE>

So essentially, as long as the DMA is told there is no new firmware available, it remains happy. azieba reported that in fact, the web server can send back any response at all and the DMA will continue without error — it is only the lack of response that causes the problem.

(I notice that the SKU field in the initial XML request identifies the unit as EU or US, so I expect the European server may respond positively to requests from US units; if so, a simple short-term fix would be for Cisco to update the DNS entry for us-firmware.linksys.com to point to the European server instead.)

I hope Cisco/Linksys will get this issue resolved as quickly as possible, since most users won’t be comfortable tampering with low-level network settings. And let’s hope that the EMEA Linksys server doesn’t suffer the same fate!

Comments are closed.

 

Other Posts