LEDE v17.01.1 service release

The LEDE Community is proud to announce the first service release of
stable LEDE 17.01 series.

LEDE 17.01.1 "Reboot" incorporates a fair number of fixes back ported
from the development branch during the last six weeks.

Some selected highlights of the service release are:

  • Linux kernel updated to version 4.4.61 (from 4.4.50 in v17.01.0)
  • Reworked opkg to reduce resource usage
  • Bug fixes and improvements for MT7620 radios
  • Bug fixes and improvements for the odhcpd DHCPv6 server
  • Bug fixes for the umdns mDNS implementation
  • Fixed and improved nslookup applet
  • API additions to the libubox library
  • Improved service termination logic in procd
  • Assorted platform fixes for ar71xx, arc770, archs38, bcm53xx,
    brcm2708, kirkwood, lantiq, mvebu, ramips and x86

For a detailed list of changes since 17.01.0 refer to

For latest information about the 17.01 series, refer to the wiki at:

To download the v17.01.1 images, navigate to:

A big thank you goes to all our active package maintainers, testers,
documenters and supporters.

Have fun!

The LEDE Community


Thanks a lot to all involved developers and maintainers!

I really appreciate the effort towards a stable and supported release branch that users can rely on. If this effort can be kept up, I think this is a strong advantage over OpenWrt from a user perspective.

Hi, ran into some bumps doing a sysupgrade using keep-config but then I lost internet access twice over to all devices which remained lost even after downgrading to previous version and restoring backup of conf. Now that I have an understanding of what happened, here is how to fix it or avoid it.

  1. Ensure you have a SSH client installed on your computer so you can connect to the router through the terminal and that it works before you proceed because you will need it! This will let you edit conf files and also check from the router if you're able to ping the internet.

  2. In /etc/dnsmasq.conf I had dnsmasq listening on 2 interfaces with bind-interfaces on due to an openvpn setup but this isn't going to work at first for whatever reason which might be related to the openvpn package not being currently present even though the interface is still defined? Sysupgrades do not keep packages, you have to reinstall them. I had to use SSH and then the vi editor (can't just install nano, because lede's software suite depends on resolving a domain name not an IP address) and comment out those lines, at which time DNS services started working again and I was able to properly access the internet. This brings us to item 3 below.

  3. Because there was no functioning DNS being served by the router as a result of my dnsmasq settings in item 2 until they were commented out, the computer in turn could not connect to the router because it was not receiving a DHCP 192.168.1.x IP address. I had to set the computer to a static IP address so it could connect to the router, do the cleanup in item 2, at which time changing the computer back to dynamic DHCP worked fine and internet access was present.

If I had not selected 'keep settings' I'm fairly certain everything would have been just fine, but I wanted to keep them so I wouldn't have to reconfigure everything at this time of night. So a lesson learned is that if you have been installing packages and editing conf files, best to do this upgrade on the weekend not a weeknight!

Hope this helps someone.

Why ICMP traceroute (traceroute -I) is disabled, :< is there any way to enable it? I need it for troubleshooting.

There's a longtime OpenWRT error that has a tendency to repeat itself dozens and dozens of times in the log, seemingly for no apparent reason:

daemon.err uhttpd[xxxx]: sh: write error: Broken pipe

The problem is that it would tend to dominate a log with its repetition, obscuring more important things.

I saw a comment a few months ago saying that it was fixed in 17.01.1 though (the commenter was talking about the prerelease of that at the time), but I can't find any mention of it in the release notes.

Does anyone know if it's fixed?

Nothing to do with LEDE 17.01.1, uhttpd, LuCI or even Openwrt itself...

That is a generic error that is typically coming from a package's init script or hotplug script, where an uninitialised (or empty) variable is used. Typically e.g. a config option has no default value and if the option is missing from the config file, the variable remains empty. When that shell variable is then used in a comparison like "is it greater than", the shell complains about empty value, and uhttpd passes the error.

Such errors have been seen in the last few years e.g. in ddns-scripts, mwan3 etc. packages. If the package has a status component on the LuCI overview page and that is refreshed every 5 seconds, the log spam gets visible.

See e.g.

Nothing to do with LEDE 17.01.1, uhttpd, LuCI or even Openwrt itself...

Ah, OK, thanks for the explanation and context. I recall now that it was triggered by errant scripts, but I was hoping/assuming that it could be compensated for by putting in some kind of rate-limiting or maybe some other functionality that drops duplicates.

Great work to all the contributors! I really like these frequent updates to the stable branch. It keeps my router up to date and secure. Huge props to everybody making this happen :slight_smile:

In the "LEDE v17.01.1 Changelog", there is a section "Kernel (9 changes)" which ends with "6ca5ccc kernel: update kernel 4.4 to 4.4.61 (+9,-117)". But then, further down, there are SoC specific sections that specify, for instance, "0dcc4d2 kernel: update kernel 4.4 to 4.4.59 (+135,-527)", for the brcm2708.

Which kernel version, then, is being used in the brcm2708, "4.4.59", or "4.4.61"?

I'm confused. Does the firmware for these different devices contain different versions of the kernel? Why is there a "kernel" changelog section if those changes do not apply globally?

The same (4.4.61) version is used for all arches. The SoC specific sections mention the .59 commit explicitely because this bump commit happened to touch patches specific to these SoCs.

What happened to the ar7 target? It is neither in 17.01.0 nor in 17.01.1, nor could I find a commit that removed support for this target.

The ar7 target is still stuck on kernel 3.18, which was EOLed upstream in january, therefore 17.0.x only includes architectures using the upstream supported LTS kernel 4.4.x.

OK, thanks, found it in the changelog of 17.01.0: https://git.lede-project.org/?p=source.git;a=commitdiff;h=982dd01ac37f64892deb4003f4e53d3bc7a114c4

There are 3 targets on the list stuck on 3.18 which I care about (adm5120, adm8668 and ar7). What can I do to ensure these are available in the next LEDE release?

Those targets would need updating to kernel 4.9.x, urgently - and some continued care. Just treat it like any other patch for lede, either by filing a pull request on the github mirror or mailing the corresponding patch series to the mailing list (given the expected patch size, the pull request is probably a better option).

[quote="RaylynnKnight, post:15, topic:3134"]
There are 3 targets on the list stuck on 3.18 which I care about (adm5120, adm8668 and ar7). What can I do to ensure these are available in the next LEDE release?
[/quote]Create the needed patches to bring those targets to kernel 4.9...
Looks like no core developer has been interested enough in those targets to upgrade them.

Examples of kernel major version bumps:

Both of those were transitions from 4.4, so the task of bringing targets from old 3.18 is likely much harder.

You might also read these old threads for examples: https://forum.openwrt.org/viewtopic.php?id=67962 and https://forum.openwrt.org/viewtopic.php?id=67420

1 Like

Given that the affected platforms are rather old and typically very low-end, the problem isn't 'just' updating them to kernel 4.9.x, but also getting kernel and defconfigs small enough to actually result in a working image small enough to fit. This is a problem the more modern targets like mvebu or ipq40xx/ ipq806x don't have (as those devices ship with >= 16 MB flash and >= 128 MB RAM, while all software -including the kernel- has a tendency to grow over time/ with new versions).

I would like to know if this release contemplates the stability with Acher C2600 v1.1.

Congratulations on this milestone! I must say however, LEDE is acceptable stable for a while already. I'm running it on linksys wrt, linksys Exxx, Netgear, TP-Link and comiled it to intel x64 running in virtualBox on Windows and everything is stable. no connection drops or reboots or hangups on any of the devices since december 2016.

Of course more needs to be done, but once it's setup and running. Very stable!