Skip to content

Tag: hdtv

Hackability as a selling point

Hardware: On my home network, I recently replaced my NetGear MR814 with a brand new Linksys WRT54G.

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.

Aha.

A new world for radio regulators

GNU Radio, which (as noted on Boing Boing) has just released screenshots of a successfully-decoded HDTV signal, is a totally new way to receive (and possibly, in the future, send) radio-frequency signals. The FCC ponder the implications:

The emergence of the low-cost, generally available SDR which can be configured with … open software will present a new issue for regulators. What will be placed in the hands of the public entrepreneurs, amateurs, and even those with malicious intent will be machines which in principal can emulate, send, and receive any radio signal on any band. …

Then, with the world-wide availability of software that can even be modified if needed, any radio transmitter or receiver can be emulated. Bans on receiver types will be circumventable with ease. Mandates such as the proposed ATSC broadcast flag will be hard to enforce (and may even fail in the presence of a single web-connected noncompliant receiver). And, although not generally an issue for the Commission, it will be possible to implement proprietary systems without the benefit of any license from the patent holder. Because the software is open, as a practical matter virtually all mandated restrictions will be at risk (except for total power output which remains a classical hardware issue). …

In the GNU SDR environment, we have the makings of a powerful new technology that has the potential of solving the spectrum management problem, but we may also have other people in the world writing and distributing software with their own agenda.

Wow. That’s a brave new world. I wish I knew enough about radio tech to really get a handle on this stuff…