I have actually done this kind of setup and actually seems to work fine, at least with just two nodes I have and 4 VLANs. My concern is all about this topic is basically that this should be impossible to do and the solution is to encapsulate inside batman or vxlan (defining it manual or using mesh11sd system).
I'm really doing it bad, or, with actual OpenWrt 25.12 version with DSA support and a Mediatek wifi chipset that seems to accept plain VLANs I'm right. Is very possible that in the future I add a third node just for testing. Will I have issues then?
Also because is very probable that I test with manual VXLAN for curiosity, or if my actual setup is not right to set ir permanent, I think I should move the actual mesh being just a VLAN bridge port to be a interface with their own ips to be able to manage VXLAN right?
Yes you need either batman or vxlan. You could also do an other layer2 tunneling.
Vxlan is modern, easy to use. That's why it's used with the 80211smesh package from @bluewavenet
@bluewavenet usually asks how many mesh nodes you have because "normally" you would need this package because many wireless options on not be set before but only after the mesh interfaces are up, and this deamon ensures it. My 3 node mesh works with static mesh interfaces good enough at home.
Vxlan on its own can also be configured with uci.
@howl your main question is how to do vlans on 80211s correct?
Yes, my main idea is exactly what you have. I don't want to use mesh11sd for just 3 home routers, I prefer to manual tune them statically. Actually with the VLANs they work (just two nodes), that's why actually annoys me, is supposed to not work.
Several years back I remember one recommended setup was using a GRE tunnel but I was tried setting mesh directly as VLAN bridge port and the VLAN are going through.
The main question is if given setting up VLANs works but not reliable, or if it's supposed not to work.
Then also the question about VXLAN, I think it need IPs first, but with my actual setup the mesh as port the routers in mesh doesn't have any ip for it. I should set a interface for just the mesh connections to have an IP and then the VXLAN over?
Either use batman advanced which is kind of an hack between layer2 and layer3 and batman is vlan aware. Just attach the batman interface to the vlan bridge.
With vxlan or gre, as the both are a layer2 over layer3 protocol they need a working layer3 backbone network yes.
This can be done with IPv6 link local addresses too.
But as I see you situation I would say go with batman. Yes sometimes I also have funky issues with the 3 node setup but then I just do a reboot cycle and after 40 sek the AP are back
If you need help or hints on the batman config say so I can share mine
As @LilRedDog asked, is this a wireless 802.11s backhaul?
Or, do you have your nodes connected using ethernet?
Maybe you are using Batman, with its built in vlan tunneling?
I ask, because 802.11 wireless frames do not have the necessary fields to support vlans and if you have a genuine 802.11s wireless backhaul, it will not act as a vlan trunk without some form of tunnelling.
As @_bernd mentioned, commonly, wireless tunnelling is done using gre or vxlan. gre is a simple point to point tunnel. vxlan is a point to multi-point tunnel, more ideally fitted to a multi-node mesh.
Nodes are in a 802.11 mesh with no cable at all between them. The setup is just the mesh as a port in the vlan bridge with the vlans tagged. I'm actually planning to document the setup in the wiki but want to wait a little to see if any kind of issue appear.
I started exploring 802.11s in April for my wrtnova.sh project (https://github.com/LongQT-sea/wrtnova/blob/main/wrtnova.sh), and what I found matches what you described: an 802.11s netdev handles VLANs just like a normal Ethernet netdev (ethX, enoX, lan1, ...), so I implemented it in wrtnova.sh — tested on OpenWrt 23.05.6 through 25.12. Performance is better than VXLAN and batman-adv, at least on my MT7621 box.
Short Version
802.11s did not gain VLAN-aware mesh frames. People are putting 802.1Q on the Linux mesh interface. That can pass tags over a simple link; it is not protocol-level VLAN support and it is not reliable as a multi-hop trunk. For a real trunk, use an overlay, batman-adv or mesh11sd.
TheTL;DR Version (Extract from an internal BlueWave Technical Note)
You can put the mesh netdev in a VLAN-aware bridge.
eg phy1-mesh0.10
Linux will then add an 802.1Q tag on that netdev. A tcpdump on phy1-mesh0 can show 802.1Q. That is the kernel VLAN module tagging an Ethernet-like interface. It is not 802.11s “supporting VLANs”.
That is the same trick you can apply to almost any Linux interface. It is not a mesh protocol change.
Why it is not the same as “VLANs work on 802.11s”
One hop can look fine: tagged frames go A→B, tcpdump shows the tag, a local AP on VID 10 does not see VID 20.
Multi-hop HWMP does not parse the tag. The inner 802.1Q is just payload. Path selection, proxy (MPP), and broadcast/multicast flooding are VLAN-unaware.
Mesh proxying of Ethernet stations is by MAC, not by {MAC, VID}. Two clients on different VLANs with the same MAC, or the same client moving between VLANs, are undefined.
Broadcast/unknown-unicast is flooded across the MBSS. A tag in the payload does not give you per-VID flooding or isolation inside the mesh.
Encrypted SAE mesh + VLAN subinterfaces is driver-dependent. Some chipsets drop, reorder, or strip the tag; others pass it as opaque bytes.
So a two-node lab with phy1-mesh0.10 in a bridge can “work”. That does not mean 802.11s frames support VLANs.
What actually supports VLANs over an 802.11s radio
Layer
VLAN behaviour
802.11s / HWMP
No VID; MAC routing only
Linux mesh0.N / bridge-vlan
Tag on the local netdev only
batman-adv on top of 11s (mesh_fwding=0)
Real VLAN-aware bat0
VXLAN / GRETAP / similar over the mesh
Overlay carries 802.1Q (what mesh11sd uses)
In summary, if you only have single hop links, you might get away with it. But you cannot guarantee single hop.
HWMP will use a 2-hop path as soon as one pair is missing or expensive, for example if a node reboots and comes back on a weaker link.
Then the tag is forwarded as opaque payload by the middle node. Some drivers pass it; some do not. You get silent VLAN leaks or drops with no protocol error.
Practical conclusion
2 nodes: tagged mesh0.N can work.
>2 nodes, all mutually heard, static: often works until a path becomes 2 hops or a broadcast leaks.
>2 nodes you care about: treat native 802.1Q on the mesh iface as unsupported. Use VXLAN, mesh11sd or batman-adv.
If the goal is “one hop only”, that is a radio topology constraint, not a VLAN feature. The moment HWMP inserts an intermediate hop, the “it worked on two nodes” assumption is gone.
That's why I'm testing 3 nodes. Even I bought the third one just for testing this as with just two I have full coverage. If I don't arise any issue these days is because it works. Have to test making blinding "main" node with one of the other two and that node being only able to "see" the other node through the other one. This is a little difficult because even in the opposite side with little signal they still see each other, so I will try to play with power output.
You can fiddle around to try to make it resilient, but then something changes, possibly transient, say someone opens a door in your house. The nature of microwaves - suddenly you get two hops and your vlans leak.
Silly sounding, but actually quite likely scenario:
eg, nodes A, B and C in a straightish line.
B is your main router and is in the middle. It has one hop to A and one hop to C.
That nice stainless steel fridge door in the kitchen opens.
Suddenly, B has one hop to A and two hops to C (via A) - leaky vlans.
You got your beer and the door closes.
Vlan leaks stop until next beer.
Here using three MT7622, have to check making one node being able to see the main node only through the other one and not directly. About the performance is very probable because the overhead of plain VLANs is so much smaller.
I want the opossite to try Even more instead of using wireless connection in the testing devices is one device connected to the lan switch in the main and the other device on the lan switch in the cannot directly see the main node.
If I'm not mistaken that should make both devices to not see each other at all when 2 hops are done without testing errors because a device connected to any other? I think also about setting different wireless names for each node to ensure the test also with only wireless devices.
I have forced to do 2 HOPs and it seems to work. Tomorrow will do more test but basically What I have done is this:
Nodes: A - B - C
Manaully disconnecting C from A and A from C and being one device connected to A and another into C, so no direct connection between A and C without the need to physically block the signal between both nodes.
Pinging one device to another and ping is successful.
Even more instead of using wireless connection in the testing devices is one device connected to the lan switch in the main and the other device on the lan switch in the cannot directly see the main node.