Wifi interface attached to vlan tagged bridge

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.

So i create multiple ssids like this:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:00.0'
        option htmode 'VHT80'
        option disabled '0'

config wifi-iface 'ssid1_radio0'
        option device 'radio0'
        option network 'vpn'
        option mode 'ap'
        option ssid 'ssid1'
        option encryption 'none'

config wifi-iface 'ssid2_radio0'
        option device 'radio0'
        option network 'vpn'
        option mode 'ap'
        option ssid 'ssid2'
        option encryption 'none'

And config/network

config interface 'vpn'      
        option type 'bridge' 
        option ifname 'eth1' 

I end up with the 2 interfaces connected to the bridge:

root@gs-mgw1:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-vpn		7fff.9483c404e8b0	no		eth1

Now i'd like to put wlan0 and wlan0-1 into different vlans on that bridge but how?

From the code i read the whole vlan stuff is only ever run when there is wpa with 802.1x it seems.


You cannot add vlan tags on the wifi.
You can bridge the ssid to a vlan subinterface, like eth1.10


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.

1 Like

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
                echo bridge vlan add vid 201 dev $INTERFACE untagged | logger -t wifibridge
                bridge vlan add vid 201 dev $INTERFACE untagged
                echo bridge vlan add vid 202 dev $INTERFACE untagged | logger -t wifibridge
                bridge vlan add vid 202 dev $INTERFACE untagged

There is no guarantee that wlan0 will be assigned to the same ssid on every boot or network restart.

Now you see my problem.

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.

I have replied to that already.

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.

Use a different bridge for each VLAN.

1 Like

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.

Did you add the tap interface in the bridge and it didn't work?

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

So config in uci looks like this:

config wifi-iface 'radio0_ssid1'
       option device 'radio0'
       option network 'vpn'
       option mode 'ap'
       option ssid 'OpenWrt'
       option encryption 'none'
       option vid '201'

Define one interface, type bridge for each eth.x, then another one for eth.

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.


1 Like

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.

1 Like

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.

I'd want to see that there is a performance difference before saying that it ought to be done one way or the other.

With OpenVPN part of your use case, discussion of other CPU usage is of minor importance.

1 Like

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:

1 Like