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.
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.
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?
See the diagram for the Turris Omnia
There, it seems to be an internal performance issue only, if you don't use any internal VLANs to separate LAN segments.
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.
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.
Unknown. The last couple years were 21.02 and 23.03. The number after decimal means the month, so maybe this March for the first RC.
As I said above though, Master snapshot builds on kernel 5.15 are stable and the switch is fixed for me though so I consider it resolved.
There seems to be conflicting information regarding this. Some say it won't leak. Some say it will. Some say it depends on if the WAN is connected to the switch directly or if it's a port on the CPU. I would love to get a firm answer as the security implications are huge.
Let's assume that everyone is using private IP addresses internally, that their router behaves correctly, or that some router on the hops outbound behave correctly. It would seem that this so called leakage should be quickly squashed, and the misrouted IP packets will be quickly routed.
Regardless, this seems like much ado about nothing. The issue is resolved and easily rectified.
The other benefit of installing a snapshot is surely that if fixes 7 or 8 CVEs which are fixed in the latest official release
I have now switched to a AVM Fritzbox 4040 with 22.03.03. Got everything working.
For the WRT3200ACM I see, despite the snapshot installation, as best option:
Get a USB network adapter for wan. This way the hub behaviour should not affect public side.
After a few days of careful planning, I have upgraded my WRT3200 to the current master snapshot build with kernel 5.15.x today.
So far everything is working fantastic.
My plan going forward is to use
luci-app-attended sysupgrade to upgrade from snapshot to snapshot every couple of weeks or so. That way it will be a smoother process overall while keeping my packages installed each time.
Yep that's my plan as well, just do a snapshot sysupgrade like once a month or if I see an interesting commit hit the branch. 24 day uptime on my wrt32x so far, master snapshot w/kernel 5.15. All is good.
Likewise, but with perhaps less diligent planning, I have upgraded my WRT1900ACSV2 to the master snapshot (r21807) build with my retained configuration. So far so good. Updated my packages accordingly.
Edit: scratch that I'm having some difficulties on the master with pinging devices also on the network and network discovery. (ie Home Assistant seeing google speaker/hub devices, etc.) Not sure what changed.