OpenWrt 22.03.0-rc4 fourth release candidate

Release and security announcements
#83

An intermediate bootloader would be installed into the kernel partition, merely chainloading the real (bigger) kernel from another place, this does not touch the OEM bootloader in any way and reinstalling the OEM firmware just takes the normal push-button tftp recovery route. This is one option, not the only one, not the easiest one to get working but probably the only one which could account for future kernel growth.

...and unless a fix gets commited soon, very soon, there is every reason to be realistic.

#84

Worked fine for default on a rpi4b. But back to the last stable release for my imagebuild. To many packages not ready for fw4 yet. I'll wait till 22.03.x is stable.

#85

It's worth pointing out these are release candidates - it's unlikely any major packages lacking fw4 support are going to gain it prior to release.

2 Likes
#86

meh i mean rc1 upnp was broken for me and it works now, you'd be surprised

1 Like
#87

I am little confused, I had the impression that the second CPU port eth1 was supposed to be back with 22.03 after it was dropped with DSA on 21.02.

But the wrt3200acm still only have eth0 with 22.03?

#88

You might be looking for this. The devs have used this page for many months for tracking packages updated to support nftables:

#89

DSA on upstream Linux kernel lacks using multiple CPU ports to control switch ports. There was a patch series circulating around which would make it possible to map a switch port to a certain CPU port but it wasn't found acceptable by the kernel maintainers. I don't know if there's any OpenWrt-specific effort to support it.

There was an effort to map a switch port to a CPU port on the go using iproute2, which we would no longer have to define bindings on the devicetree, but I don't know the current state of it.

#90

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.

#91

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
2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices
#92

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/

#93

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
#94

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

#95

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?

[SOLVED] SSH over wifi stops working on RT3200/E8450 with 22.03.0-rc6
#96

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.

#97

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).

#98

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.

#99

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:

#100

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
#101

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.

image
image1041×365 12.9 KB

#102

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