OpenWrt 22.03.3 third service release

OpenWrt is always stable on my Raspberry Pi4. Great work :+1:
But Packet Steering and irqbalance doesn't work

Resolved by add metric to Wan

uci set network.wan.metric='10'

I'm seeing an issue with wireguard-tools - 1.0.20210424-3 that a user can invoke shell command "ifdown wg0" or "ifup wg0".

What is expected when taking down an active commercial wireguard session, one could surf on the ISP network. What is occurring is the interface goes down but access to internet/web browsing stops. Toggling the command to up does not restore wg0 as it stays stopped.

wg0 interface is in the WAN firewall zone.

luci-app-wireguard  
luci-proto-wireguard  
wireguard-tools 
kmod-wireguard

I believe this popped up in 22.03.2 when I installed up from 22.03 back in January 2023, and is present in the update I did yesterday.

As a work around I can issue uci commands to take the "allow ip route" to 0 and commit network and restart network.

uci set network.@wireguard_wg0[-1].route_allowed_ips='1';uci commit firewall; uci commit network; /etc/init.d/network restart

I'm posting to see if anyone can confirm this in their build or get the attention of a Dev to correct me or suggest I post this in GitHub.


Thanks

Install from snapshot. That way you get kernel 5.15 where the bug is fixed. I did and it was really easy. That will solve matters until the devs fix the issue at root

1 Like

Hello, I am fairly new to OpenWRT and got a WRT3200ACM recommended by an engineer as a way to improve my privacy. I saw there is this upgrade but the fireware selector does not have this model anymore. I see in the post there are some problems and people asking if this is a death sentence to it. Can someone clarify it to me in simple terms? Will it ever be this update or following updates to WRT3200ACM? Maybe @hauke?

1 Like

Everything you're asking has been answered in this very thread already, please read it first. If you then have specific -further- enquiries, feel free to ask.

3 Likes

I have just read the whole post, again I am very new to OpenWRT and do not have knowledge about these modules and components being mentioned. So I am asking for an explanation in non-technical terms if possible.

1 Like

In short, the problem is temporary and already fixed in the development branch. Next major release should support it, and you could use a development build (known as 'snapshot') or wait and use an older version in the meantime.

6 Likes

Thanks a lot for your answer. It is clear now, since it is working I will wait for the next version.

Is it planned that fw4 doesn’t post events to hotplug, from 22.03 and onwards? Like fw3 does.
Thanks

Thread already exists:

When Kernel 5.15 versions start come out ( Ath79)?

They already do for the development master branch.
And will be in the next new stable release branch, 23.0x.

But the old stable branches like 22.03 will not get new major version backports.
Future 22.03 maintenance releases will still have the current old kernels.

1 Like

i has a same problem with my box fai in 22.03.3 upnp work correctly

but just ont + router upnp work sometimes yes sometimes no ?

why

github maintainer reply

U can try latest snapshot build to see if this issue has gone
I don't have time now so decide to wait for the next stable.

3 Likes

I'm using an ea8500. I am currently running 22.03.2. When I upload a 22.03.03 sysupgrade image, I get this error/warning:

The device is supported, but this image is incompatible for sysupgrade based on the image version (1.0->2.0). Sun Feb 12 12:18:10 PST 2023 upgrade: *** Kernel partition size has changed from earlier versions. You need to sysupgrade with the OpenWrt factory image and use the force flag when image check fails. Settings will be lost. *** Image check failed.

I don't understand this. I already installed a factory image when I first upgraded to 22.03.2 in order to resize the kernel partition.

The partition info from the boot log is collapsed at the end of this post.

I'd just install the factory image again, but I'd like some idea of what's going on here. Is this expected?

Summary
[    2.757107] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xa1
[    2.757396] nand: AMD/Spansion S34MS01G2
[    2.764105] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    2.768091] 18 fixed-partitions partitions found on MTD device qcom_nand.0
[    2.775399] Creating 18 MTD partitions on "qcom_nand.0":
[    2.782137] 0x000000000000-0x000000040000 : "SBL1"
[    2.788765] 0x000000040000-0x000000180000 : "MIBIB"
[    2.795028] 0x000000180000-0x0000002c0000 : "SBL2"
[    2.799612] 0x0000002c0000-0x000000540000 : "SBL3"
[    2.806741] 0x000000540000-0x000000660000 : "DDRCONFIG"
[    2.809216] 0x000000660000-0x000000780000 : "SSD"
[    2.814231] 0x000000780000-0x000000a00000 : "TZ"
[    2.821390] 0x000000a00000-0x000000c80000 : "RPM"
[    2.826298] 0x000000c80000-0x000000dc0000 : "art"
[    2.828993] 0x000000dc0000-0x000000ec0000 : "APPSBL"
[    2.832997] 0x000000ec0000-0x000000f00000 : "u_env"
[    2.836643] 0x000000f00000-0x000000f40000 : "s_env"
[    2.841174] 0x000000f40000-0x000000f80000 : "devinfo"
[    2.846136] 0x000000f80000-0x000003780000 : "kernel1"
[    2.918862] 0x000001380000-0x000003780000 : "rootfs1"
[    2.988854] 0x000003780000-0x000005f80000 : "kernel2"
[    3.066345] 0x000003b80000-0x000005f80000 : "rootfs2"
[    3.136461] 0x000005f80000-0x000008000000 : "syscfg"

appears so but also see rest of git log as disabled? this is master, best check 22.x branch

That was supposed to be dealt with in the upgrade to 22.03.x, which required a factory.bin. This solved my problem with upgrading from 22.03.2 to 22.03.3.

Yes, well if you overwrote the config that allows an upgrade to know where things are regarding your device... it just don't know.

1 Like

Thanks for digging around in the commits.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=863288b49d3d1466f22bcf6098e4635a5be98626

mac80211: Update to version 5.15.92-1

This update mac80211 to version 5.15.92-1. This includes multiple
bugfixes. Some of these bugfixes are fixing security relevant bugs.

Any idea how serious these "security relevant bugs" are?