The OpenWrt community is proud to announce the newest stable release of the OpenWrt 22.03 stable version series. It fixes security issues, improves device support, and brings a few bug fixes.
Download firmware images using the OpenWrt Firmware Selector:
CVE-2022-46393: mbedtls: Fix potential heap buffer overread and overwrite
CVE-2022-46392: mbedtls: An adversary with access to precise enough information about memory accesses can recover an RSA private key
CVE 2022-42905: wolfssl: In the case that the WOLFSSL_CALLBACKS macro is set when building wolfSSL, there is a potential heap over read of 5 bytes when handling TLS 1.3 client connections.
Device support
Support for the following devices was added:
Ruckus ZoneFlex 7372
Ruckus ZoneFlex 7321
ZTE MF289F
TrendNet TEW-673GRU
Linksys EA4500 v3
Wavlink WS-WN572HP3 4G
Fix reboot loop by using LZMA loader. This affects the following devices:
NETGEAR EX6150
HiWiFi HC5962
ASUS RT-N56U B1
Belkin F9K1109v1
D-Link DIR-645
D-Link DIR-860L B1
NETIS WF2881
ZyXEL WAP6805
Fix WAN mac address assignment. This affects the following devices:
UniElec U7621-01
UniElec U7621-06
TP-Link AR7241
TP-Link TL-WR740N
TP-Link TL-WR741ND v4
Teltonika RUT230
Luma Home WRTQ-329ACN
mvebu: Disable devices using broken mv88e6176 switch. This affects the following devices (See mvebubroken_mv88e6176_switch, and #11077):
CZ.NIC Turris Omnia
Linksys WRT1200AC
Linksys WRT1900ACS
Linksys WRT1900AC v1
Linksys WRT1900AC v2
Linksys WRT3200ACM
Linksys WRT32X
Linksys WRT3200ACM
SolidRun ClearFog Pro
lantiq/xrx200: Enable interrupts on second VPE
layerscape: Fix SPI-NOR issues with vendor patches
RouterBoard 912UAG: Fix reference clock
TP-Link RE200 v3/v4: Fix LED configuration
GL.iNet GL-MT1300: Fix flash access by reducing SPI clock
Youku YK-L2 and YK-L1: Allow installing initramfs-kernel.bin over vendor web UI
D-Link DIR-825 B1: Add factory image recipe
D-Link DIR-825-B1: Expand rootfs
D-Link DGS-1210-10P: Add support for extra buttons and LEDs
Asus RT-AC88U: Include Broadcom 4366b1 firmware by default
AVM FRITZ!Box 7430: Include USB driver by default
HAOYU Electronics MarsBoard A10: Include sound driver by default
Do we have details on this? Looking at the MR8300 page (https://openwrt.org/toh/linksys/mr8300), it doesn't say specifically how to do this. Perhaps it's just uploading the factory firmware image to sysupgrade?
Regarding "mvebu: Disable devices using broken mv88e6176 switch. This affects the following devices", what issue is occuring? I have an WRT1900ACS running 22.03.2. I haven't noticed anything and it appears to be functioning correctly. As it stands I can't upgrade for the security issues.
Looking into the bug, it seems that in some cases the switch behaves more like a hub (sending packets to all ports regardless of where they are supposed to go).
I have not investigated very much, but I don't think that every use case is affected. Say, I have not personally observed the issue in my setup after spending a few minutes trying to confirm it.
The image for my device (wrt1200ac) isn't built by default anymore, but it still builds find using the imagebuilder. I was already building custom images for my own use, so I'll just keep doing that.
Only oddity seen so far coming from 21.02.5 (WNDR3800) is repeated:
"daemon.info vnstatd[4317]: Error: Database load failed even when using backup (Invalid argument). Aborting"
Which of course meant that Vnstat didn't work, even after restarting it. So I had to delete the database for whatever reason. Not something that I've seen happen before and am not sure if it's expected coming from 21.02 given the changes.
Xiaomi Redmi AC2100.
upnp function stops from work starting from 22.03.rc6. in rc5 it was fine.
in 22.03.3 it is the same. Applications complain no upnp support, and when enable extra log,
"xxx is not a IGD pinhole" is shown. Something like this:
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: level=0 type=8
daemon.debug miniupnpd[24166]: ifindex = 10 192.168.57.99
daemon.info miniupnpd[24166]: Received UDP Packet (IPv6)
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: level=0 type=8
daemon.debug miniupnpd[24166]: ifindex = 10 192.168.57.99
daemon.info miniupnpd[24166]: Received UDP Packet (IPv6)
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: level=0 type=8
daemon.debug miniupnpd[24166]: ifindex = 10 192.168.57.99
daemon.info miniupnpd[24166]: Received UDP Packet (IPv6)
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
daemon.debug miniupnpd[24166]: rule with label 'a9301fd0' is not a IGD pinhole
Can anyone suggest recommended action for users of the above mvebu devices such as myself. It seems this pretty serious issue affects previous stable builds as well. It would be good to get some sort of official announcement on this with recommended actions given the popularity of the device and severity of the issue.
--
[0] or working on finding- and backporting the changes that fixed kernel v5.15 to v5.10, so the next openwrt-23.03 release after those (potential) backports got merged can be fixed
I wonder what that means ...
Does 'sending packets to all ports' aka acting like a hub include the WAN port?
Is there any recommendation? Buy a new router? Will there be a fix in future or is the device broken (I haven't seen any problems so far)?
Hello. The build for the x86_64 target ends with various errors. I had to exclude (kmod-button-hotplug, kmod-ath10k, kmod-mac80211, kmod-cfg80211, flashrom, pciutils). Device PC Engines APU2.
Kernel 5.15 does not show this behavior, so the issue will likely 'fix itself' once OpenWrt switches to a new kernel. TurrisOS did exactly that and switched to 5.15.x evon for its OpenWrt21 based TOS 6 version.
Howebrr unless someone finds what fixed the isdue between kernel 5.10 and 5.15 and backports these changes if possible it is likely that OpenWrt 22 will not support mvebu.
I have a feeling disabling mvebu was partially intended to increase the motivation to get this fixed properly, but have my doubts whether it will work out.
For what it is worth, I run my mvebu turris omnia under turrisOS as I bought it in big parts for the automatic update feature (I happen to trust team turris). So I am unlikely to help in fixing OpenWrt22, since again TOS does not show the issue.
I'm still unsure about the implications?
Is this making mvebu unusable as packtes also go out on wan? Should we stopusing mvebu devices (I have a WRT3200ACM) until this is fixed?
As it seems this is not always happening: is there some info how to detect if this hub bevaviour occures? Mayby some log statements?
Really think there ought to be an official announcement on this with an explanation of the implications and suggested actions rather than burying the fact these devices have been disabled in a changelog. Many will not realise that this is an issue unless they read all the way through the changelog and even if they do there is no context given around the situation. Fairly disappointed in the way this has been handled...