OpenWrt 22.03.0-rc4 fourth release candidate

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.

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.

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

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

1 Like

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?

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

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.

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 may also save a bit of processing power but don't quote me on that.

However, this 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.

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