Last updated on January 20, 2011
 |
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-aliveHTTP/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: close414 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.)
Why not just use one of the many cookie-controlling extensions to prevent sending cookies to that particular device? It’s ridiculous that such a workaround is needed, but it’s not remotely difficult.
I saw this via your breakdown post that made it to hackaday. Great post!
Regarding this issue, the “20 byte” fix was mostly geared towards getting around long URL’s being used. We have some large GET strings used in the system/utility settings and this would help there. Outside of this, we’d have to bump up the buffer to 200bytes + and being a small embedded device, we don’t have a lot of RAM to spare (as you can see by the sheets posted in your other article, we are making the most out of 16K of RAM).
The cookie issue is something else. I think its tripping our buffer overflow checks on the device (since we don’t expect cookies, this is quite possible). I’ve made a note to take a look at our tcp stack code to see if we can filter that out. I’ll replicate the issue locally (send your exact request header) and we’ll try to work in a fix.
If you are putting this device out to the public, one suggestion/workaround is to use scripts to cache the files on your webserver. This is pretty straightforward (i.e. a bash script to to a wget call to a URL and save it locally to a directory). We do that on our demo so, and I mentioned in the hackaday post, I’ll see if I can bundle it up for distribution. The biggest benefit to it is that your TED can be open to the public but most of the bandwidth would be located to your webserver vs. your home connection (you can also handle more simultaneous requests to the device). Most of “footprints” can be downloaded and cached once (per version upgrade).. the rest of the data calls are all documented in our API (http://www.theenergydetective.com/media/TED5000-API-R330.pdf) Our scripts streamline this a bit so I’ll definitely see about cleaning them up and publishing them.
Cookie wise, you should be able to limit them to certain subdomains via your webserver configuration as well (since you already break it out to its own subdomain). However, if we can filter out the cookie data when processing the request, that may be the way to go.
TedDev: Thanks very much, it was fun to look into it.
That said, I would imagine that if you’re throwing out the cookies (text from Cookie: straight-through to the next \n) while writing into the buffer) you’d simply step around the problem. Personally, I’d almost look at this as a filter which doesn’t sound quite ideal, but would allow you to sanitize the input to something that you’re able to deal with.
That’s interesting to hear about how you do the demo system. I can definitely see that working for me, it’d just require me to run another webserver to have something that’ll run internally even when disconnected from the public site. I do have this public site here, but one of the big selling points of the TED for me is that it would simply work stand-alone without requiring another device to make things accessible. The solution you mention sounds like a great way to scale things up for public consumption, but for personal use at home (even if exposed to the public network) I really think that it should just work. I feel that devices should be very liberal in what they accept, throwing out parts of sane requests if they aren’t useful or able to cope with them.
Martin: No, it’s not difficult, but it also shouldn’t be necessary.
I just have to say it’s great to see this sort of open conversation between TED and Steve. I’ve been running a TED5000-C for a couple months now, and am largely impressed with the capabilities. It is amazing how much they have managed to cram into such a small device, and I really like having both this and my Bayweb thermostat. I use the Bayweb a lot more real-time and really like the phone-home SaaS model over the Footprints software, but the Google Powermeter interface helps out a bit with that. I still think there is a bit of maturity needed, but since my home network is relatively stupid (the TED is probably the only box I hit with a non-FQDN), I’ve been okay… I do really like the reverse caching idea though, because no offense, but as a security professional have to say there is no way in Hell I would ever open this poor little box up to Internet-inbound traffic. I used to run MRTG against a 10/Half interface on a midsize Liebert in one of our data centers, and every time I would either Nessus or nmap it, the poor thing would fall over and need to be rebooted… I just don’t believe these little guys are meant for more than light use, and the daily barrage of Internet flotsam and jetsam (SQL Slammer, SSH brute force, NetBios, etc) would probably kill the poor TCP stack.
I’m really not a hater though. I do dig my little TED! It is definitely an innovative product, and it’s fun to see my home go from ~3-4kWh to 11kWh when I fire up everything in the basement. Thanks, and keep up the development!
I encountered this same problem when setting ted up through my reverse proxy. I wish I could find a resolution as I would like to have all my data behind the proxy.
i had this over flow problem with Firefox but when i made Google Chrome my default
it worked just fine.