My top criteria for what hardware to buy for this job weren’t price, form factor, how pretty the hardware is, or even what features it had — instead, I bought it because it’s an extremely hackable router/NAT/AP platform. Thanks to a few dedicated reverse engineers, the WRT hardware can now be easily reflashed with a wide variety of alternative firmware distributions, including OpenWRT, a fully open-source distro that offers no UI beyond a command-line.
Initially, I considered a few prettier UIs — HyperWRT, for example — since I didn’t want to have to spend days hacking on my router, of all things, looking stuff up in manuals, HOWTOs and in Google. Finally I decided to give OpenWRT a spin first. I’m glad I did — it turned out to be a great decision.
(There was one setup glitch btw — by default, OpenWRT defaults to setting up WPA, but the documentation claims that the default is still no crypto, as it was previously.)
The flexibility is amazing; I can log in over SSH and run the iftop tool to see what’s going on on the network, which internal IPs are using how much bandwidth, how much bandwidth I’m really seeing going out the pipe, and get all sorts of low-level facts out of the device that I’d never see otherwise. I could even run a range of small servers directly on the router, if I wanted.
Bonus: it’s rock solid. My NetGear device had a tendency to hang frequently, requiring a power cycle to fix; this bug has been going on for nearly a year and a half without a fix from NetGear, who had long since moved on to the next rev of cheapo home equipment and weren’t really bothering to support the MR814. I know this is cheap home equipment — which is why I was still muddling along with it — but that’s just ridiculous. None of that crap with the (similarly low-cost) WRT. OpenWRT also doesn’t contain code to DDOS NTP servers at the University of Wisconsin, which is a bonus, too. ;)
Sadly, I don’t think Cisco/Linksys realise how this hackability is making their market for them. They’ve been plugging the security holes used to gain access to reflash the firmware in recent revisions of the product (amazingly, you have to launch a remote command execution attack through an insecure CGI script!), turning off the ability to boot via TFTP, and gradually removing the ways to reflash the hardware. If they succeed, it appears the hackability market will have to find another low-cost router manufacturer to give our money to. (update, June 2006: they since split the product line into a reflashable Linux-based “L” model and a less hackable “S” model, so it appears they get this 100%. great!)
Given that, it’s interesting to read this interview with Jack Kelliher of pcHDTV, a company making HDTV video capture cards:
Our market isn’t really the mass market. We were always targeting early adopters: videophiles, hobbyists, and students. Those groups already use Linux, and those are our customers.
Matthew Gast: The sort of people who buy Linksys APs to hack on the firmware?
Jack Kelliher: Exactly. The funny thing is that we completely underestimated the size of the market. When we were starting up the company, we went to the local Linux LUG and found out how many people were interested in video capture. Only about 2 percent were interested in video on Linux, so we thought we could sell 2,000 cards. (Laughs.) We’ve moved way beyond that!
Well worth a read. There’s some good stuff about ulterior motives for video card manufacturers to build MPEG decoding into their hardware, too:
The broadcast flag rules are conceptually simple. After the digital signal is demodulated, the video stream must be encrypted before it goes across a user accessible bus. User accessible is defined in an interesting way. Essentially, it’s any bus that a competent user with a soldering iron can get the data from. Video streams can only be decrypted right before the MPEG decode and playback to the monitor.
To support the broadcast flag, the video capture must have an encryptor, and the display card must have a decryptor. Because you can’t send the video stream across a user accessible bus, the display card needs to be a full MPEG decoder as well, so that unencrypted video never has to leave the card.
Matthew Gast: So the MPEG acceleration in most new video cards really isn’t really for my benefit? Is it to help the vendors comply with the broadcast flag?
Jack Kelliher: Not quite yet. Most video cards don’t have a full decoder, so they can’t really implement the broadcast flag. ATI and nVidia don’t have full decoders yet. They depend on some software support from the operating system, so they can’t really implement the broadcast flag. Via has a chipset with a full decoder, so it would be relatively easy for them to build the broadcast flag into that chipset.