OpenWrt 22.03.0-rc1 first release candidate

Seconded. Using MR8300 without issues with this rc1 release. Stable 2.4GHz and 5GHz, with Apple devices.

1 Like

Updated both Linksys WRT3200ACM and MR8300 without issue to this rc1 release. I am NOT using wifi on WRT3200ACM because of issues with Apple devices (see other threads for details). Wifi works fine for 2.4 and 5 on the MR8300 (ipqxxxx). Using luck for GUI without issues.
Only bummer is BanIP is not updated to support nftables. Oh well, next candidate perhaps...

One of my BT Hub 5As has been frequently rebooting during boot for some time while using various builds of the development branch (I'm not sure, but I think it might have started at some point after the change of kernel).

Sometimes, it gets stuck in a boot loop for some time, unplugging all LAN and the phone cable often seemed to make it more likely for it to complete the boot, as did turning it off for a while. I did suspect a hardware issue like overheating (unfortunately temperature is not recorded in the log during boot anymore), or a PSU issue, but a second BT hub started doing it almost as bad using a recent build.

I put this release candidate on it and also disabled its 5ghz mesh a few days ago, and it seems to boot loop a lot less, but after running for a day or few, I'm now getting packet loss followed by a reboot.

Unfortunately neither router has the serial pins connected.

about software flow offloading:
after Sysupgrade from 21.02 to 22.03.0-rc1 on my C2600, I personally don't believe that it's fully fixed.
sw flow offloading disabled: stable, overall routing and NAT performance seems to be little better than before (max. around 400-450 Mbit/s now, on C2600)
sw flow offloading enabled: instable throughput, download and upload performance went down and up.
felt like it was losing packages from time to time.
have no verified proof, it's only my impression, I haven't digged deeper, first ran some speedtests in comparison

besides that ... I only wanted to answer the question ... 22.03.0-rc1 seems to run very well on my device. no major issues found yet - great!

it looks like kmod-vrf is coming with this release. Does this mean Openwrt will start supporting VRF to isolate zones/interfaces? I am looking for this feature.

Thank you

2 Likes

Installed 22.03.0-rc1 on Asus MAP-AC2200 (aka Lyra). It works, but there is a problem with the LEDs and it is impossible to configure VLANS (at least in Luci)

I've just got the ap, so I cannot compare the performance with former versions.

In 22.03.0-rc1 the driver for the led's fails

root@OpenWrt:/sys/class/leds# dmesg |grep 5523
[    1.969494] lp5523x: probe of 0-0032 failed with error -22

Afther the boot, the ap is left with "random breathing" - a continously change between different colors.
Becase there is no driver, I cannot stop og change the led.

So I tried the stable version, 21.03.3.
In that version the leds are turned off by default - and I have the driver

root@OpenWrt:/sys/class/leds# dmesg |grep 5523
[    1.929880] lp5523x 0-0032: lp5523 Programmable led chip found

In the 21.03.03 I can control the leds with

lrwxrwxrwx    1 root     root             0 May  6 18:49 ath10k-phy0 -> ../../devices/platform/soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/leds/ath10k-phy0
lrwxrwxrwx    1 root     root             0 Jan  1  1970 blue0 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/blue0
lrwxrwxrwx    1 root     root             0 Jan  1  1970 blue1 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/blue1
lrwxrwxrwx    1 root     root             0 Jan  1  1970 blue2 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/blue2
lrwxrwxrwx    1 root     root             0 Jan  1  1970 green0 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/green0
lrwxrwxrwx    1 root     root             0 Jan  1  1970 green1 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/green1
lrwxrwxrwx    1 root     root             0 Jan  1  1970 green2 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/green2
lrwxrwxrwx    1 root     root             0 Jan  1  1970 red0 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/red0
lrwxrwxrwx    1 root     root             0 Jan  1  1970 red1 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/red1
lrwxrwxrwx    1 root     root             0 Jan  1  1970 red2 -> ../../devices/platform/soc/78b7000.i2c/i2c-0/0-0032/leds/red2

Both 22.03.0-rc1 21.03.03 reflects the situation in luci - only in the old version, the different leds are shown.
In both version ath10k-phy is shown but it does not correspond to any visible led on the router.

Furthermore, in Luci the menu "Network\switch" is missing in both versions - so I dont think it is possible to configure VLANs

The lp5523 LED driver was changed between kernel v5.4 and v5.10, the map-ac2200 DTS will need to be modified to match (if you can help with that, great). While this has no functional impact on the device, this 'light show' is a major annoyance (and sadly not fixable with black tape).

1 Like

I can confirm, that 21.0.3 does not have a problem with the led controller.
I have filed a issue on github regarding the problem.

Regarding the switch-problem, I can see, that a solution have been done, but apparently, it has been blocked, because it gave some builderrors for some devices. Hopefully that will be solved.

This is such a fantastic release, i'm using it on my raspberry pi and it feels legitimately better than the last versions!

No bugs so far, i'm not using wireless tho but yeah this one is lit!

thank you for your work.

I have now tried the patch (on master - not 22.03.0-rc1)
mentioned in 9851 - and MAP-AC2200 now boots up with a dimmed blue, and I can control the leds.

1 Like

Great, I can't test it at the moment, as I'm away from my map-ac2200 for the next couple of weeks.

You will have to patch and build openwrt yourself of wait until the patch is accepted and used in the daily builds. Hopefully, that will be done, when you get access to your map-ac2200 again.

My LAN doesn't have connection to internet when I install Wireguard on the router and then

remove LAN forwarding to -> WAN Interface
set LAN forwarding to -> Wireguard Interface

This is what I always did to prevent IP leaks but apparently something gets broken with this build.

I got this running on my rockpro64 and it is running better than previous stable versions I tried. The nftables change got me because I always run strictly IPv4 whenever possible but I don't mind running IPv6 too now. I fixed it by removing all instances of option family 'ipv4' from all zones in my firewall config but I think I could have technically left the ones that didn't use masquerading.

Installed it on Netgear R6220 and Tp-Link Archer C50 V3. Both are running great with no issues so far. But I have noticed that nlbwmon does not work with flow offloading enabled, maybe the packages needs to be updated or something?

Anyways, a great release!

Update:- I can certainly confirm that some older 2.4GHz devices(like samsung SM-M105F/DS) are losing connection after sometime. They show "Connected without internet". This happens on both the routers.

1 Like

Can you run flent rrul -p all_scaled -l 60 -H netperf-west.bufferbloat.net -o results.png on both the 2.4 and 5GHz radios and share the results? If you're on windows you'll need to install wsl ubuntu first.

The 2.4GHz radio has had issues for years https://github.com/openwrt/mt76/issues/487

Yes, I had to rebuild my install from scratch as suggested. It then works well except firewall4 needing an older version of software! and the fact that it boots - eventually..... both brought up by elizan.

Sure! I will update you with the info later, need some time.

Archer C50 V3 2.4Ghz
archer_c50_2_4ghz_OpenWrt 22.03.0-rc1

Archer C50 V3 5Ghz
archer_c50_5ghz_OpenWrt 22.03.0-rc1

Netgear R6220 2.4Ghz
netgear_r6220_2_4ghz_OpenWrt 22.03.0-rc1

Netgear R6220 5Ghz
netgear_r6220_5ghz_OpenWrt 22.03.0-rc1

I have igmp_snooping enabled for 2.4Ghz radio on both the routers and enbled Software Flow offloading only on Archer C50.

Do tell me your analysis.

This looks like a disconnect to me. I don't have any advice to solve it. I suggest adding this to the github bug report so anybody interested can see the 2.4GHz radio still has reproducible issues, even on the latest version.