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 - #46 by farmwald
I erased all the settings, upgraded, and then uploaded the backed up settings. I am now running 17.01.5 
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 http://example.com/example-package.ipkg") 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 31.27.5.181 with TOS=0x2
[ 69.130311] sit: non-ECT from 31.27.5.181 with TOS=0x2
[ 69.218354] sit: non-ECT from 31.27.5.181 with TOS=0x2
[ 69.223538] sit: non-ECT from 31.27.5.181 with TOS=0x2
[ 69.294836] sit: non-ECT from 31.27.5.181 with TOS=0x2
[ 81.591915] net_ratelimit: 352 callbacks suppressed
[ 81.596828] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.661946] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.667163] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.672335] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.677499] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.682669] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.687832] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.693003] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.698168] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 81.703336] sit: non-ECT from 31.27.5.181 with TOS=0xe
[ 87.759190] net_ratelimit: 78 callbacks suppressed
[ 87.764012] sit: non-ECT from 31.27.5.181 with TOS=0x3
[ 88.749717] sit: non-ECT from 31.27.5.181 with TOS=0x3
[ 89.755460] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 89.818519] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 89.827336] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 89.892702] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 89.897866] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 89.964864] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 89.970028] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 89.975246] sit: non-ECT from 31.27.5.181 with TOS=0xa
[ 93.764896] net_ratelimit: 3191 callbacks suppressed
[ 93.769893] sit: non-ECT from 31.27.5.181 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! 
This patch queue (optionally) improves the backup handling, I've been using it for almost half a year by now:
https://patchwork.ozlabs.org/project/openwrt/list/?series=37466
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!
2 Likes
Thanks so much! I updated the compress lzo to yes and now it works perfectly. Thanks!
very nice! can we have this in master?
I agree. This is a fantastic project.
Just updated three Rosewill RNX-N150RT (rebranded tp-link TL-WR741N/ND v1) routers from 17.01.4 to 17.01.5, with "keep settings" selected. These are set up as access points supporting two VLANS.
Perfectly smooth-- many thanks to the developers.
Archer C7 v2 updated to 17.01.5 and working like a charm.
Many thanks to all the developers making posible LEDE/OpenWRT project going forward.
This is a bug in the kernel. Upstream patch is pending. You can patch it yourself or wait a bit.
Ciao, do you know where i can find this patch?