OpenWrt 19.07.0 first stable release

[hemi]

Thanks, i was very uncertain....

[Hegabo]

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.

[supersebbo]

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

[geofb]

Robert,

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 0.0.0.0 53
  [1578740005] unbound[12312:0] debug: creating tcp4 socket 0.0.0.0 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

regards,
Geof

[Borromini]

@zen1932

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???

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.

[zen1932]

Hi Borromini, thanks for your reply.

I had reported it https://forum.openwrt.org/t/can-not-find-squashfs-build-in-19-07-tiny-branch/48262

I can live with release 18.06.06

[Borromini]

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.

[Mushoz]

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?

[Sgt_Greco]

@hauke

This release 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.

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

[jow]

@Mushoz

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

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

[vk496]

Cool. Thnks all contributors for this incredible work!

[Mushoz]

Anyone else running into issues with hardware flow offloading on a mt7621 device? I was getting the full 500/500 mbit from my WAN connection on dslreports with minimal router load during tests on 18.06.x series. I am now seeing 500/400 bottlenecked speeds, with multiple cores hitting 100% load.

[lede_dude]

Has anyone been able to update their Xiaomi Mi Router 3G (mir3g) with the latest OpenWrt 19.07.0? There is no .tar file in the releases folder and the router will not accept the .bin file.

Another question related to this is, if you have updated your Xiaomi Mi Router 3G (mir3g) to the latest OpenWrt 19.07.0, do you have ipv6 working?

There is a mt7621 related bug FS#1763 in the 18.06 and ipv6 does not work with this router, and I can't update my router to test, for above mentioned reason.

[ne20002]

I'm missing the 'Force connection tracking' checkbox in the firewall's dialogs. It now has a tab for conntrack settings, but it does not seem to have the same effect. It does not write an option conntrack to the firewall file.

[Sunspark]

@hnyman

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

Minor disagreement. Factory can be used anytime (including from OEM firmware). My personal best practice is, for major version number changes I use the factory file and for minor version updates I use sysupgrade. I would also use factory instead of sysupgrade if I was changing from AR71 (which is what I have on 18.06) to ATH79.

[hnyman]

@Sunspark

Factory can be used anytime

Wrong for most routers. Totally depends on the router...
For most routers the factory image contains a header that makes it compatible with the OEM flashing routine: like "Factory = header + sysupgrade image + possibly padding". But flashing that factory image via sysupgrade would brick the router. (no idea about that 3700v4 specifically, maybe that is an exception, if you are sure about that)

@Sunspark

My personal best practice is, for major version number changes I use the factory file and for minor version updates I use sysupgrade.

Makes no sense for most routers. The sysupgrade and factory have identical functional contents except that packaging (for OEM flashing routine).

[Sunspark]

@hnyman

Wrong for most routers. Totally depends on the router...
For most routers the factory image contains a header that makes it compatible with the OEM flashing routine: like "Factory = header + sysupgrade image + possibly padding". But flashing that factory image via sysupgrade would brick the router. (no idea about that 3700v4 specifically, maybe that is an exception, if you are sure about that)

Interesting. I had no idea that other routers could have issues. I can attest that the Archer C7 v2 has never had a problem flashing the factory image from within luci which I have done multiple times in the 17.x series and once to the 18.x series. Thanks for making me aware it could be an issue on other devices.

Factory on the Archer is probably still a better recommendation for people switching from AR71xxx to ATH79, because most people (in my opinion) will be using the luci web interface and won't see it documented anywhere that they need to drop to a commandline and sysupgrade -F etc.

[austinbutler]

Thanks, that'll do. Out of curiosity does that mean LUCI can't be used even when unchecking "keep settings" since it has no "force" equivalent?

[Borromini]

Using sysupgrade over SSH gives you more flexibility. I never upgrade through LuCI myself, frankly, but that's mostly just force of habit.

@Sunspark Please stop recommending bad practices. Like @hnyman said, there's a valid reason why OpenWrt differentiates between factory and sysupgrade images. If you want to persevere, that's fine, just don't drag other people along.

[Forceflow]

Is it normal that my router got a slightly modified MAC address after upgrading? Shouldn't be a biggy, but it prompts all the windows machines on my network to see it as a "new network", reverting their settings to "public network".