OpenWrt 22.03.0-rc5 fifth release candidate

This still links to 22.03 rc4: https://downloads.openwrt.org/

2 Likes

D-Link dir-1960 (mt7621): 22.03 rc5 so far is actually a rather boring :wink: release: no flaws, sysupgrade + config taken over from 21 just works, no problems.

I flashed my router collection from 22.03.0-rc4 to rc5 with one from the Image Builder. All are running as dumb APs w/ VLANs and 4 WiFi SSIDs per radio; some use a mesh w/ GRE tunnels to other APs.

Devices I've tried:

  • tplink_archer-c7: Up 4 days
  • glinet_gl-ar150: Up 6 days
  • ubnt_unifiac-lite: Up 7 days
  • ubnt_unifi: Up 5 days

I do note that swconfig is gone from the c7 whereas it was there in rc4. I'm not quite sure how or why it's even working since IIUC the release notes say There is no migration path for targets that switched from swconfig to DSA so IDK why it allowed me to upgrade or even still works, but works correctly it does since it is the router that bridges my wired network to the mesh, along with ~8 VLANs. I diffed my configs and nothing changed in them, so ¯\_(ツ)_/¯ .

1 Like

Does anyone know if the rest of ath79 will be transitioned to DSA, and if not, what the problem might be? So far, it's been just the one device in the ath79 family that has (not sure why that one), and that was back in 21.02. To my knowledge, 22.03 will have no changes for ath79 and DSA.

Updated to correct important typo

I think the channel analysis only works on radios that are in client mode. At least that's how it behaves in 21.02

R6220 -radio device 2.4GHz not visible on pcie for 22.03-rcX.
I'm testing 22.03 since very first rc, on two R6220 routers (Cezary builds, eko.one.pl). Both working well on 19.07 builds, no issues with radio devices. One of them has absolutely no issues with 22.03, as well. BUT for next one, it is unlikely that 2.4G radio device is discovered on pcie during start procedure. Sometimes I have to restart it dozen, dozen of times. Seems like the issue is already described:
fix: add pci reset_gpios for R6220 by pierrepinon · Pull Request #10125 · openwrt/openwrt (github.com)
R6220 ” Could not find PHY for device ‘radio0’” mt76x2 .. issue continues - Installing and Using OpenWrt - OpenWrt Forum

On all devices that I use, no radio is in client mode: they are set in AP mode. I can perform a channel analysis, except for this case.

Installed in Archer C6 V2 EU, installed qos sqm package and as an amateur I report that it works OK :wink:

Did an update from 21.02 to 22.03 rc5 on a WRT3200ACM. It's been a week and it's been stable so far. I didn't precisely measure it but there may have been extremely small improvements in WiFi latency (on the order of 1-2 ms). I don't have a super fancy setup, just SQM and dns over https. Did not attempt to see if DFS is working better on 5ghz.

2 Likes

Updated a few of my own devices last week. No issues to report.

  1. Dumb AP Cudy X6 - has multiple wifi client devices connected (iOS, Android, Windows and Linux Laptop, Pi3, IoT/esp8266, etc.) on both bands.
  2. Test device Netgear WAC124
  3. Test device D-Link DAP-2695 A2
  4. Test device Netgear GS108Tv3

A minor issue exists in the firmware selector, it doesn't allow custom images to be build.

The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

1 Like

I guess you meant from ar71xx to ath79. I believe that basically depends on somebody volunteering to do any such work.

@sumo Ah, sorry, I corrected the typo now. The question was about the transition to DSA for that family.

The answer stays the same: It basically depends on somebody volunteering to do any such work.

Did you try WPA3? Does it work?
My router is WRT1900ACS. WPA3 works for 21.02 but not for 22.03 RC1-5.

No idea what has been changed.

The rc5 x86_64 image builder runs into this issue building with the default profile options:

$ make info
Current Target: "x86/64"
Current Architecture: "x86_64"
Current Revision: "r19523-bfd070e7fa"
Default Packages: base-files ca-bundle dropbear fstools libc libgcc libustream-wolfssl logd mtd netifd opkg uci uclient-fetch urandom-seed urngd busybox procd procd-ujail procd-seccomp partx-utils mkf2fs e2fsprogs kmod-button-hotplug dnsmasq firewall4 nftables kmod-nft-offload odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe
Available Profiles:

generic:
    Generic x86/64
    Packages: kmod-amazon-ena kmod-amd-xgbe kmod-bnx2 kmod-e1000e kmod-e1000 kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-r8169 kmod-tg3
    hasImageMetadata: 0

$ make image PROFILE="generic"
Unknown package 'libustream-wolfssl'.
...
 * pkg_hash_check_unresolved: cannot find dependency libwolfssl5.4.0.ee39414e for libustream-wolfssl20201210
 * pkg_hash_fetch_best_installation_candidate: Packages for libustream-wolfssl found, but incompatible with the architectures configured
 * opkg_install_cmd: Cannot install package libustream-wolfssl.
make[2]: *** [Makefile:169: package_install] Error 255

Builds OK:

$ make image PROFILE="generic" PACKAGES="-libustream-wolfssl"

Reported in:

I also have this with mt7621 and ipq40xx.

Trying out the image builder for 22.03.0-rc5 on a TI BeagleBone Black. I'm also seeing the same issue with libwolfssl 5.4 being unavailable. (My selection of packages means that I really do want/need tls support; so for me deselecting the package which pulled in wolfssl, and enabling an openssl alternative instead gets me past this problem.)

I noticed that a bunch of luci packages, which I'd expected would be included by default, were not selected automatically, and so I needed to manually add them to the build as well. Is this expected?

There is a PR in progress to do this for ath79 (PR 4622), but performance issues preclude the transition to date. Same with ipq806x (PR 4036) targets. Moving ipq40xx (PR4721) to DSA looks a bit further along, but not far enough along for 22.03.

1 Like

WPA3 is unsupported by mwlwifi last I checked so let us know how you got it working. I've long used WPA2 for my WRT32X for that reason.

1 Like

Yes, I've used WPA3/WPA2 mixed in the past with some specific device success for WRT1900ACSv2, but ultimately went back to WPA2 for more consistent 5Ghz performance.