The Grumpy Editor's Tomato review

Your editor has just completed an important transition: moving his Internet connectivity from one evil branch of the local telecom duopoly to the other, equally evil branch. This change required the acquisition of a new router; that, in turn, provided the opportunity to play with Linux-based router software, and Tomato in particular. Read on for your editor's impressions of this impressive bit of (mostly) free software.

Tomato has its roots in the original Linksys WRT54G firmware. This firmware was first distributed as if it were proprietary software, but Linksys, under heavy GPL-enforcement pressure, eventually made the source available under the GPL. The existence of this source, along with the ease by which the Linksys routers could have new firmware installed, led to the creation of a number of firmware distributions, all of which added new features and otherwise improved on the original Linksys offering. Over time, Linksys (Cisco) has incorporated some of these improvements; the company also continues to offer a special version of its basic household router (the WRT54GL) which is explicitly designed to allow firmware replacement.

If a company is going to make a competitively-priced, Linux-based, user-hackable router, your editor feels an obligation to buy it. That choice is easy, but the choice of which replacement firmware to use is harder. There's a wide variety of offerings, including OpenWrt, DD-WRT, FreeWRT, and Tomato. There appears to no easy way to pick one in particular; your editor started with Tomato because the screen shots looked nice and the installation instructions were straightforward. On the other hand, OpenWRT's installation instructions are simply missing (though some information is available on the OpenWRT wiki), and those for DD-WRT are lengthy and intimidating, making the process look similar to installing Gentoo.

The funny thing, of course, is that installing replacement firmware on a WRT54GL router is a trivial task: download firmware, go to the router's "upgrade firmware" screen, and upload the new blob. Two minutes later the job is done.

Your editor's first impression of Tomato is that it is great stuff - though reflection yields some concerns which will be discussed below. Tomato brings a whole range of new functionality to a cheap consumer device, yielding a degree of visibility into and control over the network which your editor has never had before. The web-based interface is slick - if JavaScript heavy - and mostly easy to use. It would have been nice to bring this device into the house some time ago, even if Evil Telecom #1's network did not require its presence.

One nice feature is simple bandwidth monitoring and display; there are a number of plots which can be brought up and watched in real time. The router is also able to store network statistics for a long period of time and produce plots on daily, weekly, or monthly scales. The only problem there is that the hardware lacks the storage for this amount of data; Tomato can work around that little limitation by using a built-in CIFS client to use storage found elsewhere on the net.

The Linux kernel has the facilities to exercise a great deal of control over the processing of network traffic. There is simple firewalling, of course, with the ability to decide which traffic is worthy of passage and which should be denied. But there is also an extensive traffic control subsystem allowing the user to prioritize the use of the available bandwidth. That feature is arguably underused because it takes a while to figure out how to configure it with the available command-line clients. Tomato provides a relatively straightforward mechanism for the creation of both access control and quality-of-service rules.

On the access control side, Tomato has a screen which allows the creation of rules for specific addresses and port numbers. Rules can be global, or they can apply only to traffic from specific machines on the local network. Rules can have a schedule attached so that, say, distracting web sites can be blocked during the day - encouraging accomplishment - while serious sites can be blocked at night - encouraging relaxation. Specific systems can be blocked from the net entirely on a schedule, a potentially useful feature for parents who have long since given up on trying to keep wireless-enabled devices out of the kids' rooms late at night.

Interestingly, Tomato does not stop with port-based restrictions; it also incorporates the L7-filter and IPP2P classifiers. Both modules are essentially deep packet inspection implementations, allowing the classification (and, thus, control) of traffic based on a look at the actual bits passing through. With L7-filter, for example, an administrator can block specific role-playing games, regardless of whether the official servers or ports are being used. There's a vast set of canned rules, enabling control of various instant messaging protocols, file formats, and more. It is now possible to block the downloading of Perl scripts - something which, while tempting, is probably unwise to actually do. IPP2P, instead, is more directly focused on the detection of peer-to-peer protocols. Together, they are a control freak's dream; network neutrality stops at the local router.

Even if a network administrator does not wish to ban, say, role-playing games outright, there is value in saying that such uses of the network should not interfere with real work like reading XKCD. That's where the quality of service (QOS) screens come in. QOS is a two-step process: dividing the available bandwidth among various classes of traffic, and assigning specific types of traffic to those classes. Tomato provides ten different classifications, each of which has a priority and a guaranteed bandwidth portion - all of which can be changed, of course. By default, only outbound (to the wide-area network) traffic is subject to control; it is possible to control inbound traffic, but, since that traffic has already passed over the WAN link by the time the router can work with it, there's usually little point. Classification rules look a lot like access control rules, allowing the use of addresses, port numbers, or classification by IPP2P or L7-filter.

With all this, the administrator can decree that, say, a certain proprietary role-playing game favored by the children is a very low priority stream - but it still gets a few percent of the available bandwidth so the kids do not suffer permanent trauma as a result of lag-induced fragging. Tomato can also generate pie charts showing (by classification) how bandwidth is being used currently; clicking on a classification yields a list of current connections. All told, it's a capable and easy-to-use way of ensuring that the network functions well even under heavy use.

Other features abound. There is a DHCP server, of course, along with a nice screen for doing static DHCP assignments without ever having to type a MAC address. The router can report its globally-visible address to a wide variety of dynamic DNS services. Incoming connections can be forwarded to internal machines in a flexible way. There is a "triggering" mechanism which automatically opens specific incoming ports in response to specific outgoing connections. Old-timers will see triggering as a way to support the full FTP protocol; everybody else will use it to enable incoming BitTorrent connections. And so on. It is, to say the least, a highly capable system.

The biggest operational problem your editor has experienced is the occasional dropping of long-lived SSH connections. A bit of research led to the tweaking of a few of the rather intimidating array of connection tracking parameters, and things would appear to have improved.

There are a couple of more general concerns, though. Like many of its peers, Tomato appears to be well past its active development phase; there were a few releases in 2009, but they did not make a great many changes. Meanwhile, its 2.4.20 kernel is rather far back from the leading edge, and both L7-Filter and IPP2P are explicitly unmaintained. Given the steady stream of security updates for protocol dissectors in WireShark, your editor has a hard time believing that these other classifiers can be completely free of security issues. But there is nobody maintaining them, and Tomato has no apparent means for the monitoring of security problems or the distribution of updates. Given that these routers are directly exposed to the net and are the first line of defense for many networks, the combination of ancient software and no security support is worrying.

Tomato is also not 100% free software. The core Linux system is, of course, free, but the user interface code carries a "for use with Tomato only" copyright notice. There is also the issue of the proprietary Broadcom network driver, but that's a problem any 2.4-based firmware for this router will have.

These concerns are strong enough that, despite Tomato's many qualities, your editor is not yet sure that he has found the final distribution for his router. In particular, OpenWRT - which offers a 2.6 kernel, a seemingly larger and more active development team, release notes with CVE numbers included, and a packaging system allowing others to add features to the router - seems worth a detailed look. The good news is that this choice exists and is easy to execute. That, in turn, is the result of the GPL and the developers who made an effort to enforce it.

---

(Log in to post comments)