OpenWrt 19.07.0 second release candidate

Highlights in OpenWrt 19.07.0-rc2

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.

Highlights of this release candidate since the previous OpenWrt 19.07.0-rc1 release candidate are:

  • 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/ 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.


25+ hours, so far, so good.

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?

edit: device = wrt3200acm / wrt32x

1 Like

I have the same problem of @dynasticorpheus

This is a screnshot where i ping the stadia controller, connected to 5ghz wifi, from the router itself.

In red you can see ping spikes when i move pads on the controller.

No issues on OpenWrt 19.07.0-rc1 r10649-c4fdb377a2

1 Like

Upgraded TP-Link WDR 4300 from RC1 to RC2. All looking fine atm.


which device is this?

wrt3200acm / wrt32x

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)

When 5ghz radio disabled there is no problem.

2.4 ghz works flawlessly.

1 Like


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.

I have version 1 of Archer C60 with ath79 and I installed ath10k and not ath10k-ct because it became unstable.

If i want to try the same, i need just to remove "*-ct" and install no "-ct" via opkg and restart router, or there are some fancy settings to do?

I also did that and after restarting it does not turn on the radio. So I had to create my firmware image with ImageBuilder.

I manually remove the -ct driver and firmware (luci-system-software)

  • kmod-ath10k-ct
  • ath10k-firmware-qca9xxx-ct

and then manually install classic drivers

  • kmod-ath10k
  • ath10k-firmware-qca9xxx

Mostly followed by a restart.

I find the classic driver to be more stable than the -ct ones.

1 Like

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.


Did you try switching from the new default ath10k-ct back to traditional ath10k?

Hmmm... not sure about that. What I did was to reflash the rc2 firmware with the sysupgrade 18.06.05 version for the c2600. Does that make sense?

It was my aggressive ublock rules, sorry for the noise!

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.