OpenWrt 22.03.4 service release

Release and security announcements
21

Upgraded my Linksys E8540. There was some breakage, but I am not sure if it was due to the upgrade or merely due to the reboot.

  1. The USB LTE modem (Huawei NCM) did not get IPv6 on the first try.
  2. The StrongSwan VPN that I use to get a public IP address did not come up correctly (connected but no IP). Fixed with a restart.
  3. The WireGuard VPN that I use in order to access some specific geo-restricted sites broke. For some reason, there was a route to the WireGuard VPN server through the IPSEC tunnel, which is wrong.
1 Like
22

Add new supported devices to table of hardware

23

Does installing this version still cause bootloop and bricking issues for BT HomeHub 5?
Do you think I should upgrade from version 21.02.6 to this version or not at all recommended?
I have one more question, is it possible to brick my router in all versions of 22.03.X?
What should I do to stay on version 21.02.6?

24

Second service release without support for Linksys WRT AC series, are we dropping support or what?

3 Likes
25

Yes, support is dropped for wrt ac series in the 22.03 release. Use master or downgrade to 21.02

26

That's a shame, switch was patched months ago

1 Like
27

A fix for the bt hub 5a boot looping issue was merged a couple of weeks ago https://github.com/openwrt/openwrt/pull/12265

https://openwrt.org/releases/22.03/changelog-22.03.4 ( lantiq: nand: don't yield while holding spinlock)

You must not keep any setting when upgrading the BT hub to the 22.03 branch because of the switch to DSA. I'd suggest backing your existing settings up first.

I've tried the patch with my own snapshot build plus the 5.15 testing kernel and it seems to have cured the bootloop, even with lots of extra packages included which previously made prolonged bootlooping occur most boots.

I think it may be taking just a few seconds longer to boot than my previous build of 22.03 which I'd used a workaround to avoid the boot loop.

1 Like
28

Where/when exactly ? (Git commit pls)

29

Capture

So, in your opinion, should I update version 21.02.6 step by step or can I update to the latest version 22.03.4 without any problems?
Sorry, I didn't understand what you meant by this problem. This means that this problem has been patched in all 22.03.x builds
I don't want to lose my device :frowning:
So please guide me , Why this problem has not been solved yet on the Openwrt website!

30

Switch issue was resolved as of kernel 5.15, divested build implemented it last year.

31

The required patch is included in only the 22.03.04 release (plus current snapshots), do not install previous versions of 22.03.

I haven't tried this actual release yet, so I would suggest perhaps waiting for someone else with a bt hub 5 to try it and confirm that it is working before installing yourself, as it sounds like you'd not want to do a serial console recovery.

(I did find that in boot looping builds that the bt hub would often boot successfully after a few hours)

Remember not to keep your settings if/when you do install it.

1 Like
32

Unfortunately, I don't have access to the console serial. Otherwise, it would be easier for me.
Anyway, I will try it because I am also affected by this version 21.02
I hope it's worth it

33

I know 5.15 has the fix that's why I recommended using master (divested build base) but 22.03 uses 5.10 kernel and no fix there afaik

1 Like
34

:white_check_mark: Version 22.03.4 successfully installed for BT Home Hub 5A

Upgrade From 21.02.6 => 22.03.4 new

and thanks for your help and all dear Openwrt developers & ... Fortunately, the boot speed seems to have improved, but I hope that I won't face the problem of Boot loop in the future, because I encountered it once in version 21.02.5, and after a lot of effort, the device was able to boot up. It's just that the initial installation took a lot of time compared to the previous versions, but the reboot is better.

:stopwatch: reboot time : 45s
:stopwatch: erase factory time : 1m,5s

:no_entry_sign: :no_entry_sign: :no_entry_sign: Please do not install versions 22.03.0 - 22.03.3 For BT Home Hub 5 / Plusnet Hub One under any circumstances, there is a very strong possibility of bootloop and bricking. :no_entry_sign: :no_entry_sign: :no_entry_sign:

35

While the resolution has been submitted, it does leave a gaping hole for those that are affected from migrating from "stable" builds 21.02.x, 22.03.x to now the intentionally "broken" 21.02.6 and 22.03.4 builds. Not sure how the affected users would feel to migrate to the snapshot builds since the rushed release could have been avoided if the UBI 'build.c' code had been rolled back to the previous state or the published patch in early March was adopted. Being comfortable with the snapshot builds due to inherent long-standing limits with the 5.10.x builds, consistency on many targets adopting the same builds for predictable operation, and concerns over timely CVE roll-outs, it does not have a significant impact for some but will for most. The correct approach should be to roll-in the fix and replace the 21.0.6 and 22.03.4 targets so that unsuspecting upgrades don't lead to soft-bricking of devices when individuals do not understand the scope of the problem noted in the forums and blindly sysupdate by clicking on the links on the wiki. Not a professional approach.

3 Likes
36

Thank you to the team!

So far upgraded an Itus Networks Shield, and several Extreme Networks WS-AP3825I AP's.

Those AP's all took abnormally long (approx 10 min) with just a flashing green light but they all upgraded successfully.

I wasn't able to observe the console to investigate the delay as I didn't uninstall them from their locations.

37

Yep, but release 22.03.x runs on kernel 5.10. See Version History
Wait for 23 rc1.

38

No. The issue involved here will be fixed definitively in the next major release. It has already been fixed in master, which i run well on my wrt3200.

1 Like
39

I can confirm fix on MR8300 it works

after patch adding

40

Another RT3200 updated successfully. Thanks, devs!

An ongoing issue I've been having may have been fixed: dropbear came right up on the IPv6 listen address. On previous reboots, I've had to log in via IPv4 and restart dropbear to get it to come up on both address families. This is the first reboot I recall where v6 came up without intervention...