OpenWrt 22.03.2 second service release

Working well on GL.iNet GL-B1300, Netgear R6100 and TPlink archer C7v5.
Thanks to the devs!

Installed 22.03.2 on my WRT32X along with lots of added packages: SQM, Adblock, Samba, USB3 storage, Advanced-reboot, etc. Running great. Thanks devs.

4 Likes

How do people install this version?

2 Likes

Upgraded from 23.03.0 keeping configuration on Linksys WRT1900ACS v1 and Netgear WAC104. Other than "Packet Steering" being enabled on the WAC104 when I had it disabled, all seems well.

1 Like

Yes, I noted/discussed this in a few threads. I'm usually told to wait or download/install/run the image builder.

Example:

This user noted before the release: OpenWrt 22.03.1 first service release - #59 by elatllat

But obviously they misunderstood, as I was discussing version .1 and now version .2 - both released and showing unsupported at the time of the discussions.

Yes, that's when it was built. It should download/install.

Upgraded from 22.03.1 and reset all settings. Besides getting the issue mentioned in the linked thread, everything appears ok.

I noticed this was enabled by default in a new WAX202 converted from stock to version .1.

Thanks to all who made this release/security fix possible. As always, the upgrade went smoothly and was a very short affair.

There appears to be a change in fw4 that prevents it from correctly parsing ipsets using the loadfile configuration option. This prevents my device from booting, but I found a workaround--which is to not configure ipsets using loadfile but list them one by one.

I was on 22.03.1 previously on an RT3200 which was fine (as with all prior releases) using the loadfile configuration for ipsets. When I did a sysupgrade to 22.03.2 and preserved the configuration, the device failed to complete the boot cycle. I reset the device, and then manually reconfigured it line by line until I found the configuration where it started to fail to boot.

Here was the problem area in /etc/config/firewall:

uci set firewall.trusted=ipset
uci set firewall.@ipset[-1].name=trusted
uci set firewall.@ipset[-1].family=ipv4
uci set firewall.@ipset[-1].match=src_mac
uci set firewall.@ipset[-1].loadfile=/etc/trusted_macs
uci commit

The problem is the loadfile configuration option. When I run "fw4 print" with the above configuration lines, fw4 errors out over and over recursively with:

Skipping invalid entry 'null' in file '/etc/trusted_macs' for set 'trusted'

This fw4 error keeps going on indefinitely which prevents the device boot cycle from completing. For those interested, the file for the ipset data is just a text file with mac addresses, one on each line. This file used to work with 22.03.1 and prior versions. Now it errors out in fw4 on 22.03.2. Here is how it was created:

cat <<EOF > /etc/trusted_macs
MAC ADDRESS HERE
ANOTHER MAC ADDRESS HERE
EOF

The workaround was to not to use the loadfile command for ipsets but list each item using the entry option. For example, if I replace my configuration with the following, then fw4 loads correctly and the device now boots again on 22.03.2:

uci set firewall.trusted=ipset
uci set firewall.@ipset[-1].name=trusted
uci set firewall.@ipset[-1].family=ipv4
uci set firewall.@ipset[-1].match=src_mac
uci list firewall.@ipset[-1].entry=MAC ADDRESS HERE
uci list firewall.@ipset[-1].entry=ANOTHER MAC ADDRESS HERE
uci commit
2 Likes

@jow , this fw4 regression report might interest you.

1 Like

The latest releases were added to the upgrade server, thanks to @otaran

3 Likes

Yes, this one slipped through the cracks. I pushed a fix to firewall4.git and will bump the package in master openwrt-22.03 later, a fix can be deployed by upgrading firewall4 through opkg once the updated packages become available.

7 Likes

Updated Xiaomi AX3200 AX6S. I added DDNS services & it runs fine.
Also on BT home hub 5 the boot loop is gone & it now runs fine also.
Thanks to the devs for this release/security fix. :+1:

Thanks for the really fast security fix :+1:

One question, Wifi seems to be less stable after this upgrade, could that be, or should I look for external factors like neighbors, weather circumstances.

[edit] issue doesn't seem to be related to the update as nothing has changed since yesterday and the stability is good again.

First, again thanks to the OpenWrt team!

Just did sysupgrade on APU2 x86. Everything came back fine with just two things of note:

  1. IPv6 is slow coming back (no AAAA in the DNS yet). I think I just need to wait longer for the RAs and NDs to get everyone synced up.
  2. dropbear only came up listening on IPv4, /etc/init.d/dropbear restart got it listening on all addresses. (I think this is a known issue from a while back, maybe related to #1?)

Will the ea8500 sysupgrade.bin ever work again or will factory.bin be required forever more?

(I'm getting the partition size change error on every upgrade)

most routers have 2 partitions, one for the kernel, one for the remaining stuff.

Your router model (among a few other models) have a vendor defined kernel partition size limited to 3MB, which is too small for recent OpenWRT 21 and 22 updates. The kernel partition size has to be enlarged, before being able to apply a more recent OpenWRT version.

the sysupgrade image and sysupgrade process cannot change partition sizes. You with your model have to onetime use the factory bin and the device specific method to apply the factory bin, that does resize the kernel partition and then apply OpenWRT.

On some models this can cause issues, if you want to late go back to vendor firmware. Also I do not know your device, better check the wiki and forum first, you dont want to brick your stuff.

1 Like

onetime use the factory bin

The issue is it's every time, not just once. Either the instructions are missing something or there is a bug that is throwing false positives.

Upgraded my Cudy WR1300 with settings from 21.02.3 to 22.03.2
No issues so far, thanks for your work, devs :+1:

I upgraded my Linksys WRT3200ACM to this release and everything is working well. Thank you, developers!

4 Likes