OpenWrt 22.03.3 third service release

yes i have the same problem for x86-64

Got a question to you all. Why there's no package bind-server available for 22.03.3? Anyone answers for this? Thank you for answering.

Asked and answered, read back; I assume the search button works.

2 Likes

OK....This mvebu switch thing has got me spooked

I usually leave the "world of snapshots" stuff to you qualified guys but it sounds like we mvebu owners need to take some action this time.

I use the imagebuilder to compile my flash images but I have not ever used one for a snapshot.

I DL'd "openwrt-imagebuilder-mvebu-cortexa9.Linux-x86_64.tar.xz" from the Index of (root) / snapshots / targets / mvebu / cortexa9 / and added my packages and "files" to it and ran it as usual.

It compiled normally except for one package.
Flashed a WRT3200ACM with the image and it is up and running with luci.

Status overview shows:
Firmware Version OpenWrt SNAPSHOT r21729-89eb8b50d1 / LuCI Master git-22.361.69865-deed682
Kernel Version 5.15.86

Is there anything else that needs to be done to complete a snapshot install?
Will system software update properly?k Or not at all?

1 Like

I'm not sure what packages you installed with master snapshot to know if there is anything else needed (e.g. advanced-reboot, sqm, adblock, samba, etc.), but if you're up and running it sounds like you're good.

For updates you can just flash a new sysupgrade snapshot anytime, they are built almost daily. My current build has been running 3 weeks uptime, keeping it going until the new GCC 12 commit gets a week or so I'll flash a new one if it's using that. Usually I just flash a new one monthly or so.

I just installed the SNAPSHOT (r21729-89eb8b50d1) and it seems to run fine on my WRT3200ACM. I had to install some luci and other packages. Am I on the safe side for now? Should I reinstall as new snapshots come out?

You should be good for a bit, can keep an eye on the github for needed changes, or just install a sysupgrade snapshot monthly or so until the next release which should include 5.15 by default.

1 Like

Happy to report an 'Attended Sysupgrade' (keeping settings) for TP-Link c2600
22.03.2 => 22.03.3 all OK.

So far OpenWrt is behaving itself nicely! Great job :scream_cat: to all involved!

2 Likes

I tried to upgrade from 21.02.5, keeping settings. It did not work well, so I tried again via uboot and it did not work well for 3 times, then I tried the 23.03.2 version, did not work as well, tried back the 21.02.5 version back and it worked. What can I do?
Device - GL.inet S1300

What device?

Man I can't tell if you are joking, but I'm living out of France and I use upnp frequently.
Thing is some stupid, yet essential apps have no manual port mapping function, so upnp is a must for me.

2 Likes

x86-64 EFI build is working well on a newly christened Dell OptiPlex SFF machine acting as a router-on-a-stick using the integrated Intel NIC.

Upgraded two devices today from 22.03.2, kept configuration, no issues so far:

Netgear R7800:

Pretty vanilla configuration: Main home router hanging off the residential ISP. Divides the ISP-supplied IPv6 PD across the house networks. 2 APs and 1 mesh point on the 2.4GHz radio, 1 AP on the 5 GHz radio.

Buffalo WZR-HP-AG300H:

Probably a more "interesting" configuration: Mesh point on the 2.4 GHz radio, layer 2 bridging with the wired LAN. Essentially a wireless bridge for anything connected to its wired side, currently only a printer. The layer 3 logical network interface on this bridge is configured as the router's upstream/WAN in terms of firewall etc, and is a DHCP client to the Netgear.

The physical WAN port on the other hand is configured as a "LAN", including providing DHCP service. Essentially a fallback device management interface in case the Netgear and/or the mesh misbehaves.

1 Like

GL.inet S1300

Yeah, I borked the setup on my WRT1200AC by flashing a snapshot (including the custom packages that are normally included for that model). I'm making use of my LAN ports, though, and, if I've read this thread correctly, it's expected that some devices will become unreachable post-flash.

I guess, for now, I'll stick with 22.03.02. I'll echo some of the comments I've read in feeling a bit uncertain about all this. Not sure why my snapshot didn't include the kernel 5.15 fixes someone else mentioned.

