The OpenWrt community is proud to announce the seventh service release of OpenWrt 19.07. It fixes security issues, improves device support, and brings a few bug fixes.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 19.07.7, r11306-c4a6851c72
-----------------------------------------------------
Main changes from OpenWrt 19.07.6
Only the main changes are listed below. See changelog-19.07.7 for the full changelog.
Note: security fixes for most packages can also be applied by upgrading only the affected packages on running devices, without the need for a full firmware upgrade. This can be done with opkg update; opkg upgrade the_package_name or through the LuCI web interface.
Nevertheless, we encourage all users to upgrade their devices to OpenWrt 19.07.7 or later versions whenever possible.
Major bug fixes
Fix dnsmasq error messages such as failed to send packet: Network unreachable or failed to send packet: Address family not supported by protocol that could be filling up logs. This was a regression caused by the dnsmasq update in 19.07.6.
Fix opkg so that it purges obsolete packages from its local cache. This fixes a long-standing issue in the ImageBuilder where a manual cleanup was needed before rebuilding: FS#2690
Device support
Improve stability of mediatek Ethernet switch (affects many mt7621 devices): FS#2628
Fix Wi-Fi band detection on some Broadcom-based devices
Fix poor 2.4 GHz Wi-Fi performance on TP-Link Archer C50 v4 due to a missing EEPROM chip ID: FS#2781
Make initramfs image usable out-of-the-box on Turris Omnia
Use full flash size on Nucom R5010UN v2
Fix support for TP-Link TL-WR810N v1 in ath79: FS#3522
Remove broken factory image for TP-Link Archer C2 v1
Fix unintended failsafe mode during boot on Netgear EX6150: FS#3590
Various fixes and improvements
The ImageBuilder no longer requires compilers (gcc, g++) and libncurses-dev. This was partially implemented in 19.07.6 but one part was missing to make it actually work.
Update to a new major version of ksmbd to fix several bugs. This breaks compatibility with previous versions of OpenWrt (19.07.0 to 19.07.6): it is no longer possible to install a working version of ksmbd-tools on previous versions of OpenWrt. Existing installations will keep working, but ksmbd-tools should not be upgraded with opkg. PR#14647
kmod-fs-ksmbd has a dependency to the not existing package kmod-crypto-arc4. Installing kmod-fs-ksmbd returns this: satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-ksmbd: * kmod-crypto-arc4 * opkg_install_cmd: Cannot install package kmod-fs-ksmbd.
Run this to force the installation: GH#14771 opkg install --force-depends kmod-fs-ksmbd
to force the installation.
Known issues
Transition to ath79: some devices that are supported in ar71xx are not yet supported in ath79: this is a community effort. Helping to port devices to ath79 to make them available in future releases is very welcome.
Device support: images for some device became too big to support a persistent overlay, causing such devices to lose configuration after a reboot. If you experience this problem, please report the affected device in the forum and consider downgrading to OpenWrt 18.06 or using the Image Builder to pack a smaller custom image
Device support: conversely, certain images for devices with small flash (4 MB) are no longer built for the release
An upgrade from OpenWrt 18.06 to OpenWrt 19.07 is supported in many cases, including preserving configuration. A configuration backup is advised nonetheless when upgrading from OpenWrt 18.06.
As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters.
Hi, after upgrading to 19.7.7 from 19.7.6 on GL.iNet GL-B1300 my DNS (that is simply configured on lan interface and active) is now my isp dns. I mean the DNS I setup there is ignored.
Nothing changed, just upgraded configuration.
Any idea about how to enforce that, without installing other components I want to keep it simple and update to latest versions without reconfigure everything..
Thnaks
Backed up config files from 19.07.6 to archive config files. Rebooted to alt-OEM partition using Advanced Reboot package.
Installed 19.07.7 fresh from alt-OEM partition on MR8300 using EA8300 factory release (not sysupgrade), reinstalled needed optional packages "as is" and without further config, Wi-Fi was left disabled and unconfigured.
Restored backup, without "reset to defaults" (as this is a fresh factory install) and voilà ! All works fine, took a few minutes and no headache.
Average load is higher than 19.07.6 (which was drastically reduced from .5), but still way lower than 19.07.5.
RAM use is lower than 19.07.6 (which was drastically increased by 10 to 20 MB from .5), now back to more in line with 19.07.5.
There now seems to be a better balance between average load and RAM use.
Many thanks to Devs, you guys are definitely working very hard fixing issues !
I think you need to define DNS servers for your WAN interface, not your LAN interface.
Undo the settings you changed on your LAN interface, and under Network>Interfaces> in luci, try Editing WAN settings on your Gateway router under the "Advanced Settings" tab and define the DNS servers you want to use (e.g., 1.1.1.2 and 9.9.9.9) under "Use custom DNS servers" and uncheck "Use DNS servers advertised by peer". Same thing for WAN6, except use IPv6 servers of course (e.g., 2606:4700:4700::1112 and 2620:fe::fe).
This works fine for me on 19.07.7 (and has also worked fine on any other version for that matter).
Luci feels way faster. Wifi is slower, but with the mess that is mwlwifi I'm just happy it works at all
That being said, I'm having far less drop-outs of the 5GHz band, so...
It is included in .7 mt76 is the wireless driver, it has nothing to do with it.
The transmit queue timeout can still happen, but crashes should happen less frequently. It's a workaround, not a real fix (the fix will probably never happen).
Not sure why ethtool wouldn't report that, I haven't tested it (I'm not even sure that this NIC/switch can actually be controlled by ethtool).
I upgraded from 19.07.06 to this release on my Linksys WRT1900ACS, keeping the configuration. I then installed the additional packages that I had installed with the prior version and rebooted.
Awesome job with the timely release of security updates.
mt76 is the wireless driver, it has nothing to do with it.