so many marvell chipsets affected by a switch problem, newer snapshots are available using kernel 5.15 which has a fix. so a stable update probably won't be in the works for a while unless they have a stable 23.0 release. just a fyi.
I no longer have my W32x, but root for the idea of a dedicated thread for this topic, as this discussion should not be flooding the generic release notes, or other device threads (as it currently is). Would really be helpful, if this thread gets now used as central collection and to point all people to this thread to continue any 22.03 issue discussion of the platform in a single central place.
@cornerstone or @tmomas Would you mind refining the thread headline into something more descriptive, to name version and devices, eg.:
„22.03.x: no release builds for Turris Omnia, Linksys WRT, ClearFog“
If this thread will be a central place to point people since there are a lot of mvebu users, then it sounds good. To summarize you have two main options:
Keep running 22.03.2 until later this year when 23.0x comes out. (Note with kernel 5.10 the switch essentially behaves as a hub but still functions.)
Move up to a Master snapshot where the switch is fixed with kernel 5.15, these are built almost daily. My wrt32x is currently running a snapshot with over 3-weeks uptime so I can confirm it's stable. New snapshots might even run slightly better since it's now built with GCC 12. (Note software flow offloading is broken on my snapshot, but this doesn't matter using SQM.)
Here are the packages I install via SSH right after a clean Master snapshot, it may help others:
Thanks @phinn ... useful recommendations and package installation recipe
I'd like to take a moment to insert the following reminder and/or notice for those not used to using snapshot builds... they are a moving target. Install all the packages you need right away, as it may not be possible to install packages at a later date (due to compatibility and kernel version changes among other things). In some cases, package installations may only be possible within a ~24h window from when you downloaded the snapshot from the OpenWrt site (sometimes it may be considerably more, but it depends on the package and also the work that has been done on the snapshots, so don't count on any future package installations). If you miss the window, you can upgrade to the newest snapshot.
I think the point is next stable 23.x (this year) in all likelihood being moved to kernel 5.15 where issue is resolved, baring the unlikely event of the fix being backported to 22.x.
Robimarko pointed out on IRC that the fix is too invasive to be backported to the 5.10 kernel. So there will definitely be no fix for 22.03.
I have backported 5.15 to 22.03, as I already needed a stable base for my Marvell EBU Cortex A72 hardware and only on 5.15 the hardware is fully supported. Was easy to backport Marvell EBU Cortex A9 as well then. But it's hacky and you need to keep up with the master kernel bumps.
Hello phinn, 22.03.2 works perfect on my WRT3200 ACM, Thanks for explaining Options, Ill stick with 22.03.2 and follow your advise, to wait for 23.0.x . Praying that in maybe upcomming 23.0.x versions the problems are fixed Cheers and a Happy new year everybody
Yes, but lots of us still ran kernel 5.10 even with the faulty switch (I had over 100 day uptime) and it worked fine, just let's say as a hub not a switch. I'd never go back to 5.10, but it's still an option if people are ok with 22.03.2 and don't want to move up to master snapshots yet for kernel 5.15.
Of course it is an option, but they should also be informed of what the consequences of the problem is.
“I don’t see anything then everything is working”, doesn’t really work on this bug.
What are you supposed to see? In best of cases the Lan LED workload?
Of course everything works, all connected devices gets all data in all of the available network.
It hasn’t really been that clearly information even in this forum about the issue. It mvebu simply was put put on hold and when 22.03.3 arrived people started asking why they don’t find their devices.
Exactly, but that includes WAN as well! So, if your WAN is some kind of shared media, where other people/customers are connected too, they can sniff some of your internal LAN traffic, and maybe even bypass your routers firewall and attack your internal devices. On my WAN, I get serveral ARP requests per second completely unrelated to my connection.
But people really doesn't seem to understand this when we say why this device was stopped for the 22.03 branch (ALL VERSIONS).
But generally many see wan connector as some exclusive isolated port since it is often separated from lan connectors with another color and name on the plastic router box. But in practical terms it is often only a port in the switch and all data traffic is VLAN controlled. And you can use what ever port you like for wan. This is just handled in switch config.
I won't shoot anybody
But one should make it clear, that using these devices can be a great security risk using 22.03.x, if they don't know exactly what they are doing.
I did flash my three WRT32X/WRT3200ACM with a custom snapshot image, even if they are connected to WAN via a VLAN trunk to my ZyXEL GS1900-24E, so there wouldn't be any leaks to WAN and vice versa, as long as local devices connected to the router itself are well behaved and not using wrong VLAN tags.
I just tried to update with snapshot build. Seemed to be OK but then I realised port forwarding from wan is not working. Firewall rules are listed OK..
Any idea?
Found it: Software flow offloading is not working. After disabling all is OK
But IPTV with igmpproxy show now constantly interrupts.
I have actually two of these my self that I am using for backup, secondary test routers and dev tools behind the operational ER4.
Anyway…
How do we “un-pull” something already built and released and already installed world wide?
The only meaningful thing we can do is to say “do not use anything from the 22.03 branch for mvebu family.”
The thing is that the world isn’t perfect and we can only go forward in one way or the other.
We are instead really glad that actually someone probably pretty much by pure luck and random chance actually got the feeling “hey, there is something wrong here” and started investigating.
Without that initiative no one would have found out, maybe in the future but who knows?
I wasn't used to running s snapshot either, in fact I had never done it before, but I didn't want to stay on a release that seems to have an issue. It was actually incredibly easy, download the snapshot, install and keep settings, and then install the extra packages over ssh.
Cheers and a Happy new year everybody
