OpenWrt/LEDE v17.01.5 service release

Upgraded WRT3200ACMv1 from .4 without issue. Kept settings.

P.S. Anyone tried 18.06.00 RC2? I might give it a go on a backup WRT1900ACSv1

No idea about WRT1900, but I've been running rc1 and rc2 on WRT32000 (with eduperez'es updated WiFi drivers) and both release candidates have been great for me.

1 Like

thanks for fixing it :slight_smile:

@stangri Thanks. Loaded 18.06.00 RC2 on WRT1900ACSv1. Kept settings. So far so good.

17.01.05 is installed and working without problems on these TP-LINK access points:

TL-WR741ND version 4

No problems observed.

Thanks everyone for the excellent work!

sit (6in4 kernel driver) is broken in 17.04.5, because an upstream commit.
It should be fixed in 4.4.143. The patch is pending now.

I uploaded the system upgrade bin, verified the sha, and flashed the new firmware. When the router reboots, it shows I am still running 17.01.4 with kernel 4.4.92. I see no errors in the logs. Has anyone else experienced this? This is for the WRT3200ACM v.1. Bin file uploaded: lede-17.01.5-mvebu-linksys-wrt3200acm-squashfs-sysupgrade.bin

Likely means the firmware didn't take. The WRT series has two firmware partitions. If the boot pointer did not get updated or the system had a problem (corruption, settings conflict, etc.) booting to the new firmware, it will automatically boot to the other partition which will still have the previous firmware and settings.

You can save your config, uncheck the keep settings option, re-flash the new firmware. You can trying to restore your settings, but if it's a settings conflict, you will likely get the same result.

I also tried with the option to not keep my settings and the same result. I wonder if I could try with the full system image rather than the bin upgrade?

Curious to know if 17.01.5 fixes the slow wifi using N, 20 hz width on the 2.4 band or if that is a feature for 18.0x instead?

Edit: Sysupgraded it. 802.11N speed is fixed in this release, and there are no issues with SQM Cake.

Edit 2: I've since moved on to 18.06, which is running very well and the 802.11N is more robust. I would recommend doing a clean install of 18.06.

Would be nice if in the future the keep configuration settings had a companion checkbox, "Re-install previously installed software packages?"

You may be experiencing a problem that also affects the WRT32x, which is a similar router: WRT32X Sysupgrade Broken

I erased all the settings, upgraded, and then uploaded the backed up settings. I am now running 17.01.5 :slight_smile:

I like this idea, but with a caveat. It should only do that for packages that the user explicitly chose to install. Not system bundled packages (can change), and not packages that were installed as dependencies (can change). Opkg currently makes no such distinction; "opkg list-installed" lists every installed package regardless of how it got there.

Another potential issue is third-party repos and also third-party packages that were installed as a one-off using a URL ("opkg install") or an offline install. Those might not be compatible with the newer OpenWrt version, and might require a URL change.

Even if a user sticks entirely to the official repos (as most users probably do), there's a possibility that a package might not be available in the newer system's repo. So there would need to be a way for the system to alert the user about packages from the old version that failed to auto-install in the new version.

This might sound like I'm bashing your idea, but I actually think it's great. Done properly, it would make upgrading much easier for the user, and therefore make it more likely that people would stay up-to-date. It's just not without complication, and that might explain why OpenWrt has never done it.

Hello guys!

Do you know what this error could it be? Since, my Linksys WRT 3200ACM/1900ACS are giving these errors and I have know idea, what it could be and it is a showing stopper for me:

[   69.072330] sit: non-ECT from with TOS=0x2
[   69.130311] sit: non-ECT from with TOS=0x2
[   69.218354] sit: non-ECT from with TOS=0x2
[   69.223538] sit: non-ECT from with TOS=0x2
[   69.294836] sit: non-ECT from with TOS=0x2
[   81.591915] net_ratelimit: 352 callbacks suppressed
[   81.596828] sit: non-ECT from with TOS=0xe
[   81.661946] sit: non-ECT from with TOS=0xe
[   81.667163] sit: non-ECT from with TOS=0xe
[   81.672335] sit: non-ECT from with TOS=0xe
[   81.677499] sit: non-ECT from with TOS=0xe
[   81.682669] sit: non-ECT from with TOS=0xe
[   81.687832] sit: non-ECT from with TOS=0xe
[   81.693003] sit: non-ECT from with TOS=0xe
[   81.698168] sit: non-ECT from with TOS=0xe
[   81.703336] sit: non-ECT from with TOS=0xe
[   87.759190] net_ratelimit: 78 callbacks suppressed
[   87.764012] sit: non-ECT from with TOS=0x3
[   88.749717] sit: non-ECT from with TOS=0x3
[   89.755460] sit: non-ECT from with TOS=0xa
[   89.818519] sit: non-ECT from with TOS=0xa
[   89.827336] sit: non-ECT from with TOS=0xa
[   89.892702] sit: non-ECT from with TOS=0xa
[   89.897866] sit: non-ECT from with TOS=0xa
[   89.964864] sit: non-ECT from with TOS=0xa
[   89.970028] sit: non-ECT from with TOS=0xa
[   89.975246] sit: non-ECT from with TOS=0xa
[   93.764896] net_ratelimit: 3191 callbacks suppressed
[   93.769893] sit: non-ECT from with TOS=0xa

... or the new version might have slightly larger kernel and larger packages, preventing installing the same
packages . Similaly, there maybe new dependencies taking more space.

Speaking of the "Keep settings" checkbox, I think it would be nice if it were a bit smarter. Rather than copying over every single UCI setting to the newer OpenWrt version, it could copy only the UCI settings that the user had changed from the default. That way, for every setting that the user hadn't changed, they would get the benefit of whatever new defaults there might be in the newer version. Easy migration, while still benefiting from changes.

I'm even imagining a system update checker built into LuCI. It could have a pop-up menu to check for new system versions daily/weekly/monthly/manually. If the automatic checker found a system update available, it would notify the user via email. Then the LuCI update tool could offer to download the update for you, verify the sha256 checksum and GPG signature automatically, and then flash the update (with user confirmation, plus the checkboxes for preserving user-changed settings and packages that the user explicitly chose to install). And outside of system updates, maybe there could be a way to automatically install package updates that have been marked as critical (security fixes and things like the tc & cake issues @jow and @ldir talked about in this thread).

I'm just spitballing here. I know it's a volunteer run project and that these are embedded devices with limited storage and processing, so if these ideas aren't feasible I can totally understand. Thanks for making such a great firmware! :slightly_smiling_face:

Might be related to this

This patch queue (optionally) improves the backup handling, I've been using it for almost half a year by now:

I have installed yesterday v17.01.5 on my Tp-Link TL-WR1043ND v1.8 and Tp-Link TL-WR841N v9 routers as upgrade from v15.05.1. Kept all settings, and both are working perfectly. Even the smaller one with 4MB flash is fully functional and working. The bigger runs OpenVPN without any problem.

Dear Dev Team! These are 8 and 4 years old hardwares, worth of only few bucks or nothing, and you made them like a new. What you do is simply amazing, i didn't find any good place to express my highest appreciation, so flooding this topic, sorry for that. Just wanted to tell you how much i like your project and how useful you are for ordinary people, having old outdated stuff too. Thank you for the brilliant work!


Thanks so much! I updated the compress lzo to yes and now it works perfectly. Thanks!