This issue finally broke my trust in TO.
I upgraded to most recent TOS5 last week, and tried since to get my VLAN configuration running again.
Actually nothing fancy - just 3 different VLANs on the LAN4 interface bridged to different other LAN and WLAN ports. Worked flawlessly with TOS3, fails miserably on TOS5.
I followed this and several other threads here and learned several things:
- With the switch to DSA a lot changed - and broke.
- There are basically two ways to make VLANs work again: Use the supposedly still valid TOS3 approach, where tagging is handled by the kernel (run through CPU) or use the new DSA stuff, handling tagging withing the switch.
- The latter requires some in-depth DSA knowledge and CLI commands. This approach must be considered highly unssupported, because it is not documented anywhere (except whats contained here in some threads), not supported by LuCI and it remains unclear how to persist all that. Not to mention how this will behave on future upgrades. No option for me.
- The old TOS3 approach with just using LANx.y interfaces would be a feasible approach - for me. I would happily accept the extra CPU cycles for the tagging overhead, for a simple and working solution, even configurable via LuCI. However, this turned out to be a deadend also. Although this way is actually documented, it really doesn’t work due to several ARP issues (described here among other places).
After all that hassle, I desperately reverted back to TOS3. I’m not very confident, that CZ.NIC will eventually resolve this issue. It is already known for so long, but nothing moves.
Actually a pitty. I’d so much hope for TO when backing this project in the very first Indiegogo campaign.
Currently, I can’t recommend this device to anybody.
And sorry for this non-productive post, but I had a strong desire to give some feedback from a user’s view.