Previewing OpenWrt 15.05

Routers, it seems, are easy to forget. Your editor's router, at the beginning of the research for this article, was running OpenWrt 10.03.1, which was released in 2011 and featured a bleeding-edge 2.6.32 kernel. Routers, it seems, are easy to forget as long as they work; this one had been happily working away since this article was written nearly four years ago. This router could have been updated a number of times over those four years, but that didn't happen; your editor suspects that frequently updated routers will be the exception rather than the rule, especially when one is talking about small, consumer-level devices.

Calming the chaos

There is no question that this particular device was overdue for an update. Still, it takes a certain state of mind to take a working router (the only working router in the house) and flash a release-candidate version of the operating system onto it, skipping over several releases in the process, shortly before the weekly publication deadline. Your editor, not always known for his wisdom in such things, went for it — and got away with it. The upgrade worked, the router booted properly, and settings were preserved. Users with more complex setups may not have had such good luck, but, for a simple router configuration, this multi-version upgrade works fine.

Once it's done, the end result doesn't look a lot different than what was there before. The web-based LuCI management interface has been cleaned up a bit, but is essentially the same as it was in 2011. To a first approximation, the router does what it did before: it sits there and routes packets.

This impression overlooks the fact that quite a bit of work has been done in the less-visible parts of the system. The kernel has been pulled forward to 3.18.14; that will bring a lot of improvements with it. For example, quite a bit of work addressing the bufferbloat problem happened between 2.6.32 and 3.18; integrating and making use of those kernel changes happened mostly in the derivative CeroWrt project, but the changes have generally found their way back to OpenWrt. Support for IPv6 has improved considerably over the years. There is also, naturally, support for a number of new hardware platforms.

There are some new security features in the 15.05 release. The distribution's package-signing mechanism now evidently uses the ed25519 signature system. Work has gone into hardening the OpenWrt build using the various features (stack protection, for example) provided by GCC. The uhttpd web server can now force the use of TLS. And so on.

There is also a new "jails" mechanism built into the router, meant to prevent the compromise of one daemon process from being escalated into a compromise of the router as a whole. Documentation for this feature, it must be said, does not seem to have escaped from the jail yet, so there is little information available on how it works or how to use it. This posting from OpenWrt developer John Crispin offers some clues, though. It is based on the use of mount namespaces to isolate a jailed process from the filesystem as a whole; it also uses the seccomp mechanism to limit the system calls that a jailed program may invoke. Future plans call for the addition of user and network namespaces, fancier seccomp filtering, control-group support, and more.

All told, 15.05 looks to be a solid OpenWrt release, and the project is working hard on more useful stuff for future releases. Among other things, the next release after 15.05 will use the musl C library by default. Longtime OpenWrt release watchers will also be amused by the probable name for this release. OpenWrt's tradition has been to name its releases after alcoholic beverages in alphabetical order; the "D" name, instead, looks to be "Designated Driver."

A couple of concerns

Your editor can find things to worry about in any project, and OpenWrt is no exception. For example, if one looks at the above-linked message regarding the jail facility, one will find this bit of text:

That simple change can be found in this patch in the OpenWrt repository. Where you will not find it, though, is in the mainline kernel. Similar things can be found throughout the OpenWrt kernel. There are 243 patches in the "generic" part of the repository; the ar71xx subdirectory (supporting your editor's WNDR3700v2 router) has 88 more. These patches represent features (and, crucially, hardware support) that are not available in the mainline kernel; they also make work for OpenWrt developers, who must go through a lengthy forward-porting process every time they move to a new kernel.

There are OpenWrt developers who push code back upstream, but one gets the impression that they are in the minority. It looks like OpenWrt is caught up in the same situation as embedded developers worldwide; they are busy just getting everything to work and don't necessarily have the time to push changes back upstream. If there are aspiring kernel developers out there looking for a place to get started, working to move some of OpenWrt's patches upstream would be a great service to both projects.

There is one other concern that is worth raising: the OpenWrt project still lacks processes for the creation, distribution, and application of security updates. The "application" part is a hard problem due to the limited amounts of storage available on most consumer-level routers (the WNDR3700v2 has a total of 16MB, for example). OpenWrt uses squashfs to cram as much software possible into that space; squashfs does not handle replacing existing files well. So, realistically, the only way to update the software on systems like that is to do a full update, which is a multi-step process whenever add-on packages are involved.

There were rumors a few years ago about a better package-update mechanism under development for OpenWrt, but that has never seen the light of day. Even the full-update approach could be made to work, though, if there were a process for identifying security issues and making the updates available. OpenWrt does not appear to have any such process. So there is no way to notify users of problems, and no way to get fixes out to them in a timely manner. Users are left to pay attention and apply upgrades when they become available, which is not all that frequently. And, as has already been seen, even relatively aware users are not always paying attention to the state of the software on their routers.

That said, a simple fact remains true: one of the best ways to improve the security of a consumer-grade router is to dump the factory firmware and install a distribution like OpenWrt on it, preferably before ever exposing it to the Internet. A default OpenWrt installation is configured for security, and the project's developers are working on improving security in a number of areas. But, someday, it would be nice to see a better process for reacting to the security issues that will inevitably come about after an OpenWrt installation is put online.

All told, OpenWrt is a solid contribution to the wider Linux ecosystem. This distribution allows us to take control of an important appliance, make it serve our needs precisely, and add interesting functionality. It serves as the base for other projects, including CeroWrt and Gargoyle; some commercial router vendors also base their firmware on OpenWrt. Your editor would not consider buying a router that lacked OpenWrt support. Happily, the project appears to be going strong and such support will only get better in the coming years.