Connecting WiFi network to a tagged VLAN, using DSA

Installing and Using OpenWrt
1

I'm setting up a device using DSA for the first time, and had to configure it in a way I did not expect. I have the router and access point functionality split between two devices, the device with config issues was the AP. My setup is something like this.

  • There is a single cable connected to the WAN port, with mulitple tagged VLANs.
  • There is one bridge device configured, "mainbridge"
  • There is one network interface configured, "yellow"
  • There is one WiFi SSID.
  • I want the WiFi SSID to be connected to VLAN 20 on the WAN port.

Attempt 1:
On the bridge, under "Bridge VLAN filtering", I have VLAN 20 configured, set to "tagged" on wan. The option "Local" is unchecked, because I don't need the device itself to be connected to this network. Under interface "yellow", it was set to device "wan.20" (it was the only suggestion having .20 in it's name).
This did not work, any traffic coming over WiFi was not sent out on the WAN port of the device.

Attempt 2:
On the bridge, I checked the option "Local". On the interface "yellow", I changed it from "wan.20" to "mainbridge.20". The protocol is still set to "unmanaged", the device itself has no IP in VLAN 20.
But this worked, any incoming WiFi traffic is now sent out on the WAN port on VLAN 20. Why is the option "Local" needed for this use case?

2

Let's take a look at your config -- things will probably be more clear once we can see it in full.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
3

Bug and workaround here

4

That bug may not apply... let's see the config first.

1 Like
5

It is in the thread title imo, at least ip-bridge is of help finding wrong connectivity hidden from brctl

6

My point is simply that we should look at the config first. After all, we don't yet know:

  • What version of OpenWrt is being used
  • What device/platform is relevant here
  • How the OP has configured the device in general (including bridge-VLANs and the like).

It is highly possible that the bug will not be relevant and that the issue is related to a misconfiguratoin. If the configuration turns out to be completely correct, maybe the bug applies.

1 Like
7

Sorry, I forgot to say that I am infact using 24.10.0. On the box the device came in it says ASUS RT-AX1800U, it's this https://openwrt.org/toh/asus/rt-ax53u

Hostname OpenWrt-AP1
Model ASUS RT-AX53U
Architecture MediaTek MT7621 ver:1 eco:3
Target Platform ramips/mt7621
Firmware Version OpenWrt 24.10.0 r28427-6df0e3d02a / LuCI openwrt-24.10 branch 25.044.01357~67d27ad

I went back and reproduced the issue, relevant parts of the config below. I found that selecting "Local" does not matter, what triggers the issue is whether I choose "mainbridge.20" or "wan.20" (top line in /etc/config/network). It needs to be "mainbridge.20" to work. Is it expected behavior that you can't have a physical port connected to both a bridge and directly to a interface, as I have done here?

[etc/config/network]

config interface 'yellow'
	option device 'wan.20'
	option proto 'none'
	option delegate '0'
	option defaultroute '0'

config interface 'anotherWiFiInterface'
	option proto 'static'
	option device 'mainbridge.200'
	option ipaddr '10.0.200.2'
	option netmask '255.255.255.0'
	option gateway '10.0.200.1'
	option type 'bridge'
	option delegate '0'
	option defaultroute '0'

config interface 'gt'
	option proto 'gretap'
	option force_link '1'
	option peeraddr '10.0.200.7'
	option ipaddr '10.0.200.2'
	option tunlink 'anotherWiFi'
	option df '0'
	option network 'gti'

config device
	option type 'bridge'
	option name 'mainbridge'
	option bridge_empty '1'
	option stp '1'
	option ipv6 '0'
	list ports 'lan1'
	list ports 'wan'
	list ports 'gre4t-gt'

config interface 'gti'
	option proto 'none'
	option defaultroute '0'
	option delegate '0'
	option device 'mainbridge'

config bridge-vlan
	option device 'mainbridge'
	option vlan '20'
	list ports 'wan:t'
	option local '0'

[/etc/config/wireles]

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
	option channel '36'
	option band '5g'
	option htmode 'VHT20'
	option cell_density '0'
	option country 'myCountry'

config wifi-iface 'wifinet5'
	option device 'radio1'
	option mode 'ap'
	option encryption 'sae-mixed'
	option key 'supersecretpassword'
	option wpa_disable_eapol_key_retries '1'
	option network 'yellow'
	option ssid 'yellowWiFi'
	option disabled '1'

	config wifi-iface 'wifinet6'
	option device 'radio1'
	option mode 'ap'
	option ssid 'anotherWiFi'
	option encryption 'sae'
	option key 'supersecretpassword'
	option ocv '0'
	option network 'anotherWiFiInterface'
	option disassoc_low_ack '0'

As you see, the bridge is also connected to a GRETAP interface, where SSID anotherWiFi is used as a trunk to transport Ethernet frames with VLAN tag to another access point (AP2, that is in client mode). On that end there was a PC wired to AP2, the PC had internet access the whole time. The issues described was with clients in AP1, which I got the config from.

8

There are multiple issues here.

I'd recommend not using the GRETAP for now until we can sort out the rest. You can try adding that in again once things are working in general.

Is the network config file you shared complete or are there more parts to it?

9

