OpenWrt 22.03.0-rc4 fourth release candidate

Well then there is no real point splitting wan and lan hardware on single port devices or multi port devices (just simply make a single bridge of everything) since all the data must be routed and tagged with vlan and every bit of data goes through the same single Gbit port to the CPU on a full duplex line working at about half speed anyway.

That's about right! This is what I advise on the Converting to DSA page I wrote.

Even if we had a port directly connected to the CPU (this is possible on the mt7621 SoC), let's say the wan port, it still wouldn't matter if we were to put it in the same bridge with other switch port interfaces. If you want to do VLAN filtering on all of the interfaces, you put them all in the same bridge. wan and lan interfaces will still have 2Gbps access to the CPU in total.

There's also this feature called bridge offloading. Most DSA subdrivers implement this. The only one I know that lacks this is the rtl8365mb driver. What this feature does is it offloads traffic between switch ports. Forwarding frames between switch ports will be offloaded to the switch hardware so they don't go through the CPU and exhaust the link to the CPU. This saves CPU usage as well. This is the CPU usage for switching frames at 1 Gbps between two interfaces without bridge offloading:

However, bridge offloading is only useful for switching frames between LAN ports (what makes a LAN port is completely up to us). We usually need to route wan traffic so we need to have the CPU involved, in other words, have those packets delivered locally.

4 Likes

Looks like all issues are fixed for mt76. Compile your packages on the 22.03-SNAPSHOT branch

Command line (copy packages paste in server and download image build)
opkg list-installed | awk -F' - ' '{printf $1 " "}'

Server
https://asu.aparcar.org/

I have a WRT1900ACSv2 running OpenWrt 22.03.0-rc4 with a few configuration optimizations, and honestly I am extremely pleased with this build's performance! Thank you developers! Other builds have felt tenuous at best, but I feel like I've finally struck gold. Looking forward to the continued refinement with future RCs. Well done.

2 Likes

Please, have a look here: AQL and the ath10k is *lovely* - #565 by amteza

I'm having a peculiar problem with 22.03.0-rc4. I installed it on a My Book Live Duo (apm821xx), no configuration changes except setting the lan interface to dhcp and disabling dnsmasq/odhcpd and firewall.

Super-short overview over my network:

Main router (x86) ---+--- My Book Live (apm821xx)
                     |
                     +--- Access Point (mt7621) ---(wifi)--- Wireless clients

(main router and AP are running OpenWrt 21.02.something)

When I connect from wireless clients in my network, the MBL throttles and ultimately refuses ssh connections.

Immediately after system startup, ssh is possible, but very soon the ssh connection is throttled and ultimately times out, any further ssh connection attempts fail. The logfile shows nothing, not even the subsequent connection attempts.

It is not a client OS problem, I tried Windows, Linux (Debian) and Android on the wireless side. It is only SSH though, LuCI/http access works fine. And it is only ssh connection attempts going through the access point, ssh connections from the main router or from machines connected to the main router via VPN (wireguard) work, and continue to work even once SSH from wifi clients stops working.

What could be the reason for this behaviour? Are ssh connections coming through the access point accidentally triggering some sort of security measure?

Sidenote: There seems to be something off in the default packages selection. Being a single-port NAS, it should not have wpad/hostapd packages, but the downloadable image contains both hostapd-common and wpad-basic-wolfssl, and the system has them running. Are they pulled in by some meta package, luci perhaps?

On my Archer C60v2 the CTRL-EVENT-BEACON-LOSS issue seems to be solved. It was there since 19.07.
The only annoying problem with 22.03 since RC1 is that 2.4 GHz scanning doesn't work anymore. On 5GHz I have no problems both with scanning and channel analysis, but with 2.4 GHz they don't work. I had no problems with 21.02.

Haven't tested the TD-W8970 build myself yet but this seems like a serious problem.
IMHO the best long-term solution would be to save maximal storage space to allow Extroot/Overlay storage expansion via USB flashdisk(today everyone has some).
I would really appreciate devs effort to save internal storage space, maybe create a firmware version completely without xDSL firmware blob.
That way anyone could upload xDSL blob firmware of his choice (even have more of them available for testing).

Good idea, if not for anything else it frees a bit of additional space. But it's not helping as much as one would think. A quick test shows that this would free up only around 550 kB. On 22.03 that might give juuuuust enough space to upload one firmware binary into the uncompressed filesystem -- certainly not two. On snapshot (i.e., OpenWrt's next version) it is cutting it darn close and might not even free enough space to upload one and leave enough space for the router to function properly.

The best way still stands: Need custom firmware binary with 8MB flash - use imagebuilder to put it into compressed squashfs.

Realistically, Lantiq devices with 8MB flash are pretty much on life support going into the future.

I hope for some more life time for devices with USB ports :slight_smile:
We just need a firmware where optional packages for USB storage can fit.
In critical situation I would prefer some system packages moved to optional (installed after Overlay).

I personally use USB Overlay filesystem for my device for about 5 years now.
Still on the same Sandisk UltraFit 16GB with 3 partitions (rootfs, swap, data) and don't experience any problems related to speed or reliability. DynDNS, Unbound and BanIP working.
Until I change my ISP to other technology, for DSL it's good and stable device with openwrt.
Unfortunately, don't know of any alternatives for it... :neutral_face:

Make one. And I'm not being snide: With the online imagebuilder-chef-thingy it's really easy to include the necessary packages into the compressed squashfs system. And then you're free to install everything else on your USB drive however you see fit.

But an official build including those packages? That would open up a can of worms where everyone and their wifi-enabled vacuum cleaner has their own idea of what should be included beyond the common base system. Didn't happen before, and I'd wager it will not happen in the future. I wouldn't hold my breath.

3 Likes

Thanks for suggestion. Found a builder https://firmware-selector.openwrt.org/, but my first try with removed xDSL blob-files was not successful. Will try again later.
I have no experience with building images but if the devs don't include a smaller standard image this could be my only option left.

It should be pretty simple, when customizing the list of to-be-installed packages, mark the respective packages as "not to be included" by prefixing a minus/dash:
-dsl-vrx200-firmware-xdsl-a -dsl-vrx200-firmware-xdsl-b-patch
(Full disclosure: I didn't try that with the online imagebuilder, I build my images locally and it works slightly differently.)

1 Like

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

Hi,

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.

Thanks.

Is it this arch?

https://downloads.openwrt.org/releases/22.03.0-rc4/packages/arm_cortex-a7_neon-vfpv4/base/r8152-firmware_20220411-1_arm_cortex-a7_neon-vfpv4.ipk

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?

EDIT:
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 8.8.8.8

And this is output on 22.03.0-rc4:

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

@hauke

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

2 Likes