Last week I received a TED 5000-G from Energy, Inc., one of their The Energy Detective products. This home power monitoring device sits in one’s electrical panel and logs energy consumption, calculates cost, and displays all this info in near-real time via some web-based software called Footprints. This software runs off of the Gateway piece of the system, and a live demonstration of it can be seen here.
Unfortunately, this software has one fatal flaw in that it in normal use in my network it responds to HTTP requests with HTTP/1.1 414 Request-URI Too Long. After not very much digging I found that this happens every time the HTTP request to the Gateway includes a cookie. When your browser has a cookie for a website any websites that are visited that are on subdomains of where the cookie was set will also be sent the cookie. Therefore, cookies set by my site (https://nuxx.net) also get set when visiting the Gateway’s internal address on my network (http://ted.home.nuxx.net) and thus the device doesn’t work.
Specifically, here’s Firefox on my main machine accessing the Gateway immediately after clearing cookies. Text in red is the request from my browser, and text in blue is the response from the Gateway redirecting my browser to Footprints.html. This is normal, expected behavior:
GET / HTTP/1.1
Host: ted.home.nuxx.net
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html
Expires:0
pragma:no-cache
<meta http-equiv="refresh" content="0;url=Footprints.html">
After this I visited nuxx.net where some simple Google Analytics tracking cookies were set and tried to access the gateway again. Note that the only difference is cookies being sent, and the 414 response:
GET / HTTP/1.1
Host: ted.home.nuxx.net
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: __utma=23010084.1066362494.1295494794.1295494794.1295494794.1; __utmb=23010084.1.10.1295494794; __utmc=23010084; __utmz=23010084.1295494795.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
HTTP/1.1 414 Request-URI Too Long
Connection: close
414 Request-URI Too Long: Buffer overflow detected
This problem makes the device unusable for me. There are two discussions about this issue in TED’s support forums about this issue (#1, #1 PNG Mirror, #2, #2 PNG Mirror) which indicate that there is only 100 bytes available to service the request and that the developers may be adding another 20 bytes.
As a workaround it’s proposed that the Gateway instead be accessed by only its hostname (without the domain name, eg: http://ted) or IP address (eg: http://192.168.0.17), which ensures that no cookies are sent because it’s unlikely that any would have ever been set for those addresses. I feel these workarounds are a stopgap at best and seriously fail if one ever wishes to access the TED data from the public internet or on a well-managed, convenient network. After all, we have DNS so that (potentially changing) IPs don’t need to be remembered and/or discovered, and FQDNs because hierarchal naming is good. It would be possible to use a proxy sitting in front of the Gateway to remove cookies and make the requests more acceptable to the firmware, but I’m not particularly interested running another server just to work around this device’s shortcomings.
Since a variety of cookies could end up being sent by a modern browser I don’t think that the developer’s proposed solution of adding 20 bytes to the buffer will not solve the problem. While I’ve got a limited knowledge of embedded development, I’d think that the developers should instead should simply discard the cookie when reading it into the buffer. After all, the cookie is plaintext in the frame, begins with Cookie:, is terminated with a standard \r\n, and just comes across from the Ethernet controller as serial data. I can’t see why it couldn’t be parsed out if it’s too large to stuff into a buffer. Then again, I suppose this issue could also be caused by clients that have a particularly long User-Agent, really long hostnames, or any other number of other things which could expand the size of the request.
(Thinking about this further, I also believe that only the GET / HTTP/1.1 is the URI which is the same length in both cases. Perhaps the Gateway should really be returning a 413 Request Entity Too Large if it feels the length of the request itself is too long?)
Today I called for an RMA for my TED 5000-G, and after receiving it called back to speak with tech support. I mentioned this issue to the person with whom I spoke, and unfortunately I don’t think he quite understood the problem and instead seemed to be offering to try upgrading the firmware to resolve it. He also stated that he doesn’t have access to firmware changelogs so he can’t tell me if the issue is fixed in a future or beta release, or even if it will be fixed. When I send the device back I’ll be including this letter explaining why I’m returning it. Save for this hugely annoying issue the device seemed to work rather well, so if Energy, Inc. can resolve the problem I’d love to keep it. However, something that doesn’t function with modern browsers and network setups isn’t worth $199.95.
(Mirrored forum discussions were captured at 23:09 EST on 19-Jan-2011. Software versions as reported in Footprints are as follows: Gateway Version 1.0.400, Daughterboard Version 1.0.48, Footprints Version 1.0.222, MTU Version 1.0.0. All information above is only representative of these versions.)
