OpenWrt 19.07.0 first stable release


sorry for the noobish question but what is with the new "openwrt-19.07.0-ath79-generic-tplink_tl-wr1043nd-v2- initramfs-kernel .bin" file ? what is it for?

An initramfs image can be RAM-booted over the network (tftp) for debugging purposes, unless you know what you're doing (and have a serial console attached to the opened device) you can ignore these images (trying to flash these would be fatal and might brick the device beyond repair).


I've tried with config files from the R8000, and also tried with luci-app-unbound. I don't have dropbear or dnsmasq installed. No dhcp, no pppoe - the WDR3600 is normally just an Access Point.

The latest logs:

Sat Jan 11 00:07:48 2020 user.notice unbound: default protocol configuration
Sat Jan 11 00:07:48 2020 user.notice unbound: default memory configuration
Sat Jan 11 00:07:48 2020 user.notice unbound: default recursion configuration
Sat Jan 11 00:08:13 2020 procd: Instance unbound::unbound s in a crash loop 6 crashes, 0 seconds since last crash

After changing parameters in luci-app-unbound to reflect the working config on R8000, then there's only one line in the log after starting unbound:

Sat Jan 11 00:24:17 2020 procd: Instance unbound::unbound s in a crash loop 6 crashes, 0 seconds since last crash

Adjusting "Memory Resource" doesn't affect anything - tried all values.

Device memory:

              total        used        free      shared  buff/cache   available
Mem:         124528       24884       81788        1408       17856       68796
Swap:             0           0           0


I was expecting this last support for 4/32MB (tiny) devices as stated in Hamburg decision. Sadly, no more. Only unusable initramfs builds.

Last support for tiny devices not real???

Anyway, congratulation for this great job.

Sorry to ask, i have a Netgear WNDR3700v4, with a very old openwrt version (Firmware Version OpenWrt Chaos Calmer r45592 / LuCI Master):

Can i upgrade the device with newest version 19.07.0 or should i use 18.06.05 (which is named on the Device page: Or shoud i use 18.06.06 which is the latest 18.06. version....

Think the device page is not updated permanently, which i understand because of the high number of supportet hardware, but this confuses me....

THX in advance!

You can sysupgrade directly to 19.07.0, without any intermediary steps. But coming from (especially-) before 17.01.x you shouldn't try to keep (or worse, try to restore-) your old device configuration over the upgrade (the same when switching between ar71xx and ath79).

1 Like

THanks for your answer, but which release should i take to upgrade directly from Luci? I am very uncertain about the right bin, or is it the tar file? Can someone send me the exact link to upgrade from this very old version to 19.07.0 via Luci?
Thanks in advance!

The correct sysupgrade image for wndr3700v4 should be here:

Download and use the "sysupgrade" image. ("Factory" is meant for installing from OEM firmware)


Sorry again for my silly question, but which file is it exactly, and thank you very much for your Help!

Is it the ...squashfs-sysupgrade.tar

Well, there is exactly one file in that directory that says "wndr3700v4" and "sysupgrade".

1 Like

Thanks, i was very uncertain.... :thinking:

Upgraded TP-Link Archer C7 V2 form 18.06.1, and BT Homehub 5 Type A from 18.06.4. All looking good, including DSL and WDS.

Javascript for GUI looks good news and makes things better for developing packages GUI.

Great job. Many thanks.

1 Like

Thanks to all the developers and package maintainers for this release!



I uninstalled unbound-daemon, then installed unbound-daemon-heavy.
Now unbound works on the WDR3600.

When using unbound-daemon, I saw the following:

unbound -c /etc/unbound/unbound.conf
  Error relocating /usr/sbin/unbound: ub_thr_fork_create: symbol not found
  Error relocating /usr/sbin/unbound: ub_thr_fork_wait: symbol not found

After installing unbound-daemon-heavy:

unbound -c /etc/unbound/unbound.conf
  [1578740005] unbound[12312:0] debug: creating udp4 socket 53
  [1578740005] unbound[12312:0] debug: creating tcp4 socket 53
  [1578740005] unbound[12312:0] debug: creating udp6 socket :: 53
  [1578740005] unbound[12312:0] debug: creating tcp6 socket :: 53
  [1578740005] unbound[12312:0] debug: switching log to syslog


1 Like

That's what the RC's are for. You try them, you report stuff. Now you're looking at a stable release that has no image for your device, which could have been fixed pre-release.

What specific device are you talking about? Devices that don't build because of space issues have been disabled, yours might be part of it. There are a few tricks to get it to build if that's the case for your hardware but you'd have to do it yourself.

Hi Borromini, thanks for your reply.

I had reported it

I can live with release 18.06.06

That's too bad (it took me a while to find it's an TL-WR841N v7 though, just like you're not mentioning it in this thread).

If you don't need e.g. IPv6 or PPP you can strip both (or either) and try the image builder to get an image going.

Can anyone confirm this bug I am running into? Seems pretty major to me. After a fresh install with fresh settings, I changed the WAN interface's protocol to PPPoE. It succesfully connects and creates a virtual WAN_6 interface on top of the PPPoE interface for IPv6 connectivity. So far so good. IPv4 and IPv6 access to the internet is fine.

However, the virtual WAN_6 interface is NOT assigned to a firewall zone. I cannot edit the interface to add it to a firewall zone, nor can I add the virtual interface to the WAN zone through the firewall's settings. This means that this zone will use the general settings from the firewall. I have verified this behavior by running an online IPv6 port scanner. Results only differ by changing the general settings. Changing the WAN firewall zone settings has no effect on the results.

This brings about many issues: Opening ports through firewall zones for IPv6 addresses will not work, but more importantly, IPv6 will be using different and potentially more lenient firewall rules than what is specified in the WAN zone. That can potentially be a big vulnerability.

Any comments? Am I doing anything wrong? Did I indeed run into a bug?

1 Like

Is there any good reason to switch (other than future-proof) to do so?

PM me the output of /tmp/run/fw3.state