What's new

News OpenWRT 22.03 Released

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

sfx2000

Part of the Furniture
The OpenWrt Community is proud to present the OpenWrt 22.03 stable version series. It is the successor of the previous 21.02 stable major release.


The OpenWrt 22.03 series focuses on the migration from iptables based firewall3 to the nftables based firewall4.

Highlights in OpenWrt 22.03.0

Firewall4 based on nftables

Firewall4 is used by default, superseding the iptables-based firewall3 implementation in the OpenWrt default images. Firewall4 uses nftables instead of iptables to configure the Linux netfilter ruleset.

Firewall4 keeps the same the UCI firewall configuration syntax and should work as a drop-in replacement for fw3 with most common setups, emitting nftables rules instead of iptables ones.

Including custom firewall rules through /etc/firewall.user still works, but requires marking the file as compatible first, otherwise it is ignored. Firewall4 additionally allows to include nftables snippets. The firewall documentation explains how to include custom firewall rules with firewall4. Some community packages that add firewall rules might not work for now, and will need to be adapted to fw4: this will happen gradually throughout the lifetime of the 22.03 release series.

The legacy iptables utilities are not included in the default images anymore, but can be added back using opkg or the Image Builder if needed. The transitional packages iptables-nft, arptables-nft, ebtables-nft and xtables-nft can be used to create nftables rules using the old iptables command line syntax.

Many new devices added

OpenWrt 22.03 supports over 1580 devices. Support for over 180 new devices was added in addition to the device support by OpenWrt 21.02. OpenWrt 22.03 supports more than 15 devices capable of Wifi 6 (IEEE 802.11ax) using the MediaTek MT7915 wifi chip.

More targets converted to DSA

The following targets or boards were migrated from swconfig to DSA with OpenWrt 22.03 in addition to the systems already migrated with OpenWrt 21.02:

bcm53xx: All board using this target were converted to DSA
lantiq: All boards using the xrx200 / vr9 SoC
sunxi: Bananapi Lamobo R1 (only sunxi board with switch)

Dark mode in LuCI

The LuCI bootstrap design supports a dark mode. The default design activates dark mode depending on the browser settings. Change it manually at “System” → “System” → “Language and Style”.

Year 2038 problem handled

OpenWrt 22.03 uses musl 1.2.x, which changed the time_t type from 32 bit to 64 bit on 32 bit systems, on 64 bit system it was always 64 bit long. When a Unix time stamp is stored in a signed 32 bit integer it will overflow on 19 January 2038. With the change to 64 bit this will happen 292 billion years later. This is a change of the musl libc ABI and needs a recompilation of all user space applications linked against musl libc. For 64 bit systems this was done when the ABI was defined many years ago, the glibc ARC ABI already has a 64 bit time_t.
 
Love firewall4/nftables and QoSify with CAKE! Great release!
 
So, I managed to get In touch with the OpenWRT developer working on device support for the IEI Puzzle-M902 and...good thing I decided to do more research before pulling the trigger.

Turns out the company (IEI aka QNAP's parent) never actually tried OpenWRT and used Marvell's proprietary driver rather than the upstream Linux driver. All the network interfaces were dead when he asked for and finally received the sample devices, so it took a while to get those working. The bootloader isn't well designed with the eMMC partition layout not ideal. So no dual-booting unless that's replaced.

Aside from these, the hardware's all good. He's managed to get the ports up and working although the 2.5G ports still can't adapt to 100M/10M rates. He's working with the IEI development team to see if Marvell can provide support to fix that.

The most important part though (to me at least) is that it runs pretty smoothly on OpenWRT snapshot/22.03.0. Further tweaking of the thermal profile (it has a PWM-controlled fan) is on the cards.
 
Turns out the company (IEI aka QNAP's parent) never actually tried OpenWRT and used Marvell's proprietary driver rather than the upstream Linux driver
Sounds like WRT1900AC all over again...
 
Sounds like WRT1900AC all over again...

Not OpenWRT's fault there - marketing folks just assumed it would be supported.

Many vendor BSP's are based on OpenWRT with all the special sauce kept in-house - much like the QC-Atheros NSS and ath10k/11k drivers - Marvell with Linksys and the WRT1900/1200/3200's...

Mediatek has been doing a decent job of supporting OpenWRT directly with frequent source drops for their FOSS drivers - they still maintain their closed source code for OEM's, but I do appreciate their support for Open Source
 
Not OpenWRT's fault there - marketing folks just assumed it would be supported.

Many vendor BSP's are based on OpenWRT with all the special sauce kept in-house - much like the QC-Atheros NSS and ath10k/11k drivers - Marvell with Linksys and the WRT1900/1200/3200's...

Mediatek has been doing a decent job of supporting OpenWRT directly with frequent source drops for their FOSS drivers - they still maintain their closed source code for OEM's, but I do appreciate their support for Open Source
This helped put things in perspective. I'd assumed it was just a QNAP thing given their reputation for releasing devices that had great hardware let down by software still in the beta stage, based on posts I'd seen on the forum. As for the the IEI device, it seems that the developers (OpenWRT and IEI) are trying their best to get all the bugs ironed out. The hardware-identical QNAP Qhora-322 packaged with their own QuRouter OS was announced last month but I haven't seen it in the market anywhere yet. I asked QNAP's marketing team about it and they recommended me the Qhora 301W instead. Guess they're still working out the bugs in the Qhora-322 as well.
 
Not OpenWRT's fault there - marketing folks just assumed it would be supported.
Not saying it was. Back then, Linksys started advertising it as "OpenWRT compatible" before the OpenWRT devs could even tell them "Uh, we can't support that until Marvel provides us with open source drivers for it", and Marvel went "Uh, we don't have any open source drivers to give you right now, we'll need time to prepare one".
 
Marvel went "Uh, we don't have any open source drivers to give you right now, we'll need time to prepare one".

It was a lot worse than that - it was an API issue... similar to Broadcom's WL interfaces.
 
What kernel is the new version using?
 
Similar threads
Thread starter Title Forum Replies Date
K Need help with Transmission in OpenWRT. General Wi-Fi Discussion 4

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top