The OpenWrt community is proud to announce the second service release of OpenWrt 19.07. OpenWrt 19.07.2 focuses on security and device support. It notably fixes a security issue in ppp and improves support for migrating devices from ar71xx to ath79.
Selected highlights of this service release are:
fix a ppp buffer overflow vulnerability CVE-2020-8597
fix a libubox regression in 19.07.1 that caused umdns to stop working
update Linux kernel from 4.14.167 to 4.14.171
improve reliability of uhttpd handling of HTTPS requests under heavy load
I upgraded my two x86 systems from 19.07.1 to 19.07.2. The first system on geode hw seems to work fine and upgrade did as usual. The seconde system on VM with x86_64 target lost its Luci as the system refuse to start uhttp process. Log lines:
Sat Mar 7 12:01:26 2020 daemon.info procd: Not starting instance uhttpd::instance1, command not set
Sat Mar 7 12:01:26 2020 daemon.err procd: unable to find /sbin/ujail: No such file or directory (-1)
I tried to find, what package provides /sbin/ujail, without much success. Found these from the forum.
But weren't much for help without me digging deep into the subject. Before I'll go deep into this, I'd like to ask those familiar, how to fix this? Or is this a regression bug slipped in preparation of the release, as one might think so as upgrade on geode went without a hitch.
As usual I upgrade with Image Builder from release target.
Sat Mar 7 12:01:26 2020 daemon.err procd: unable to find /sbin/ujail: No such file or directory (-1)
Sorry about that, I've forget to fix it in 19.07, just send fix for that harmless error message.
Sat Mar 7 12:01:26 2020 daemon.info procd: Not starting instance uhttpd::instance1, command not set
This error message is probably not related to the ujail error message above. I've just run x86/64 19.07.2 image in QEMU and uhttpd starts just normaly.
I did not have to install luci-compat on my EA6350v3 or EA8500 with 19.07.0 or 19.07.1, but with 19.07.2 I got a lot of these errors (one for every luci package I tried to install) and no luci menus for the packages showed up in the GUI:
* opkg_install_cmd: Cannot install package luci-app-minidlna.
* check_data_file_clashes: Package luci-compat wants to install file /usr/lib/lua/luci/tools/webadmin.lua
But that file is already provided by package * luci-base
I fixed it by doing this before installing my usual packages:
opkg install --force-overwrite luci-compat
Other than that minor hiccup, 19.07.2 is running great on my two AP's. Thank you!
Still having problems on my main gateway router with 19.07.2 though. An IP will not assign to the WAN (DHCP client) from my ISP with 19.07.2 on my EdgeRouter X. This did not work in 19.07.1 either. I flashed snapshot (r12464) and that still works fine on my EdgeRouter X, so I'll stay with snapshot on the EdgeRouter X.
system on VM with x86_64 target lost its Luci as the system refuse to start uhttp process.
Found a fix, at least partial. I removed my own certificate and key by rm /etc/uhttpd.* and uhttpd was up and running with new certificate and key in no time.
I did not manage to find out, what was the real fault. Setting export DEBUG=1 INIT_TRACE=1 PROCD_DEBUG=1 and running /etc/init.d/uhttpd start 2>&1 | tee debug.log did not reveal anything. I compared /etc/config/{luci,uhttpd} between the system and the release. They did not differ. uhttpd binary seems to not have an debug option.
So I went on by intuition to remove my certificate and managed to hit the solution. Although I'm still left without a clue, what made uhttpd fail with my certificate, which worked in previous version.
Don't know, I did not think that 5.4 has been defaulted on any targets pending testing. I assume that was a mistake and the reason it is not to be seen in the stable releases, perhaps ping @jow.
Probably some hiccup during the build of release for kirkwood, new build is just running, so if everything goes well, the images should be available in about 90 minutes.
It was intentional, please note, that 5.4 kernel is enabled on master/snapshot, 19.07 is based on 4.14.y kernel. That missing release image binaries were caused by some buildbot hiccup which was simply just missed.
thanks, alot devices update here all working good. i still don't understand why there is no stable immage for the comfast 314 v2. that is in ath79 from long time.
Updated to latest release 19.07.2 Archer C60 V2 and all working good
I also have Archer C20 V5 and would like to update it to this latest stable release, it's working with 18.06.5, but I want to ask dear developers to create stable release 19.07.2 for this device Archer C20 V5
Thank you so much
Best Regards
Update on TP-link RE450 and Archer C7 run fine except the one bug already found in 19.07.1: Mesh-connected AP wouldnt work. Same workaround necessary as in previous version.
connect AP to lan and switch the modules using console