I tried sparing you what is not relevant. The only parts missing are other VLANs connected to other SSIDs. Each SSID is connected to one interface, each interface is connected to mainbridge.10, mainbridge.30 etc.

If you look at the first line in my example and change wan.20 to mainbridge.20, that show you the method all the other WiFi SSIDs are configured.

10

Please go ahead and post the complete network config file. There may be important parts that are necessary to properly fix the config.

11

/etc/config/network, at the point where I had changed it to reproduce the problem.
Interface names are redacted.

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option packet_steering '1'
	option ula_prefix 'fda0:882c:296f::/48'

config interface 'ZoneForVLAN10'
	option proto 'static'
	option netmask '255.255.255.0'
	option gateway '10.0.10.1'
	option device 'mainbridge.10'
	option ipaddr '10.0.10.2'
	list dns '10.0.101.100'
	list dns '10.0.40.160'
	option delegate '0'

config interface 'ZoneForVLAN14'
	option proto 'none'
	option device 'mainbridge.14'
	option delegate '0'
	option defaultroute '0'

config interface 'ZoneForVLAN20'
	option device 'wan.20' [SETTING THIS TO mainbridge.20 SOLVES THE PROBLEM]
	option proto 'none'
	option delegate '0'
	option defaultroute '0'

config interface 'ZoneForVLAN31_WiFi'
	option proto 'none'
	option device 'mainbridge.31'
	option delegate '0'
	option defaultroute '0'
	option type 'bridge'

config interface 'ZoneForVLAN11'
	option proto 'static'
	option netmask '255.255.255.0'
	option device 'mainbridge.11'
	option gateway '10.0.11.1'
	option ipaddr '10.0.11.2'

config interface 'ZoneForVLAN41'
	option proto 'none'
	option device 'mainbridge.41'
	option defaultroute '0'
	option delegate '0'

config interface 'ZoneForVLAN30'
	option proto 'none'
	option device 'mainbridge.30'
	option defaultroute '0'
	option delegate '0'

config interface 'ZoneForVLAN200'
	option proto 'static'
	option device 'mainbridge.200'
	option ipaddr '10.0.200.2'
	option netmask '255.255.255.0'
	option gateway '10.0.200.1'
	option type 'bridge'
	option delegate '0'
	option defaultroute '0'

config interface 'gt'
	option proto 'gretap'
	option force_link '1'
	option peeraddr '10.0.200.7'
	option ipaddr '10.0.200.2'
	option tunlink 'ZoneForVLAN200'
	option df '0'
	option network 'gti'

config device
	option type 'bridge'
	option name 'mainbridge'
	option bridge_empty '1'
	option stp '1'
	option ipv6 '0'
	list ports 'lan1'
	list ports 'wan'
	list ports 'gre4t-gt'

config interface 'gti'
	option proto 'none'
	option defaultroute '0'
	option delegate '0'
	option device 'mainbridge'

config bridge-vlan
	option device 'mainbridge'
	option vlan '10'
	list ports 'gre4t-gt:t'
	list ports 'wan:t'

config bridge-vlan
	option device 'mainbridge'
	option vlan '11'
	list ports 'wan:t'

config bridge-vlan
	option device 'mainbridge'
	option vlan '14'
	list ports 'wan:t'

config bridge-vlan
	option device 'mainbridge'
	option vlan '20'
	list ports 'wan:t'
	option local '0'

config bridge-vlan
	option device 'mainbridge'
	option vlan '30'
	list ports 'lan1'
	list ports 'wan:t'

config bridge-vlan
	option device 'mainbridge'
	option vlan '31'
	list ports 'wan:t'

config bridge-vlan
	option device 'mainbridge'
	option vlan '41'
	list ports 'wan:t'

config bridge-vlan
	option device 'mainbridge'
	option vlan '200'
	list ports 'wan:t'
12

Am I correct that you have indeed resolved the issue based on the comment below:

If so, that makes perfect sense. With DSA and bridge-vlans, a port must only be used in one place... in this case, you've already got it in the mainbridge, so it cannot be resused elsewhere. Instead, you use a bridge-vlan to setup the appropriate VLAN and use that device.

With that in mind, are there any remaining issues?

13

No, there are no other issues on my setup now. As I wrote in the very first post, it works when I changed it from wan.20 to mainbridge.20. I thought the setting "Local" was part of it, but in the reality, the cause was as you say.

BUT, when I had unchecked "Local" for that VLAN on the bridge, and I then configured the interface and was asked to set the device, the suggestion for the device was "wan.20" instead of "mainbridge.20". Why is LuCI suggesting wan.20 here when it will only work with mainbridge.20?

14

I don't know how or why LuCI suggested that... I don't typically use LuCI, and your environment does look a bit out of the ordinary.

But glad it is working now.

15

Ethernet to Ethernet can be handled entirely in the switch hardware, but bridging Ethernet to wifi requires the kernel to set up a software bridge. This involves the connection from the switch chip to the CPU (though these are sometimes two modules on the same chip). Checking the "local" box enables this connection. It is another port of the switch that doesn't have a name in the configuration.

This communication is at layer 2-- based on MAC addresses which require no configuration. "Unmanaged" or proto none means there is no IP address, which is a layer 3 feature.