In case it's relevant, here are the packages I installed, on top of today's snapshot for Linksys WRT1200AC:

base-files busybox ca-bundle cgi-io dnsmasq dropbear firewall4 fstools fwtool getrandom hostapd-common iw iwinfo jansson4 jshn jsonfilter kernel kmod-cfg80211 kmod-crypto-aead kmod-crypto-ccm kmod-crypto-cmac kmod-crypto-crc32c kmod-crypto-ctr kmod-crypto-gcm kmod-crypto-gf128 kmod-crypto-ghash kmod-crypto-hash kmod-crypto-hmac kmod-crypto-manager kmod-crypto-null kmod-crypto-rng kmod-crypto-seqiv kmod-crypto-sha256 kmod-gpio-button-hotplug kmod-lib-crc-ccitt kmod-lib-crc32c kmod-mac80211 kmod-mwlwifi kmod-nf-conntrack kmod-nf-conntrack6 kmod-nf-flow kmod-nf-log kmod-nf-log6 kmod-nf-nat kmod-nf-reject kmod-nf-reject6 kmod-nfnetlink kmod-nft-core kmod-nft-fib kmod-nft-nat kmod-nft-offload kmod-ppp kmod-pppoe kmod-pppox kmod-slhc libblobmsg-json20220515 libc libgcc1 libiwinfo-data libiwinfo-lua libiwinfo20210430 libjson-c5 libjson-script20220515 liblua5.1.5 liblucihttp-lua liblucihttp0 libmnl0 libnftnl11 libnl-tiny1 libpthread libubox20220515 libubus-lua libubus20220601 libuci20130104 libuclient20201210 libucode20220812 libustream-wolfssl20201210 libwolfssl5.5.1.ee39414e logd lua luci luci-app-firewall luci-app-opkg luci-base luci-lib-base luci-lib-ip luci-lib-jsonc luci-lib-nixio luci-mod-admin-full luci-mod-network luci-mod-status luci-mod-system luci-proto-ipv6 luci-proto-ppp luci-ssl luci-theme-bootstrap mtd mwlwifi-firmware-88w8864 netifd nftables-json odhcp6c odhcpd-ipv6only openwrt-keyring opkg ppp ppp-mod-pppoe procd procd-seccomp procd-ujail px5g-wolfssl rpcd rpcd-mod-file rpcd-mod-iwinfo rpcd-mod-luci rpcd-mod-rrdns ubi-utils uboot-envtools ubox ubus ubusd uci uclient-fetch ucode ucode-mod-fs ucode-mod-ubus ucode-mod-uci uhttpd uhttpd-mod-ubus urandom-seed urngd usign wireless-regdb wpad-basic-wolfssl

I have sysupgraded 5 devices (3x TL-WDR4900V1, 2x Archer-C7V5) successful without any problem (settings kept).
Thanks to everyone!

I did the assembly according to the standard:
git clone https://github.com/openwrt/openwrt.git -b v22.03.3
cd openwrt
git checkout -b v22.03.3
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
make
I have a Qualcomm Atheros QCA986x / 988x Wi-Fi card, so I had to exclude kernel modules from the assembly (kmod-ath10k, kmod-cfg80211, kmod-mac80211), otherwise the build fails.

Upgraded "Netgear R7800 (Nighthawk X4S AC2600)" today morning. No issues, at least I did not detect anything.

I would like to thank the developers and wish them a happy new year.

2 Likes

I'm running 22.03.2 on WRT-1200AC and I'm fairly sure my switch isn't acting as a hub. tcpdump on each of the LAN ports shows only the traffic I'd expect. Switch lights are blinking independently, and the switch connected to the 1200AC passing tagged VLANs doesn't have any complaints.

You say they're not building images for the WRT-1200AC anymore? Are you talking about something different than the images I see when I go here: https://openwrt.org/toh/linksys/wrt1200ac

I'm hoping 22.03.3 isn't there because of this switch issue.

Read the original post it says it right there. Mvebu isn't being built, that includes your 1200. It'll likely be back in this years 23.0x release with kernel 5.15 since the switch bug is fixed there (from my testing on master snapshot with my wrt32x at least).