OpenWrt releases "Barrier Breaker"
Continuing its tradition of releases named after cocktails, the OpenWrt project released the latest version of its firmware for home routers and other devices, "Barrier Breaker" (14.07), on October 2. As one might guess, it comes with plenty of new features, especially in the networking area (improved IPv6 support, in particular). OpenWrt has long been used by many of the technically savvy, but it is reaching a point where it "just works" and provides such an upgrade from the factory firmware that it may well make sense for some regular users as well.
OpenWrt began in 2003 by starting with the code grudgingly released by Linksys to comply with the GPL for its WRT54G wireless home router. Support for other routers and devices soon followed and the current Table of Hardware that documents the hardware supported by the distribution is truly impressive. We last looked at OpenWrt in 2011, shortly before the "Backfire" maintenance release (10.03.1). Since then, there was also the 12.09 "Attitude Adjustment" release in April 2013.
Though it is getting a little long in the tooth now, the Netgear WNDR3800 is a nice router for testing (and running) OpenWrt. Used devices appear to be plentiful and fairly inexpensive (less than $75 on eBay) or new ones can be purchased for a bit more than double that. The WNDR3800 is certainly one of the easier routers to install OpenWrt on; it is simply a matter of grabbing the right firmware (the factory image for WNDR3800 from this directory) and uploading it to the device using the factory firmware's web interface. Upgrading from an earlier OpenWrt release uses the sysupgrade image, instead; uploading that file into the OpenWrt interface will upgrade the device while preserving the existing configuration (though not any extra packages that may have been installed).
Once installed, there are several things that OpenWrt does (or, perhaps, doesn't do) to improve the security of newly installed devices. To start with, WiFi and ssh are disabled, while telnet is enabled. Turning off ssh and telnet on might seem like poor choices, but the idea is to force the user to set a root password. Users can either telnet or browse to 192.168.1.1 (after connecting some system to one of the device's ethernet ports) to set the password. Once a password has been set (and the same root password works for logging in as root to both the ssh command line and the web interface), the telnet service is terminated and Dropbear SSH is started instead.
![Traffic graph [Traffic graph]](https://static.lwn.net/images/2014/openwrt-bb-traff-sm.png)
From then on, most of the administration or monitoring that needs to be done can either use the command-line interface (CLI) or the LuCI Lua-based web interface. It uses the Unified Configuration Interface (UCI), which provides the CLI tool for the configuration of OpenWrt devices. For example, one of the first tasks is likely to be turning on the WiFi, which is easily done from LuCI, though it can also be done using UCI or by editing /etc/config/wireless directly.
Using LuCI is quite straightforward. It has hierarchical menus that govern most of the tasks an administrator might need to do. There are, naturally, realtime traffic graphs of various sorts, along with log file output, diagnostic tools (e.g. ping, traceroute), and other troubleshooting and monitoring aids available. Configuring various services, such as DHCP or DNS, is easy to do. LuCI restarts the services or network interfaces as needed to effect whatever changes were made.
Beyond that, there are some fairly complicated configuration options that one normally would not see in a router's web interface. The firewall configuration and monitoring (listing all of the different tables) is top-notch. Port forwarding, quality of service (QoS), VLAN, and other configuration are all quite accessible.
On the negative side, though, is the documentation, which suffers from a few flaws. It is disorganized, with information scattered on the Documentation page, wiki, and in the forum. You can often find what you are looking for in one of those places, but it is easiest to consult a search engine. After finding the topic you are looking for, though, you may encounter another problem: the information may be out of date—sometimes long out of date. This is not really meant as a knock on the project, as the versatility of the distribution means that there is an incredible amount of information to maintain. But it can be frustrating to new users.
![Available packages [Available packages]](https://static.lwn.net/images/2014/openwrt-bb-sw-sm.png)
Some of that versatility and complexity may be part of the reason there are several derivative distributions based on OpenWrt. We have looked at CeroWrt and the EFF's Open Wireless Router project (which is based on CeroWrt) in the last few years. Both of those focus on a single router (the WNDR3800) to try to cut down the complexity of the multi-platform problem. Documenting the base functionality of those routers is a much simpler task.
OpenWrt has, thankfully, taken a much larger bite; its work can be picked up—and simplified—by others. Development flows in both directions, though, as OpenWrt has adopted most of the anti-bufferbloat work that CeroWrt has done.
Beyond just the multi-platform support, OpenWrt's complexity comes from the sheer number of packages it supports. Numbers are hard to come by, but Attitude Adjustment came with nearly 3,500 packages, so one would guess that Barrier Breaker has at least that many. Certainly scanning through the package list in LuCI is eye-opening. One of the features for the release was a reorganization of the package feed into a single GitHub repository. For now, the older repository is still available, but it must be manually enabled.
![Package installation [Package installation]](https://static.lwn.net/images/2014/openwrt-bb-swinst-sm.png)
The opkg package management system works just as one would expect. Packages can be installed from the command line or LuCI and, as with any modern package manager, dependencies are automatically resolved. One of the features that will be coming is the ability to sign and verify packages, which is a welcome feature.
Security updates are somewhat problematic for OpenWrt, however. Kernel fixes require installing a new image. User-space vulnerabilities can be fixed by updating packages, but the distribution isn't really set up to handle the kind of advisory and update process that is normal for desktop and server distributions. Package signing seems like a step along the way toward a solution to some of these problems.
Barrier Breaker is based on the 3.10 kernel, which moves things along a good ways from the 3.3 kernel (with some backports from 3.5) that was used in Attitude Adjustment, but is still more than a year old at this point. The release notes for Barrier Breaker say that the next release (named "Chaos Calmer") will be based on 3.14 or some more recent kernel that has long-term support. Given that the project is aiming for a release of Chaos Calmer this year, it would seem that 3.14 is a good bet.
While it has been around 18 months between releases, OpenWrt certainly gives the appearance of being a highly active project. Another release before the end of the year would seem pretty aggressive, however. In any case, it is a distribution worth checking out for a wide variety of embedded Linux needs. As they say: Friends don't let friends run factory firmware. Perhaps that overstates things, but there are many things that can be done with an OpenWrt device—well beyond the manufacturer's vision.
Posted Nov 13, 2014 11:01 UTC (Thu)
by SimonO (guest, #56318)
[Link] (7 responses)
The installation of openwrt "Barrier Breaker" was easy on the tp-link archer c5, but applying the recipe(s) isn't as easy, because the documentation refers to various (but not all) devices of different architectures and it 's hard to figure out which architecture applies.
A way to start improving on this could be to use some kind of abstraction layer to name the various interfaces in a consistent manner and provide a translation table for each specific device. Another way would be to implement a couple of recipes under the LuCi WUI (which would problably also require some name remapping as well, to accommodate various architecture differences).
/Simon
Posted Nov 14, 2014 9:04 UTC (Fri)
by Felix.Braun (guest, #3032)
[Link] (6 responses)
I've found the abstraction layers that the uci system introduces complicating the issues. Fortunately (for people like me), you can just go about editing your config files by hand and more or less ignore these things.
If you don't like to work on the command line though, I can understand that you might not enjoy OpenWRT.
Posted Nov 14, 2014 9:48 UTC (Fri)
by SimonO (guest, #56318)
[Link] (5 responses)
I meant that if there was a more abstract way to name the interfaces (like "wan", "switch[0-9]", "radio[0-9]", etc) the configuration of openwrt could be copied to another device running the same version of openwrt. Some configurations may not work on another architecture, but this should be well documented for each device (which architecture it belongs to and possibly which recipes work on it).
This is (I think) the issue with the documentation mentioned in the article.
/Simon
Posted Nov 14, 2014 19:02 UTC (Fri)
by dlang (guest, #313)
[Link] (4 responses)
Posted Nov 14, 2014 22:06 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (3 responses)
Posted Nov 14, 2014 22:31 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
You can have different boards using the exact same chipset, what you are trying to detect is which network jack has the letters WAN printed on the outside of the case.
Posted Nov 14, 2014 22:44 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (1 responses)
You have to find something in the system which can uniquely identify the interfaces, which may be different for each model and revision, and then pre-stage that config in the firmware image. If the information just doesn't exist then you can't do it I guess but it seems there would be a lot of problems today if OpenWRT couldn't identify the wan, lan and wireless interfaces reliably, so that it runs the DHCP listener on the right side and the DHCP server on the right side.
Posted Nov 14, 2014 23:13 UTC (Fri)
by dlang (guest, #313)
[Link]
This is a very similar problem to what devicetrees were created to solve, the system can have identical hardware that's used in different ways, wired to different addresses, while being identical.
OpenWRT today solves this by having the knowledge in it's build system to create the appropriate defaults (for model Foo123a-2 eth0 goes in the WAN interface group while eth1 goes in the LAN interface group)
Trying to put this sort of config in the upstream udev rules seems very wrong, it's polluting those rules with a lot of very system specific data.
Linux already has mechanisms to rename interfaces, the question is just if doing so is the right thing to do or if it adds more confusion than it solves, along with the question of where you stick the configuration for this renaming so that you can copy the rest of the config from one system to another.
I'm not sure it's worth the effort, OpenWRT already has all it's firewall rules by WAN, LAN, etc so if you are using it's defaults as the starting place, you have the nice names. If you are going in under the covers to do things, then don't you want the real hardware names rather than names that assume that you are using it as an Internet Router?
Posted Nov 13, 2014 15:56 UTC (Thu)
by Darkmere (subscriber, #53695)
[Link] (5 responses)
Topping this off, OpenWRT doesn't in any way sign packages distributed for opkg, so you have no way of verifying the integrity of the package just downloaded over clear-text.
Posted Nov 13, 2014 22:38 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Is there a bug one can get CC'd on to see any progress with this?
Posted Nov 15, 2014 12:27 UTC (Sat)
by Darkmere (subscriber, #53695)
[Link] (2 responses)
Things might have changed on the OpenWRT front though.
Posted Nov 15, 2014 14:07 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 16, 2014 11:23 UTC (Sun)
by Darkmere (subscriber, #53695)
[Link]
The problem is also the compatibility. As packages & updates need to work on the non-https speaking systems still.
It can be solved, obviously. But that has to be done upstream and not in replies to an article on LWN.
Posted Nov 17, 2014 4:17 UTC (Mon)
by ras (subscriber, #33059)
[Link]
That's not really a problem. Debian doesn't download stuff over https either. It's secure.
> Topping this off, OpenWRT doesn't in any way sign packages distributed for opkg, so you have no way of verifying the integrity of the package just downloaded over clear-text.
This is the real issue.
Some have said space is issue, but it isn't really. Dropbear (which they do include) has all the crypto stuff you need, which it gets from an embedded version of libtommath and libtomcrypt. You could split that out, making it available to opkg.
So all it really needs is somebody to do the work. But the work is considerable. It's not just the coding. The logistics of securing the projects private keys would be a real headache.
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
OpenWrt releases "Barrier Breaker"
Securing binaries