PVID is set on switch port. If it is set then the switch assigns incoming untagged packages with defined vid and removes vid from outgoing packages. In OpenWRT untagged means port wirh pvid (if a vid is set)
Sure. I just checked the wire to air extenders do not feature an option to vlan tagging but perhaps that is not necessary anyway as being an intermediary but then any dhcp/dns/firmware traffic of their own is to be dropped. Some other devices like the TV do not feature vlan tagging support either.
Whilst I am still going to test with that single client it does not seem a practical scenario.
Yes, but it can be resolved like this (VID 1 as an example):
Wifi Interface -(bridged, no tag whatsoever)-> eth0.1 -> Port 5 (tagged) -> other Switch Ports (tagged or untagged).
Edit: and external Wlan Acces Points just do the same (bridge ethX.1 -> Wifi Interface). Of course they have tu support Vlans and MultiSSID
They donāt need to support vlan tagging as long as they are connected to an untagged port or an wifi Interface that is bridged to the correct vlan, they still communicate only in the scope of this specific vlan and not beyond (on layer 2), they may communicate to client on other vlans over layer 3 if granted by routerās firewall
@protree connectivity got restored indeed once the clientās nic was set to tag vid 1.
Without a vid tag from the client there is no connectivity to a tagged lan port on the switch which is was I thought we were now talking about for testing isolation without firewall as proposed by @andre.
None of the clients in my network environment are able to send vid except those with a nic that support vlan.
From that perspective the deployment scenario with tagged ports other than the CPU does not look very practicable in a SOHO landscape with the way this chip appears to be working.
@andre the test turned out very curious with the OS firewall out of the way both ends that is.
Ran a tcpdump awhile on the tagged client and the clientsā MAC addresses displayed correctly.
traffic from client to tagged switch lan port got denied if the clientās packets were not carrying a vid whilst the other way around traffic from the router to client passed both ends regardless, at least icmp packages to be more precise.
That seems to be opposite of
Again, The switch chip adds the vid if set to untagged, setting all ports to tagged is NOT required for Isolation.
All switch chips I worked with had the exact same behaviour. Nothing special to TOs switch chip I thinkā¦
Edit: And in my SOHO setup my Personal devices are perfectly separated from my Home Server and Guest Devices through VLANs (+ bridges to diffrent SSIDs)
Right, I misread something from the proposed test bed.
Probably depends which kind of chips that are. Some of the enterprise grade chips, e.g. used in Cisco equipment, appear to feature advanced port (private VLAN) tuning with
Promiscuous port (P-Port) and Host port. Host port further divides in two types ā Isolated port (I-Port) and Community port (C-port)
Meaning without OS firewall there is no traffic possible between different vlan id?
That might be true, I just wanted to point out that the concept of tagged/untagged ports, pvid and vid in the way it is handeled by TO isnāt unique 
and that it is absolutely sufficient for SOHO from my point of view
IF my vlans werenāt connected to CPU, yes. But as my TO is my router and gateway to WAN they must be connected to CPU. And I think this is the point you misunderstand. If you set up a VLAN on switch chip that only uses Port 1&2 for example and a diffrent VLAN only on Port 3&4, too (or even on Port 1&2, too!) they would be perfectly separated without any firewall. But clients on those vlans couldnāt reach DHCP, DNS, etc on TO (and thereby had no WAN Access).
But as soon as you connect your VLANs to the CPU and assign an interface to it there is automatically a route generated between those VLANs (Layer 3), which needs to be denied through a firewall. Common setting is to deny forwarding between interfaces by default and then grant forwarding as needed.
Still, on the chip there would be no Layer 2 connection between those vlans (which you proofed by yourself because you could deny communication between your vlans through firewall, which wouldnāt be possible if there would be any Layer 2 Connection between those vlans)
3 Likes
All good, the response and input from all the participants is much appreciated and perhaps will assist others with vlan matters.
Only wish perhaps that the switch would support direct wlan port plugging.
Had a look at the next gen board designed by Compex which is void of any switch mentioningā¦
2 Likes
Nope, that you will never get for technical reasons. WLAN/WiFI has an awful lot of settings (secrets etc.) which are beyond a simple switch. To make it even more annoying they have no concept of VLANs (as in they donāt support VLAN tags, that is ignoring things like wds or nv2).
Therefore you will end up with an SSID represented by an virtual interface bridged to a VLAN.
Iād hazard a guess that the top left square chip (next to the copper ports) is a switch chip.
I canāt zoom in enough/the pic isnāt high-res enough to to read the chip markings but the location and wiring suggests the CPU links to the chip (likely 1x10G) and then the chip fans out to the 1G ports. (I guess the other 10G port of the CPU is for the SFP+/10BaseT port and is either or useable).
Could not get this to work. Connectivity via eth0.2 is just peachy but switching the iface to eth2.2 and connectivity ceases.
Actually, there seems no connectivity at all when port6 is tagged or untagged.