Distributions

LEDE-17.01 is coming

Many of the changes made in LEDE since the 2015 OpenWrt "Chaos Calmer" release will not be immediately visible to most users. The core software has been updated, of course, including a move to the 4.4.42 kernel. There are a number of security-oriented enhancements, including a switch to SHA256 for package verification, the disabling of support for several old and insecure protocols, compilation with stack-overwrite detection, and more. There is support for a number of new devices. Perhaps the most anticipated new feature, though, is the improved smart queue management and the WiFi fairness work that has been done as part of the bufferbloat project. It has been clear for some time that WiFi should work far better than it does; the work that has found its way into the LEDE release candidate should be a significant step in that direction.

Your editor decided that it was time to give LEDE a try, but there was some shopping to be done first. Getting the full benefit from the bufferbloat and airtime fairness work requires the right chipset; most of this work has been done on the Atheros ath9k driver. So the first step was to go out and pick up a new router with ath9k wireless. That is where the things turned out to be harder than one might expect.

The LEDE web site has a table of hardware that can be used to obtain information about specific routers. The table does not, however, make it easy to find out which routers have the best support. Router vendors, naturally, tend not to be forthcoming about which chipsets they have used in their devices, and the LEDE site does not offer a way to find devices with suitable chipsets. Much of the information that does exist is actually hosted on the OpenWrt site, with the LEDE site simply pointing to it. In this regard, at least, LEDE may have split from OpenWrt, but it's still somewhat dependent on it.

A fair amount of time spent between the LEDE site and online retail sites failed to yield any helpful answers on which router to buy. Fortunately, many years of experience and a graduate degree have left your editor with an important bit of wisdom: when all else fails, ask the net. A quick discussion on Google+ yielded the suggestion that the TP-Link Archer C7 would be a good option. Shortly thereafter, a new router was sitting on your editor's desk, waiting to have its factory firmware unceremoniously blown away.

As it turns out, a bit of ceremony was required after all. The stock firmware on the Archer C7 has the endearing feature that it will refuse to flash a firmware file if that file's name has more than one period in it. The LEDE firmware file, as found on the "tech data page" for the C7, is named:

    lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-generic-archer-c7-v2-squashfs-factory.bin

The router will not even try to flash that file until it has been renamed to something without all those periods. The LEDE page helpfully neglects to point out this little detail, but it can be found on the OpenWrt page for this router.

After that change, the router would recognize the firmware file, but still refused to flash it, giving instead a helpful "Error 18005" message. More time spent on the OpenWrt page quickly turned up the fact that TP-Link routers sold in the US will only flash firmware with a special US header. Looking in the LEDE download directory turned up a variant on the above file:

    lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-generic-archer-c7-v2-squashfs-factory-us.bin

The LEDE "tech data" page links directly to the international version of the file, without even mentioning that there is a US-specific version (and, seemingly, versions specific to the European Union and Israel as well) that some users may want to grab instead. Once that file was downloaded and suitably renamed, the factory firmware finally consented to overwrite itself with the LEDE release candidate.

From that point on, things went relatively smoothly. Initial configuration of the router must be done via a wired connection, since LEDE leaves the wireless interfaces disabled by default. Turning them on is easy enough, as is most of the rest of the router configuration, especially if one is already used to the LuCI web interface. Somebody has spent some time cleaning up the look of LuCI but, underneath, it has not changed much from the OpenWrt version. The expected features (DNS, DHCP) work without trouble. Your editor's network connection includes native IPv6 and, as with OpenWrt, the LEDE router propagates that through to the local network automatically.

When the first release candidate came out, the Quick Start Guide suggested setting up smart queue management (SQM), pointing to yet another OpenWrt page for the details. That involved installing the luci-app-sqm package, and that operation failed, complaining about a checksum failure on the downloaded package. It appears that the LEDE repository ran out of space and was corrupted as a result. Things were eventually rebuilt and, a day or two later, the package installed without trouble.

Setting up SQM with LuCI requires filling in a form with the maximum upload and download speeds of one's network link. Once that is done, traffic shaping will be configured to avoid overrunning the link and filling buffers on either side of it. It appears to work; the DSLReports speed test reports a bufferbloat grade of "F" without SQM, and "A+" with it enabled. The cost is a few percent of maximum throughput, almost always a worthwhile price to pay for significantly improved latency.

This configuration will, of course, do bad things should the speed of the connection to the network change — something that does happen at times. Hopefully, someday, we can have debloated links without the need for this kind of manual configuration.

About one week after the -rc1 release, a second release candidate was made available. One of the visible changes in -rc2 is an upgrade to the 4.4.47 kernel. The process of downloading the new release candidate and flashing it (without the need to worry about periods in the name and such this time around) went smoothly, and the router came back up with its settings intact. User-installed packages (luci-app-sqm, for example) must be reinstalled, but their configuration is generally in place afterward and does not need to be recreated.

As with OpenWrt, LEDE does not readily support upgrading individual components; the opkg package manager can do it for packages other than the kernel, but it's not a common mode of operation. LEDE, like OpenWrt, has no structure in place for the tracking of security issues, the releasing of security updates, or notifying users of security problems. Given that the router sits in a critical spot at the center of the network, and given that many users tend to forget about their router once it works properly, this is a somewhat discouraging state of affairs. Hopefully somebody will eventually find the resources needed to solve this problem for the wider community, but that has not happened yet.

Another thing that has not happened yet is a reunification of LEDE and OpenWrt, despite the conversations that were happening at the end of last year. The split may have allowed LEDE to move more quickly than before, but it appears to have slowed OpenWrt significantly and it's not clear that LEDE has, so far, built up a large enough community to sustain a project of this scale in the long term. We need an active and vital router-distribution project, so the possibility that these projects may not thrive is discouraging.

But, then, perhaps that is an overly pessimistic impression that results from the inevitable chaos of setting up a new distribution project. Despite issues with documentation, web sites, and repositories, the actual software from LEDE appears to be solid as a rock. The new router is happily doing its job, and there is no chance that it will see its factory firmware reinstalled. The LEDE 17.01 release is shaping up to be another solid router distribution from the OpenWrt/LEDE community.

Comments (16 posted)

Distribution quote of the week

Comments (none posted)

Gentoo LiveDVD "Crispy Belgian Waffle", FOSDEM 2017 edition

Comments (none posted)

Sailfish OS 2.1.0 now available to early access for Jolla devices

Comments (4 posted)

De-Branding of Icedove, reintroducing Thunderbird packages into Debian

Full Story (comments: 1)

openSUSE Elections 2016/2017 resumed

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly (February 13)
• Lunar Linux weekly news (February 10)
• openSUSE news (February 9)
• openSUSE Tumbleweed – Review of the Week (February 11)
• Ubuntu Weekly Newsletter (February 12)

Comments (none posted)

SemiCode OS Might Be Your Next Development Platform (Linux.com)

Comments (none posted)