Hi,
i am trying to broadcast multiple wifi ssids and attaching those to a tagged bridge so that the wifi ssids end up in different vlans on the bridge. I am already transporting this bridge via a tap and openvpn to another site which already works.
I fail to find how to add a pvid/tag information while attaching a wifi interface to a bridge.
Only Ethernet ports have a concept of VLANs. A software bridge (interface of type bridge) or a wifi AP carries one network. Like @trendy showed, create a separate bridge for each VLAN network.
I am not talking about tagged wifi frames - I am pretty shure i understand das 802.1q is not defined on 802.11.
I was talking about a tagged bridge. Bridges have the concept of vlans so i can connect a Wifi to a tagged interface on a bridge.
The way to put the Wifi into a vlan into the tagged bridge would be:
bridge vlan add vid 202 dev wlan0 untagged
bridge vlan del vid 1 dev wlan0 untagged
Doing this puts wifi frames into the bridge with a 802.1q tag of 202.
This works manually as expected but how to i encode this into the OpenWrt config.
The point is that i want to carry all physical ports (and wifi ssids) away from the Device with an OpenVPN tunnel. So i connect all physical ports individually onto a single bridge into different vlans. Also i would like to put the different ssids into different vlans onto the very same bridge. So i end up with a bridge with vlans 101-10x for physical ports and 201-20x for the wifi ssids.
With this i am able to set up a single L2 openvpn tunnel to a central authority which has L2 control over all individual ethernet ports and wifi ssids on the device.
Its simple for the physical ports as i simply configure the switch to give me vlan tags and then add the switches master port (which containes tagged frames) onto the bridge.
Conceptiually this works as a net udev rule. The point is that i'd like to dump the vlan/vid into the wireless ssid config. I would be okay to fetch it by uci. The problem here is that in the udev event i have nothing which references the uci config bringing up this specific interface.
[ $DEVTYPE != "wlan" -o $ACTION != "add" ] && exit 0
bridge vlan del vid 1 dev $INTERFACE untagged
case "$INTERFACE" in
wlan0|wlan1)
echo bridge vlan add vid 201 dev $INTERFACE untagged | logger -t wifibridge
bridge vlan add vid 201 dev $INTERFACE untagged
;;
wlan0-1|wlan1-1)
echo bridge vlan add vid 202 dev $INTERFACE untagged | logger -t wifibridge
bridge vlan add vid 202 dev $INTERFACE untagged
;;
esac
So how do i get the information about the config in uci on a hotplug event? I am searching through code for netifd, ubus mac80211 etc and so far i see that once you do 802.1x there is vlan support for the wifi interfaces. But there is no way to assign a static bridge-vlan when running with no encryption.
Nope - that puts individual ssids into individual bridges. That doesnt solve my problem. I know how to do that.
I dont want that. I want ALL ssids and wlan interface in the SAME bridge - but tagged into different vlans. And i dont want to put them out on physical ports on THAT device. I have a tap device attached to the bridge and relay it via openvpn L2 tunnelling.
uci does not have a concept for that - Its not documented and when i have a look at the vlan related config options they are all related to dynamic vlans and only ever activated in hostap config when we have 802.1x and the like.
netifd does have code for changing the bridge vlan for a specific interface but i dont have a clue on how to funnel the information from uci to netifd. So my best idea was to "abuse" a hotplug event to change the bridge vlan config which is obviously a problem because of parallelism of setting up the interfaces.
And use like 8-10 openvpn instances to tunnel them - oh come on - thats broken. I'd rather drop all of uci stuff and place my own shell scripts to set up the wireless stuff.
I have hack which works but is IMHO broken as it needs to delay the hotplug event which is broken per se. So i put an option "vid" into the uci wireless section and then place this into hotplug/net
The problem is that the hotplug event comes before the ubus network.wireless status has been updated. So i delay by arbitrary 10 seconds. Then the status reflects the link between interface and uci section:
[ $DEVTYPE != "wlan" -o $ACTION != "add" ] && exit 0
sleep 10
sectionname=$(ubus call network.wireless status | /usr/bin/jsonfilter -e '@[*].interfaces[@.ifname="'$INTERFACE'"].section')
vid=$(uci get wireless.$sectionname.vid)
echo wlan iface $INTERFACE section $sectionname vid $vid | logger -t wifibridge
[ -n "$vid" ] && exit 0
bridge vlan del vid 1 dev $INTERFACE untagged
bridge vlan add vid $vid dev $INTERFACE untagged
For the ethernet its unnecessary because the DSA switch already presents a tagged interface which is perfectly sufficient to be attached to a bridge. Now i attach the wlan interfaces to the bridge aswell as described and then tunnel this bridge via a single tap interface and openvpn to a remote location.
Works now - Small delay on wifi up (10 Seconds per wifi interface) but i dont really care that much.
Put everything into an opkg ready to deploy now to the boxes.
VLANs within bridges may exist in the kernel but there's no support for it in UCI. The UCI way would be separate bridge per network, and tag each network into the trunked layer 2 VPN tunnel with tap0.N in each bridge.
Its a pity. Attaching bridges via tap interfaces and bridging packets in kernel through multiple bridges is a waste of CPU cycles just because userspace cant configure kernel space. At least we are not context switching per packet but passing the packet through multiple bridges and thus fibs with their lookups is just plain wrong. I guess one could even show in perftests that this has a serious impact, especially with these small embedded devices with their small caches.
The point is that netifd seems to have broad support in adding all kinds of interfaces to bridges and adding the pvid information. Only uci and whatever code is needed to parse and pass information to netifd seems incomplete.
Attaching a WiFi interface to a VLAN-aware bridge is being considered by the developers, but requires changes to netifd which have not been merged yet: