To be clear, I meant the actual Linux interface called "lan", not the config section with the same name in "/etc/config/network".
You need to replace all occurences of "eth0" in "/etc/config/network" by "lan". If you start from a fresh config on a snapshot image, that should actually already be the case. (I assume you ended up with the current state by keeping your config from a stable release, which is not supported for devices which migrated to DSA.)
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 ula_prefix 'xxxxxxxxxxxxxxxxxxx'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config device
option name 'eth0'
option macaddr 'xxxxxxxxxxxxxxxxx'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
If I replace the 2 occurences of "eth0" by "lan" in that network file, and restart the network, I can't access the access point anymore (its IP address being 192.168.1.1).
So, which device and which OpenWrt version are you actually using? From the previous information, I assumed it is a DAP-2610 running an OpenWrt snapshot build (as there isn't any stable release using DSA for this device yet). And in that case, the device "lan" should be used for the LAN interface by default.
Your device only has a single Ethernet port. So dsa is not a thing here.
But as a result, VLANs are really easy. Just use dotted notation - eth0.x where x is the vlan id.
Want to link another vlan to an ssid? Simple. Make a bridge containing eth0.x and a network interface with that bridge and proto none (unmanaged). Then link the ssid to that network in your wireless file.
The network file would look like this:
config device
option name 'br-vlan10'
option type 'bridge'
list ports 'eth0.10'
config interface 'vlan10'
option device 'br-vlan10'
option proto 'none'
Dunno about this particular device but some, at least the Asus Lyra didn’t come with a working switch config out of the box on 22.03 (not that it wasnt working, the switch config just didnt show up on Luci).
But as @psherman mentioned you don’t really need that. You can either use software vlan or just use the bridge vlan filtering as you would on a DSA device.
While this device has just one port, that port is still connected to the switch that is built into the SoC. The device tree confirms this. So DSA (or swconfig in the stable release) is very much relevant here.
It that's the case (and I totally admit that I may have missed the device tree and the internal switch), bridge-vlan filtering would be the way to go here (instead of the dotted notation).
The upstream router is properly configured. It serves as a gateway and DHCP server for VLAN 114 on another tagged port, and everything works fine for the computers and managed switches connected downstream which rely on that VLAN.
Here's the network. I simplify, both the router and switches hosting several subnets.
Great. We should be able to eliminate that as part of the issue (you'd be amazed how many times it is an upstream misconfiguration that is the actual culprit).
To exclude any problem related to the ethernet cables and keystones jacks of my rack, I plugged the AP on the port of my upstream router where I do the tests related to that VLAN configuration. I set the IP adress of the AP : 192.168.114.102. I set the port of the upstream router as untagged. I can access the AP at its adress (192.168.114.102). So, the ethernet cable and the keystone jack are OK. For the rest of the tests, I'll set the port of the upstream router as tagged for VLAN 114, and everything else as off for that port.
I was ready to test, but I the recipe, as I understand it, is to use VLAN 114 for WLAN (guest or IOT network). For my tests, I try to define the management IP adress of the router on VLAN 114. I'll look at the other VLANs later. I want everything to be tagged on the unique ethernet port of the AP.
I had made the assumption, possibly incorrectly, that VLAN114 would be for the guest/IoT network, and would not be used for managing your infrastructure devices.
Usually, a dumb AP only has an address on the management netowrk, and the other network(s) are transparently bridged with no address.
I did notice one possible mistake in my recipe, but before I bother to try to fix it, maybe it is best for you to answer the following:
What VLANs will be on the eth0 port?
What is the arrangment of each of the VLANs (for example: VLAN 1 untagged + VLAN 114 tagged, or VLAN 1 tagged + VLAN 114 tagged, etc.)
What is the function of each network (i.e. VLAN 1 for management, no wifi; VLAN 114 for wifi only; or maybe both with wifi but VLAN 1 for managemnet, etc.)
