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.
I know, “don’t shoot the messenger”…
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.
1 Like
22.03.2 is still available for my device, shouldn't it also be pulled then? If it also has the bug.
I'm not really comfortable upgrading to snapshot. What packages do I need at the minimum to get to an equal state as a normal install?
Luci. (likely "luci-ssl" )
Nothing else. There really isn't much magic in formal releases. Practically just the LuCI GUI is added to the releases.
1 Like
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. 
1 Like
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?
2 Likes
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.
1 Like
I know the bug related to kernel 5.10 causes the switch to forward traffic like a hub which kills throughput and exposes VLANs along with other issues. However, just for clarification, does this mean traffic which should be LAN only can end up leaving the WAN port (assuming the firewall doesn't catch it)?
Yes, all traffic going in to any port will be sent out to all other ports, including WAN, and vice versa. This means, firewall and router can be bypassed between devices located in the internal and external broadcast domain.
2 Likes
Thank you for the clarification. In that case, it's obviously a major security issue and not just a minor bandwidth inconvenience for some people who happen to notice. I'd like to request that the security implications of this bug be highlighted a bit better in the " Broken MV88E6176 switch" section of the release notes (and probably elsewhere). As it currently reads, a user could easily not grasp the severity of the situation.
1 Like
Possible scenarios: your internal devices will receive IPs from an external DHCP server, and vice versa. An external attacker could use arbitrary internal IPs and communicate with most of your internal devices, depending on your internal topology.
There was a different reply on the Github issue: https://github.com/openwrt/openwrt/issues/11077#issuecomment-1382838498
Well, it depends on the internal topology of your router. The bug is in the internal switch, if the device has e .g. an extra CPU WAN port not connected to that switch, that port will not be affected. There maybe devices with only one LAN and one WAN port, and those are still connected to an internal switch. Take a look at the device specs to check it out.
In the case of the 32X, it looks like everything is on the same switch, so would be the worst case scenario.
How can we go about properly conveying this info so affected users know their risk?
1 Like
See the diagram for the Turris Omnia
[Diagram]
There, it seems to be an internal performance issue only, if you don't use any internal VLANs to separate LAN segments.
![[Diagram]](https://openwrt.org/_detail/media/turris/turris_omnia_network_corrected.png?id=toh%3Aturris%3Aturris_omnia){kind=link}
Remove it from the website, so it can no longer be downloaded. I don't see the logic in keeping previous versions of 22.03 available and then not making this new release available. If the bug exists in all 22.03 versions.
For those who don't want to experiment with snapshots, is 21.02.5 then not a better alternative? Or perhaps going back to stock Linksys firmware. 
1 Like
Not necessarily a better alternative rather just an other alternative.
When we can expect a first RC for 23.x?
EDIT: In my case the device acts just as an AP for main and guest WiFi. The WAN port is connect to a trunk port of the main switch. Should I expect data leakage in this scenario?
When someone does the work, not sure how the moniker of a tagged branch makes things OK, or different than just running a snapshot image.
2 Likes