The OpenWrt community is proud to announce the second release candidate of the upcoming OpenWrt 19.07 stable version series. It incorporates 126 commits since the previous release candidate 19.07.0-rc1.
With this release, the OpenWrt project brings all supported targets back to a single common kernel version and further refines and broadens existing device support. It also provides initial support for the new ath79 target, the future device tree based successor of the popular ar71xx target. For 19.07, both targets are still built, but it is recommended to switch to the ath79 target whenever possible: future releases of OpenWrt will drop support for the ar71xx target.
Linux kernel updated to versions 4.14.156 (from 4.14.151 in v19.07.0-rc1)
GCC update to version 7.5.0 (from 7.4.0 in v19.07.0-rc1)
Hostapd update to version 2.9
Device support bugfixes for many devices
Security fixes for curl, e2fsprogs, expat, wolfssl, intel-microcode
Sysupgrade bugfix for an issue that could cause sysupgrade to silently fail to upgrade
Added support for the following devices: YunCore XD4200 and A782, TP-Link Archer C60 v1/v2, ALFA Network Quad-E4G and R36M-E4G, AVM FRITZ!Repeater 1200
Disable image generation for several devices due to insufficient flash space for the default set of packages. Images can still be built with the help of the ImageBuilder or SDK with a more minimal set of packages
When upgrading from 19.07.0-rc1, if you are affected by the sysupgrade bug, you need to manually edit /lib/upgrade/stage2 and add /usr/share/libubox/jshn.sh to list of files in the install_file line (around line 51).
Known issues:
Sysupgrade from ar71xx to ath79 and vice versa is not officially supported, a full manual reinstall is recommended to switch targets for devices supported by both ar71xx and ath79
Images for some device became too big to support a persistent overlay, causing such models to lose configuration after a reboot. If you experience this problem, please report the affected device and consider downgrading to OpenWrt 18.06 or using the Image Builder to pack a smaller custom image
Some optional GUI packages crash with an error about missing “cbi.lua”, install the luci-compat package to fix these
Possible Wi-Fi issues with ath10k-based boards. If you encounter such an issue, please file a bug report against openwrt-19.07.
Getting extreme jitter/latency (ping from router to device) when moving the pads (e.g. send a lot of packets I guess) on my Google Stadia controller which is connected via 5GHZ wifi. No problems whatsoever when using rc-1 nor when using usb cable instead of WIFI.
Can someone provide hints at what packages I should look first to try and pinpoint the issue as part of creating a bug report?
TP-Link Archer C60 v2 ath79, when enabled 5ghz radio, memory rapidly decreases and luci shows error within 1 minutes: Failed to create CGI process: Out of memory.
When I disable 5ghz radio in 1 minutes before error (under ~12mb) memory gets back to the normal (~30mb)
rc2 working fine without issues on EdgeRouter X (home gateway) and Linksys EA8500 (AP wired to EdgeRouter X).
rc2 not working on EA6350v3 (AP wired to EdgeRouter X). Memory usage starts high and climbs until the oom_reaper does it's thing and starts killing processes after 12-24 hours. Tried: rc1, snapshots, replacing ath10k-4019-ct with non-ct packages on rc2, full reset and reconfigure with minimum packages installed (just luci and luci-stats): same issue with all preceding debug attempts. Details in bug report and other posts. I won't repeat that here.
Just the opposite for my ipq4018 EA6350v3. A few clients would not connect due to connection delays and 5G signal to noise and speed were much worse when I tried the classic drivers. That, and the classic drivers did not fix the system crashes. Many months ago, snapshot and pre-rc1 19.07 worked well on my EA6350v3, but currently it's just not usable.
Using a TP-Link c2600. Had to revert to 18.06.05 from 19.07 rc2. The latter was causing terrible delays in wifi, such that streaming services frequently resorted to the spinning wheel of frustration. Once some time had passed, ~30 seconds or so, operation would resume normally. I use my router strictly as an AP hardwired to a Netgate pfsense sg-1100. Upon reverting to 18.06.05 (which process was very smooth), problem has gone away.
Sure, it makes sense for now to get back to a stable working router. But: 18.06 will get out of security patch maintenance in the future and then you may want to upgrade to 19.07, sooner or later.
If you have stability problems specifically with ath10k**-ct**, then you could switch to traditional ath10k (no -ct) to see, if that helps.
Maybe also a bug report what the stability problem symptoms are could be of help so that 19.07 problems could get fixed.
