OpenWrt 22.03.0-rc4 fourth release candidate

I've noticed the reboot issue with the BT hub 5a gets substantially worse with the more/larger versions of modules built into the kernel and packages included in the build. One of my recent builds of the master branch with lots of stuff like batman-adv and wpad wolfssl built in resulted in one of my routers taking at least an hour to boot successfully.

So, as rc4 was getting stuck in prolonged reboots at start-up, I had a stab at building a version of OpenWrt 22.03.0-rc4 r19426-2b1941e47d with Luci omitted based on this guide and inadvertently managed to omit lots of modules such as wpad and wireless too from the sysupgrade file, which for all the ones I noticed were missing I've installed from the feeds along with luci, and it boots/reboots pretty reliably so far.

1 Like

Seems that the online builder has currently some problem to build custom images, still the same error.
I'm not in hurry, can wait until the problem gets resolved.
Also don't want to mess my production system until final version of 22.03 arrives (21.02.3 is very stable).

1 Like


I've installed 22.03.0-rc4 on my Raspberry Pi2 but unable to get the (WAN interface) TP-Link UE300 to work because it needs the kmod-usb-net-rtl8152 module installed which I am not able to because apparently it's looking for the r8152-firmware dependency which I can't find in both kmod and package repositories. Could someone please tell me where to download this, or if there's a work around.

If there's any consolation, version 21.02.03 does not require this package dependency.


Is it this arch?

Thanks @dave14305 , you're a lifesaver.

Hi, we're having a problem with Docker on x86 build of 22.03.0-rc4 as discovered here: PiHole in a docker, no internet access

It seems that containers can no longer access the internet through OpenWrt. In release version 21.02.0 (version currently running in my production setup) the container is able to access the internet.

We're hoping if we could get some idea here on what could be causing this problem, or if the tutorial for setting up pihole on Docker should be updated for 22.03. Could it be that the switch nft/firewall4 has affected in someway?

So basically, if container tries to reach anything outside the docker network, it gets a Destination Port Unreachable. I tried for example the below on:

docker run -it nicolaka/netshoot ping

And this is output on 22.03.0-rc4:

root@OpenWrt:~# docker run -it nicolaka/netshoot ping
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Port Unreachable
From icmp_seq=2 Destination Port Unreachable
From icmp_seq=3 Destination Port Unreachable
From icmp_seq=4 Destination Port Unreachable
From icmp_seq=5 Destination Port Unreachable
From icmp_seq=6 Destination Port Unreachable
From icmp_seq=7 Destination Port Unreachable
From icmp_seq=8 Destination Port Unreachable
--- ping statistics ---
8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7261ms


i hope openwrt releases stable version 22.03 soon i want to do a test


On that subject, is there a published schedule for 22.03? Or does it happen organically?

1 Like

I would say it is different for every release depending of what is new.
For the 22.03 we will probably need to see a very stable and working fw4 before it is any point of making a actual release. If the firewall doesn’t work then the whole security concept of OpenWrt kind of fails.

And the future life of add on packages like BanIP working with fw4 is still to come.


Is fw4 in 22.03rc not secure?

You missed the sentence just before the one you got stuck on.

Developer meeting minutes are sporadically published (here) from time to time with development news, updates and release schedule targets; however, no news since March.

1 Like

I understood your point that anything not stable or fully functional has the potential to be a security risk. I was wondering if you were aware of something specific that was not stable or not working in the current fw4 implementation that is known to make 22.03rcx insecure.

1 Like

The online imagebuilder is working again, thanks :ok_hand:

I successfully managed to create a custom 22.03.rc4 build:
-REMOVED packages: -dsl-vrx200-firmware-xdsl-a -dsl-vrx200-firmware-xdsl-b-patch
+ADDED packages: kmod-usb-storage block-mount kmod-fs-ext4 e2fsprogs
resulting image size is 7.67 MB.

Haven't had time to test whether the firmware is working but it seems promising.
Thanks again for pointing me to this direction.

Dear all,

I was able to build firmware with my own application on rc3, but when building on rc4 it is complaining about missing on packages libmosquitto and libgps missing, I can't find them on make menuconfig and they were not downloaded.

WARNING: Makefile 'package/feeds/sio_packages/infosys/Makefile' has a dependency on 'libmosquitto', which does not exist
WARNING: Makefile 'package/feeds/sio_packages/infosys/Makefile' has a dependency on 'libgps', which does not exist

I checked my git checkout, seems correct. May be I am missing something obvious?
git checkout v22.03.0-rc4

Thanks in advance..

Sorry... Issue tied to make distclean somewhere... Restarted from scratch and now it is fine.

Installed it yesterday on my ZyXEL P2812-HNU-F1. Uptime is 26 hours, at the moment. Everything works fine, so far.

I had one problem. I am using blacklist file in dnsmasq, by adding a line to /etc/dnsmasq.conf:
Worked fine, but now dnsmasq refused to start, and told me that file doesn't exist. It took me some time to find out that dnsmasq now runs in a jail. (ujail), and the only way I could find to get this working is to edit /etc/init.d/dnsmasq, and add a line
procd_add_jail_mount /etc/dnsmasq/blacklist.conf
to function dnsmasq_start()

I wonder, is there no better way? Editing start scripts is ugly.

I tried several times to do a sysupgrade from 21.02.2. In all cases, the system rebooted but came back at 21.02.2 as if nothing happened. No difference via Luci or CLI.

This is on a RPi CM4 system with eMMC.

Should the sysupgrade work for for this arch or is there something else that needs to be done?

I think op actually uses /etc/config/dhcp to hold config for dnsmasq
and /etc/dnsmasq.conf is now only reserved for compatibility. Previously I used 'confdir' parameter in /etc/dnsmasq.conf with no effect, but adding the same to /etc/config/dhcp works.
The actual grammar is somehow different, check the wiki.

rc5 has been announced