I think I am missing a kernel module: 8021q ...
Hmm, there is not such package...
it is (should be) compiled in.
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_VLAN_8021Q=y
CONFIG_NET_ACT_VLAN=m
CONFIG_MACVLAN=m
does it also happen with bridge v a dev lan0 vid 11 untagged pvid ?
bridge v a dev lan0 vid 11 untagged pvid
RTNETLINK answers: Not supported
That commonly indicates some issue with a kernel config. Can you try a reboot and see if it works then?
Rebooted, no luck. I also unloaded br_netfilter that I use, but did not make a difference.
the error means that what iproute2 wants from the kernel is not providing. Something seems amiss.
What is the output of ubus -S call system board
This what I am seeing for target-arm_cortex-a9+vfpv3_musl_eabi in 18.06-SNAPSHOT:
CONFIG_BRIDGE_EBT_VLAN=m
# CONFIG_BRIDGE_VLAN_FILTERING is not set
CONFIG_VLAN_8021Q=y
# CONFIG_NET_ACT_VLAN is not set
CONFIG_MACVLAN=m
{
"kernel":"4.14.130",
"system":"ARMv7 Processor rev 1 (v7l)",
"model":"Turris Omnia",
"board_name":"armada-385-turris-omnia",
"release":
{
"distribution":"OpenWrt",
"version":"18.06-SNAPSHOT",
"revision":"r7803-5e771160b8",
"target":"mvebu\/cortexa9",
"description":"OpenWrt 18.06-SNAPSHOT r7803-5e771160b8"
}
}
Try the release instead of the snapshot, maybe something wrong with the latter.
The buildbots had some trouble around the time the last snapshot is dated.
and despite the odds run swconfig show just to be sure that DSA is really in play
swconfig show
-ash: swconfig: not found
not installed as expected when configured for DSA
I can get the same functionality by creating an interface for each port and AP and add them all to the guest zone, but then I end up with a dozen of IP ranges to manage.
I am gonna try master now: it crashes when using lanX.X notation, but it turned out I do not need that. I will try the bridge commands you provided.
And a device cannot get an IP address any more..
port vlan ids
lan0 1 Egress Untagged
11 PVID Egress Untagged
lan1 1 PVID Egress Untagged
lan2 1 PVID Egress Untagged
lan3 1 PVID Egress Untagged
lan4 1 PVID Egress Untagged
br-lan 1 PVID Egress Untagged
br-untrusted 1 Egress Untagged
11 PVID Egress Untagged
Well, one step further... is there a mismatch (br-name) n the commands or just a typo?
It was a typo. My last messages showed the setting applied to the right bridge.
| br-untrusted | 1 Egress Untagged |
|---|---|
| 11 PVID Egress Untagged |
What I want to achieve in the end is the functionality similar to below to isolate the ports.
- 0 5t (vid==11), 1 5t (vid==22), 2 5t (vid==33), and 3 5t (vid==44) in the same bridge br-untrusted
- Use kmod-br-netfilter and echo 1 > /sys/class/net/br-untrusted/bridge/nf_call_iptables to have the bridge invoke iptables
- DROP in INPUT/FORWARD in guest zone
As I said, this can all be done by creating an interface per a port/AP with its own IP range and adding them all to the same guest zone and I have already tested this, but the solution with a single interface is neater.
Try three bridges. The point of a bridge is that packets on one leg get sent to the others (either MAC-selected, or broadcast).
Or maybe I don't understand what you're trying to achieve here..
Four LAN ports in the same bridge/interface using the same IP range and the devices connected to those ports (one per port) cannot communicate with each other.
UPDATE: it can all be solved by creating one interface with a dedicated IP range per a port and adding them all to the same firewall zone. But that is a lot of IP ranges vs a single one for a non-DSA mode.
One benefit of VLAN filtering is a decluttered network landscape and easier administration.
For this node untag ports work as previously mentioned. Why not in this case is a bit difficult to discern.
That it is not working could be also owed to being Master in early stage, for whatever reason stable | snapshots missing something to begin with. I do not know to which extent Bridge filtering fits in but likely adding complexity, Without Brdige filtering and with VLAN filtering enabled any untag packet should not be able to enter a VLAN tagged port and thus isolate tagged ports.
Another point is whether DHCP is bound to particular iface that operates on a VLAN tagged port in which case clients on an untag port will not get an ip. If DHCP listens globally instead this should not be an issue.
Similar for the local DNS resolver.
There are plenty of options to play around with. Maybe reading what this user reports helps to getter a better grasp (never mind the context).