No idea about MediaTek MT7621ST/MT7603EN combination (Netgear R6220) routers
but
Still 5 GHz WiFi Address Not Found errors with MediaTek MT7621AT/MT7615N combination routers.
e.g. D-Link DIR-878, DIR-882, DIR-2640 ...
EDIT: For sake of accuracy, forgot to add AT for MT7621AT to original post.
Thanks for an info. I'm still using 19.07.10 on my MIR3P.
Works great for me:
Linksys WRT3200ACM, but did NOT test Wi-Fi.
Linksys MR8300 using Wi-Fi. The only odd thing on this device is the LUCI GUI shows Brazilian text even though I installed the -en package. Instead of Starus-Overview in the menu, it shows “Visiao Geral”. But the same menu item on the WRT3200ACM is correct.
Tested it on
The WD03 is dead slow, but it's a 8 MB Flash / 32 MB Ram device, so... It was just for fun. On all the other devices I haven't found any Issues yet.
updated RC4 on Redmi 2100,
Pros:
Cons:
May this infobit be in intrest of someone. rc4 does not fix the problem running dnsmasq in ujail in an unprivileged lxc container.
Sat Jun 18 06:17:47 2022 daemon.crit dnsmasq[1]: failed to seed the random number generator: No such file or directory
Sat Jun 18 06:17:47 2022 daemon.crit dnsmasq[1]: FAILED to start up
Sat Jun 18 06:17:52 2022 daemon.crit dnsmasq[1]: failed to seed the random number generator: No such file or directory
...
Sat Jun 18 06:18:02 2022 daemon.info procd: Instance dnsmasq::cfg01411c s in a crash loop 6 crashes, 0 seconds since last crash
In rc1 release thread at the forum had few messages about the problem with different log messages and a bug report/patch already made. On the container system ntp service in ujail works fine. urandom and random devices are available in the container environment itself. dnsmasq process works fine without ujail (started with /etc/init.d/dnsmasq trace).
I briefly tried to understand how to get inside ujail setup in OpenWrt 22.03-rc1, if the problem is about a missing urandom or random device in ujail, but had no success. My understanding, ujail makes a sort of nested container inside lxc container. To debug ujail setup seems to require more engagement than I could provide now. If my memory serves me right, with rc1 I tested the same setup both in a privileged and unprivileged lxc container. Privileged vs. unprivileged system container setup did not affect to the problem.
References:
https://forum.openwrt.org/t/openwrt-22-03-0-rc1-first-release-candidate/126045/25
https://forum.openwrt.org/t/openwrt-22-03-0-rc1-first-release-candidate/126045/29
https://forum.openwrt.org/t/openwrt-22-03-0-rc1-first-release-candidate/126045/196
Heads-up on the FriendlyARM NanoPi R1. It is not booting in 22.03.01-rc4, 22.03.01-rc1 or snapshot
All is well on 21.02.3 (r16554-1d4dea6d4f).
Tested it on FriendlyARM NanoPi R4S. Boots smoothly, briefly tested it for ~1 hour and did not notice any device specific problems.
Currently migrating a Fritz!Box 7412 / (lantiq xrx200) from 21.02 to 22.03.
This device was switched from swconfig to DSA between these releases.
Boots up and syncs VDSL successfully, but then the PPPoE WAN authentication repeatedly fails with this log message:
pppd[3505]: Remote message: 0034 PSSTG001 0002525447 profile not sufficient
I am not sure if the switch from swconfig to DSA is relevant here, and whether I missed something in the network configuration. Searching for this message does not yield much.
Log excerpt:
Thu Jun 16 22:01:31 2022 kern.warn kernel: [ 235.777108] enter showtime
Thu Jun 16 22:01:31 2022 kern.info kernel: [ 235.778664] IPv6: ADDRCONF(NETDEV_CHANGE): dsl0: link becomes ready
Thu Jun 16 22:01:31 2022 daemon.notice netifd: Network device 'dsl0' link is up
Thu Jun 16 22:01:31 2022 kern.info kernel: [ 235.787839] IPv6: ADDRCONF(NETDEV_CHANGE): dsl0.7: link becomes ready
Thu Jun 16 22:01:31 2022 daemon.notice netifd: VLAN 'dsl0.7' link is up
Thu Jun 16 22:01:31 2022 daemon.notice netifd: Interface 'wan' has link connectivity
Thu Jun 16 22:01:31 2022 daemon.notice netifd: Interface 'wan' is setting up now
Thu Jun 16 22:01:31 2022 kern.warn kernel: [ 235.803397] enter showtime
Thu Jun 16 22:01:31 2022 daemon.err insmod: module is already loaded - slhc
Thu Jun 16 22:01:31 2022 daemon.err insmod: module is already loaded - ppp_generic
Thu Jun 16 22:01:31 2022 daemon.err insmod: module is already loaded - pppox
Thu Jun 16 22:01:31 2022 daemon.err insmod: module is already loaded - pppoe
Thu Jun 16 22:01:32 2022 daemon.info pppd[3505]: Plugin pppoe.so loaded.
Thu Jun 16 22:01:32 2022 daemon.info pppd[3505]: PPPoE plugin from pppd 2.4.9
Thu Jun 16 22:01:32 2022 daemon.notice pppd[3505]: pppd 2.4.9 started by root, uid 0
Thu Jun 16 22:01:37 2022 daemon.info pppd[3505]: PPP session is 21111
Thu Jun 16 22:01:37 2022 daemon.warn pppd[3505]: Connected to 40:XX:XX:XX:XX:d2 via interface dsl0.7
Thu Jun 16 22:01:37 2022 kern.info kernel: [ 241.839236] pppoe-wan: renamed from ppp0
Thu Jun 16 22:01:37 2022 daemon.info pppd[3505]: Renamed interface ppp0 to pppoe-wan
Thu Jun 16 22:01:37 2022 daemon.info pppd[3505]: Using interface pppoe-wan
Thu Jun 16 22:01:37 2022 daemon.notice pppd[3505]: Connect: pppoe-wan <--> dsl0.7
Thu Jun 16 22:01:40 2022 daemon.info pppd[3505]: Remote message: 0034 PSSTG001 0002525447 profile not sufficient
Thu Jun 16 22:01:40 2022 daemon.err pppd[3505]: PAP authentication failed
Thu Jun 16 22:01:40 2022 daemon.notice pppd[3505]: Modem hangup
Thu Jun 16 22:01:40 2022 daemon.notice pppd[3505]: Connection terminated.
Thu Jun 16 22:01:40 2022 daemon.info pppd[3505]: Exit.
Thu Jun 16 22:01:40 2022 daemon.notice netifd: Interface 'wan' is now down
Thu Jun 16 22:01:41 2022 daemon.notice netifd: Interface 'wan' is disabled
Thu Jun 16 22:01:41 2022 daemon.notice netifd: Interface 'wan' is enabled
Thu Jun 16 22:01:41 2022 daemon.notice netifd: Interface 'wan' is setting up now
(...)
Network configuration:
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].ports='lan'
network.@device[0].type='bridge'
network.@device[1]=device
network.@device[1].macaddr='02:XX:XX:XX:XD:16'
network.@device[1].name='lan'
network.@device[2]=device
network.@device[2].macaddr='02:XX:XX:XX:XA:16'
network.@device[2].name='dsl0'
network.lan=interface
network.lan.device='br-lan'
network.lan.ip6assign='60'
network.lan.ipaddr='192.168.199.1'
network.lan.netmask='255.255.255.0'
network.lan.proto='static'
network.loopback=interface
network.loopback.device='lo'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.loopback.proto='static'
network.wan=interface
network.wan.device='dsl0.7'
network.wan.ipv6='auto'
network.wan.keepalive='8 5'
network.wan.password='XXXXXXXXXXXXXXXX'
network.wan.proto='pppoe'
network.wan.username='XXXXXXXXXXXXXXXXXXXXX'
network.wan6=interface
network.wan6.device='@wan'
network.wan6.proto='dhcpv6'
network.atm=atm-bridge
network.atm.encaps='llc'
network.atm.nameprefix='dsl'
network.atm.payload='bridged'
network.atm.vci='32'
network.atm.vpi='1'
network.dsl=dsl
network.dsl.annex='b'
network.dsl.ds_snr_offset='0'
network.dsl.firmware='/usr/lib/firmware/modem/5.9.1.4.0.7/vr9-B-dsl.bin'
network.dsl.line_mode='vdsl'
network.dsl.tone='bv'
network.globals=globals
The network.wan, network.wan6, network.atm and network.dsl sections are the same as on release 21.02.
Interesting... My Network config is a little bit different - and I'm actually using RC4 on my regular internet-7412 without any issues. (well, the disconnection after 24 hours remains, but that's due to the contract I guess, the dsl connection itself stays alive) It's an old Alice contract, now O2, AFAIK the very most connections here in Germany are technically Telekom connections, so it should work. Here's my network config, perhaps it's worth trying out the differences...
network.atm=atm-bridge
network.atm.vpi='1'
network.atm.vci='32'
network.atm.encaps='llc'
network.atm.payload='bridged'
network.atm.nameprefix='dsl'
network.dsl=dsl
network.dsl.annex='b'
network.dsl.ds_snr_offset='0'
network.@device[1]=device
network.@device[1].name='dsl0'
network.@device[1].macaddr='xx:xx:xx:xx:xx:xx'
network.wan=interface
network.wan.proto='pppoe'
network.wan.ipv6='1'
network.wan.device='dsl0.7'
network.wan.username='<phone-number>@s93.bbi-o2.de'
network.wan.password='<password>'
network.wan6=interface
network.wan6.device='@wan'
network.wan6.proto='dhcpv6'
network.@device[2]=device
network.@device[2].type='8021q'
network.@device[2].ifname='dsl0'
network.@device[2].vid='7'
network.@device[2].name='dsl0.7'
IPv6 doesn't function here no matter what kind of router I use, for me it seems the old Alice customers just won't get it from the ISP, dunno if O2 at all provides IPv6, heared rumors that not.
The lines network.dsl.firmware=..., network.dsl.line_mode='vdsl' and network.dsl.tone='bv' are missing in my config, I've set line mode and tone to 'auto' in luCI and copied my vr9-B-dsl.bin directly to /lib/firmware/lantiq-vrx200-b.bin, but the last one shouldn't matter. I've extracted my firmware blobs myself from the 6.86-firmware of the 7412, tried it with an extract of the file from the 7430-7.27 firmware and from the 7490-7.29 firmware, they all claim to have the same serial, so I switched back to the blob of the 7412, but can't remember any issues with the other ones. Perhaps also worth a try.
Works good on Beeline SmartBox Giga (pending). Mt7613 WiFi performance is good. Dumb AP + samba + dlna + mesh.
APU2D4 checking in. Working well with MT7915e for wifi 6 functionality.
I do see some odd language/translation artifacts. I am set to English but in at least two places I am seeing what I believe to be spanish.
Visão Geral is the top menu item under status.
Also the config menu in Netlink.
Similar case with my TP-Link EAP615 (MT7621 ramips). Client is a MT7921 (RZ608) with Fedora Silverblue 36 laptop. Wifi works fine for a dozen or so minutes, and then it it doesn't transfer data, then it disconnects. After about a minute, it all comes back again. This can happen again after a few dozen more minutes.
Sun Jun 19 11:44:33 2022 daemon.info hostapd: wlan1: STA [client mac address here] IEEE 802.11: associated (aid 1) Sun Jun 19 11:44:33 2022 daemon.info hostapd: wlan1: STA [client mac address here] WPA: pairwise key handshake completed (RSN)
Sun Jun 19 11:44:33 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED [client mac address here]
Sun Jun 19 11:44:34 2022 user.info : luci: accepted login on / for root from 192.168.1.106
Sun Jun 19 11:47:08 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED [client mac address here]
Sun Jun 19 11:47:12 2022 daemon.info hostapd: wlan1: STA [client mac address here] IEEE 802.11: authenticated
Sun Jun 19 11:47:12 2022 daemon.info hostapd: wlan1: STA [client mac address here] IEEE 802.11: associated (aid 1)
Sun Jun 19 11:47:12 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED [client mac address here]
Sun Jun 19 11:47:12 2022 daemon.info hostapd: wlan1: STA [client mac address here] WPA: pairwise key handshake completed (RSN)
Sun Jun 19 11:47:12 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED [client mac address here]
Sun Jun 19 11:47:14 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED [client mac address here]
I'll try to get a tighter log next time. I'm on the lowest 5GHz channel, 80MHz (only 5GHz, as 2.4GHz is extremely crowded here).
This did not happen with rc1. Did a sysupgrade to rc4, from rc1. No configuration change was made during or after the upgrade.
Device is configured as an AP-only. WPA3 only.
3x Xiaomi AX3200
all updated correctly
everything has been working fine for a few days (same as with -rc1).
It is there...
OpenWrt 22.03.0-rc4 works fine on both my routers:
Linksys E8450 (UBI)
Netgear WNDR3700 v4
Thanks to all the folks putting in the time to make this a great alternative to oem firmware. It is much appreciated.
One comment. Since this is going to be production firmware, it would be great to document the "fw_setenv bootcmd run boot_ubi" command a lot better. Lots of people aren't going to be sitting next to their router 24/7 and are going to be annoyed if they have to drive home or to wherever the firmware is installed in order to reboot it. I understand the need for good backtraces but perhaps this can be done in a way that doesn't prevent normal unattended operation.
I might give it a try on my WRT3200ACM. Can't be worse 
Bugreport:
To try it out i installed https://downloads.openwrt.org/releases/22.03.0-rc4/targets/lantiq/xrx200/openwrt-22.03.0-rc4-lantiq-xrx200-tplink_tdw8970-squashfs-sysupgrade.bin to a router running an older openwrt image on a vectoring line.
After installation i of course have to add the VDSL-vectoring firmware because the preinstalled in the image does not support vectoring. I scp the latest vr9-B-dsl.bin extracted from a FRITZ.Box_7490-07.29.image and that broke the system. The storage of the device was after copy of file full. I was not able to save any settings any more. Vectoring still not working. I checked if the file was fine. No, only about 400KiB storage was free after installation. But the vectoring firmware is 887,6KiB big and scp a oversize file causes the system to not be able to save the settings.
I think this should not be a situation the regular users should get into.
The only way out of this is to compile a openwrt image from source and not include the non-vectoring firmware but include instead the vectoring firmware into a image to be able to use the new vectoring functionality.
While certainly a problem for you, this isn't a 'bug' of this release. The -rc works just fine as is and has enough space to hold configuration files, just not enough to hold a ~900 KB additional firmware blob (it would work just fine with the default non-vectoring blob on a non-vectoring line) - which is not surprising for a device with 8 MB total flash size.
You can probably squeeze your vectoring blob in using imagebuilder, but at some point it will outgrow its 8 MB flash - the only 'solution' to fix this would be stopping to build images for this device and consider no longer supportable.