Question setting different VLANS to different radios on DSA

I'm trying to understand VLANs under OpenWRT with the goal of splitting APs between 2 VLANS. One of the radios will go on one VLAN (the private network) the other will go on the other VLAN (the public network)

The VLANS are presented to the APs on a single physical interface, as tagged and untagged, the untagged goes to the VLAN I want to use to manage the AP. (so that I can factory reset the AP such as during a firmware update then connect to it at 192.168.1.1) None of the AP's is setup as a router, all are setup as APs.

It APPEARS to me that the way to do this is leave the first bridged interface connected to the hardware port getting untagged packets alone, create a second bridged device, create a virtual hardware ethernet interface on the public VLAN (101) , tie the second bridged device to the virtual hardware interface on VLAN 101, then disconnect the radio I want to put on the public network from the first bridge and connect it to the second bridge.

It does not seem possible to tie the radio interface directly to the hardware interface, (luci doesen't allow it) but this must be done with a second bridge. Is this correct?

I've read through the instructions on https://openwrt.org/docs/guide-user/network/vlan/switch_configuration but it seems mostly concerned with swconfig setups. Possibly because most AP hardware is still running swconfig?

It also says nothing about using Luci - probably because when it was written Luci couldn't do this? I'm fine with configuring things at the command line, and I assume Luci will read the reconfigured /etc/config/network and I can figure out
how to do this with Luci later, if I want.

In my case I have the following AP on the following switch (these are all testing devices):

Netgear WNDR3700 running OpenWRT 24.10.3 on a Catalyst C3560. This AP uses swconfig on this OpenWRT version.
The switch port the AP is on is configured thusly:

!
interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 101
 switchport mode trunk
!

The Catalyst switch presents 192.168.0.0/16 to the AP as untagged, and it presents 172.16.16.0/24 as tagged with VLAN id 101. the only physical port plugged into the AP is port1 on the LAN ports, the WAN port is not used.

Unfortunately, while the documentation for this AP concerning VLANS is extensive, here:
https://openwrt.org/toh/netgear/wndr3700#specific_configuration

it appears to be VERY old since for example, /etc/config/network does NOT match what the docs display. In the docs it talks about device rtl8366s while currently I'm seeing "device switch0"

ANYWAY what I THINK I just need to do is add the following to /etc/config/network

config device
        option name 'br-lan101'
        option type 'bridge'
        list ports 'eth0.101'

config device
        option name 'eth0.101'

config interface 'lan-101'
        option device 'br-lan101'

Then modify the /etc/config/wireless file to change the

option network

from 'lan' to 'lan101'

What I am confused about, however, is do I need to add

option enable_vlan '101'

to the option device that defines eth0.101?

And, do I need to add a made-up MAC address with

option macaddr '00:00:0b:ad:be:ef'

to the interface for lan-101? I don't want to assign an IP address to it.

Now, this is all swconfig stuff. I ALSO have a Meraki MR52 running OpenWRT 24.10.3 on a Cisco Catalyst C2960X. This AP uses DSA on this OpenWRT version.
The switch port the AP is on is configured thus:
!

interface GigabitEthernet1/0/20
 switchport trunk native vlan 201
 switchport mode trunk

The switch presents 172.16.201.0/24 to the AP as Untagged, and it presents 192.168.0.0/16 as VLAN id 101, tagged.

The MR52 is running OpenWRT 24.10.3 and it's lan interface is 172.16.201.254

it's /etc/config/wireless file ties

config wifi-iface 'default_radio0'
        option network 'lan'

config wifi-iface 'default_radio1'
        option network 'lan'

config wifi-iface 'default_radio2'
        option network 'lan'

and it's considerably simpler /etc/config/network just defines lan as a bridge br-lan here:

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '172.16.201.254'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '172.16.201.1'

Once more, am I correct in assuming all I need to do is add the following to /etc/config/network

config bridge-vlan 'eth0_vlan'
        option device 'br-lan'
        option vlan '101'
        list ports 'eth0:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '101'
        list ports 'eth0:t'

config interface 'publiclan'
        option device 'br-lan.101'
        option proto 'none'

then modify /etc/config/wireless to change the option network from lan to publiclan?

00:00:0B Matrix Corporation

You may not privately assign assigned OUI.

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, VPN keys, 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

Wireless devices have no concept of VLANs so each VLAN you want to access wirelessly will require it’s own SSID. This guide might help you sort out how to get it done. :wink: Good luck!

I very strongly object to the use of 'bots such as the above to respond to advanced questions on this forum. I tried to make this point kindly - with humor - and was rebuffed - so I will now make it firmly:

  1. Immediate responses from 'bots like the above make it appear the question has been answered when it has not been.
  2. Advanced questions are typically long and include relevant details. 'bots cannot understand them and therefore end up requesting details such as information that was already provided, (such as the make/model of device) or information that is irrelevant (such as firewalls which do not apply to AP-only devices)
  3. 'bots cannot understand advanced questions nor determine whether information supplied is a security risk or not.
  4. 'bot responses to complex questions imply the OP did not rtfm. As the complexity of the question increases the chances the OP did not read official documentation already goes down.

If the forum moderators MUST use 'bots then the following good practices need to be in force:

  1. Language in a 'bot post must NEVER command, only REQUEST. Language such as "please connect to your device and [insert directive]" must be modified to say "it would help people to help you if you could supply [insert following]" This can be done by connecting to your device and [insert instructions]
  2. A 'bot post must always identify itself as an automated 'bot post. This is standard practice on forums such as reddit.
  3. A 'bot must NEVER "censor" due to anything other than defined static criteria (such as, lists of bad words, dirty picture images, spam, etc.)

The following information is for the Meraki MR52:

root@OpenWrt:~# cat /etc/config/firewall
config defaults
        option syn_flood        1
        option input            REJECT
        option output           ACCEPT
        option forward          REJECT
# Uncomment this line to disable ipv6 rules
#       option disable_ipv6     1

config zone
        option name             lan
        list   network          'lan'
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT

config zone
        option name             wan
        list   network          'wan'
        list   network          'wan6'
        option input            REJECT
        option output           ACCEPT
        option forward          REJECT
        option masq             1
        option mtu_fix          1

config forwarding
        option src              lan
        option dest             wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
        option name             Allow-DHCP-Renew
        option src              wan
        option proto            udp
        option dest_port        68
        option target           ACCEPT
        option family           ipv4

# Allow IPv4 ping
config rule
        option name             Allow-Ping
        option src              wan
        option proto            icmp
        option icmp_type        echo-request
        option family           ipv4
        option target           ACCEPT

config rule
        option name             Allow-IGMP
        option src              wan
        option proto            igmp
        option family           ipv4
        option target           ACCEPT

# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
        option name             Allow-DHCPv6
        option src              wan
        option proto            udp
        option dest_port        546
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-MLD
        option src              wan
        option proto            icmp
        option src_ip           fe80::/10
        list icmp_type          '130/0'
        list icmp_type          '131/0'
        list icmp_type          '132/0'
        list icmp_type          '143/0'
        option family           ipv6
        option target           ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Input
        option src              wan
        option proto    icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        list icmp_type          router-solicitation
        list icmp_type          neighbour-solicitation
        list icmp_type          router-advertisement
        list icmp_type          neighbour-advertisement
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Forward
        option src              wan
        option dest             *
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-IPSec-ESP
        option src              wan
        option dest             lan
        option proto            esp
        option target           ACCEPT

config rule
        option name             Allow-ISAKMP
        option src              wan
        option dest             lan
        option dest_port        500
        option proto            udp
        option target           ACCEPT


### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option dest             wan
#       option proto    tcp
#       option target   REJECT

# block a specific mac on wan
#config rule
#       option dest             wan
#       option src_mac  00:11:22:33:44:66
#       option target   REJECT

# block incoming ICMP traffic on a zone
#config rule
#       option src              lan
#       option proto    ICMP
#       option target   DROP

# port redirect port coming in on wan to lan
#config redirect
#       option src                      wan
#       option src_dport        80
#       option dest                     lan
#       option dest_ip          192.168.16.235
#       option dest_port        80
#       option proto            tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#       option src              wan
#       option src_dport        22001
#       option dest             lan
#       option dest_port        22
#       option proto            tcp

### FULL CONFIG SECTIONS
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port 80
#       option dest             wan
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp
#       option target   REJECT

#config redirect
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port         1024
#       option src_dport        80
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'
        option filter_aaaa '0'
        option filter_a '0'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ignore '1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

root@OpenWrt:~#

root@OpenWrt:~# ubus call system board
{
        "kernel": "6.6.104",
        "hostname": "OpenWrt",
        "system": "ARMv7 Processor rev 0 (v7l)",
        "model": "Meraki MR52",
        "board_name": "meraki,mr52",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.3",
                "revision": "r28872-daca7c049b",
                "target": "ipq806x/generic",
                "description": "OpenWrt 24.10.3 r28872-daca7c049b",
                "builddate": "1758316778"
        }
}
root@OpenWrt:~#

root@OpenWrt:~# cat /etc/config/network

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 'fd74:d4c8:cb18::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '172.16.201.254'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '172.16.201.1'

config interface 'wan'
        option device 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'

root@OpenWrt:~#
root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option band '5g'
        option channel '36'
        option htmode 'VHT80'
        option disabled '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option disabled '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'soc/1b900000.pci/pci0002:00/0002:00:00.0/0002:01:00.0'
        option band '2g'
        option channel '1'
        option country 'US'
        option cell_density '0'
        option htmode 'HT20'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'Test Bch'
        option encryption 'psk2'
        option key 'wayago'

config wifi-device 'radio2'
        option type 'mac80211'
        option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
        option band '5g'
        option channel '36'
        option htmode 'VHT160'
        option cell_density '0'
        option country 'US'

config wifi-iface 'default_radio2'
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option ssid 'Test but Better'
        option encryption 'psk-mixed'
        option key 'goaway'

root@OpenWrt:~#
root@OpenWrt:~#

Yes,I am fully aware of that which is why I stated in the OP:

"One of the radios will go on one VLAN (the private network) the other will go on the other VLAN (the public network)"

Note that the tutorial provided is doing it backwards - it's wanting to setup VLANs on the "inside" side of the OpenWRT device, and the OpenWRT device is a router, with multiple physical ports, NOT a dumb AP with ONE physical ports.

In my case I want to ACCESS multiple VLANS available on the LAN interface, one tagged, one untagged, and put one of those on one radio and one on the other. There is no WAN interface.

Virtually all tutorials out there on the Internut are old, most are NOT DSA (although this one is) are focused on the GUI and NOT on the config files that the GUI output is generated on.

And please assume your readers are not dumb enough that they can't use Google to find these tutorials.

But I do appreciate you are least skimming the question and spending the few minutes to google up "openwrt vlan"

I understand the frustration you might be experiencing. Taking out on volunteers who are trying to help you is not the way. At no point have I assumed you are dumb. You’re tackling a difficult issue and trying to learn. Those are not the hallmarks of dumb people.

Currently a lot of the OpenWRT sites are down. I was hoping to point you to the DSA VLAN documentation which has Luci, uci, and config file examples. It’s mighty hard to find until the site comes back up.

2 Likes

You are correct and I apologize I was mad at the autobot response not you (and frankly, am getting even madder at it because it first autobot responded saying I didn't post the required response, then deleted it's post, then censored the required response which I then uncensored. effing stupid nonsense that is messing with the forum and highly offputting IMHO)

I already read through all of the OpenWRT docs before the site went down. And it appears that it's the "front page" that's down as all the deep-links are still working (at least, for me) such as the ones in my post. I don't know what their problem is but this has happened with the front page multiple times recently. Price of success, I guess.

I stated in the OP that I didn't need luci examples. Virtually all complex luci tutorials in any case are written backwards anyway - the people writing them START with the actual command line files, modify them, then observe Luci output on a refresh, then screenshot that, and post it as a "tutorial" Obviously assuming anyone wanting to use the tutorial is scared to death of the command line. I find luci-only tutorials highly unhelpful that lack information about how the underlying command files are modified and wonder if the tutorial author truly understands what's going on under the hood or just stabbed around until getting lucky.

The only way to trial-and-error this one quickly is to take apart the AP, connect a serial console, then modify the config files and keep running service network reload, guessing on a new config each time, until you figure out what was going on inside the heads of the DSA authors. I really, really, wanted to avoid that. Otherwise, it's guess, apply, and if you lost control of the AP, reset. Then try again. I am really hoping someone has already done this and I don't have to spend half a day doing it.

While the case of a 5 physical port (1 wan 4 inside) router running OpenWRT with multiple inside untagged switch ports going to different VLANS created internally on the OpenWRT router might be the common use case for a router, for AP use only, it's completely not. At home, yes, I get it - El-Cheapo unmanaged switches plugged into a cheap consumer router = VLANs inside of the router. But when doing Access Point work - the common use case is VLANs are used to carry multiple networks to the AP over 1 physical wire, and the AP then ties the radios to whichever VLAN you want. The MR52 actually has THREE radios (one is a P.O.S. however but might be usable for iot stuff like your garden sprinkler system with wireless controllers) you can play with. Good stuff - if you can get over the hump of flashing the damn things, which requires a little soldering and a 3v serial cable. Still, better than an EPROM programmer which is what the next gen AX Meraki's require for flashing.

All right everyone,

I finally decided to drive all the way into the lab - ALL THE WAY - on a flipping holiday for gosh sake - and hammer this out. lol.

So here you have it - with both Luci and command-line explanations: (and a little humor added in and if you can't take it then that's your problem not mine)

Setup:

Cisco Catalyst 2960X running Cisco IOS version 15.2.whatever-is-current-we-don't-care

Note: Why do I use Cisco stuff like this? Because these are dirt cheap, and full blown enterprise switches and are rock solid and can do uptimes of many years plus you can SSH into them over like multiple hops. But you can substitute any managed switch you like that is VLAN-aware. Beware the new Cisco stuff though - some of it is subscription licensed and will turn off if you stop paying the extor..I mean subscription fee. Also beware some of the Netgear stuff - they have an intermediate level sort of managed switch that is very crude and lacks critical monitoring stuff although it might work. If you dislike Cisco with a passion (quite understandable) the HP Aruba stuff is also cheap and just as good.

VLAN: 101 - 192.168.0.0/16 - OutWithTheGarbage private network for all the unwashed masses to beat the snot out of with their phones and screw with each other on. Use at your Own Risk warnings on this. Bandwidth restricted upstream, obviously.

VLAN: 201 - 172.16.201.0/24 - DulocThePerfectPlace private network restricted to the Ivory Tower that is locked down and monitored within an inch of it's life where we kill crackers on sight. (and there's a lot more private networks with the Good Stuff behind this one) Unlimited bandwidth.

Single ethernet cable to Cisco/Meraki MR52 that has been flashed with OpenWRT 24.10.3. (and yes, it DID cost less than $20 bought from some poor slob who got tired of Cisco sticking it to him for the $250 yearly extor...support fee) This is a DSA setup.

Catalyst switch port configuration:

!
interface GigabitEthernet1/0/24
 description Uplink to Where The Big Powerful Routers with DHCP servers Live
 switchport trunk allowed vlan 101,201
 switchport mode trunk
!
interface GigabitEthernet1/0/20
 Description   Wifi AP # 8675309
 switchport trunk native vlan 201
 switchport mode trunk
 storm-control broadcast level 10.00 5.00
 storm-control multicast level 40.00 20.00
 storm-control action shutdown
 storm-control action trap

Note: This means that packets from OutWithTheGarbage network are all tagged VLAN ID 201, while packets from DulocThePerfectPlace network are UNTAGGED. This is so I can update the AP remotely and wipe it's config during the update then access it and recover it since a reset puts it to 192.168.1.1/untagged.

Steps:

  1. Setup MR52 and configure both it's wifi interfaces and it's lan interface into the default bridge that's plugged into the Catalyst port 20. Set IP 172.16.201.254 on it's management interface (or whatever IP address you want) In other words - set it up like a standard out-of-box AP. I like to mount these in ceilings and such and power them from PoE switches but you do you. (and, incidentally there's loads of options in the wifi for this unit so make sure your stuff connects - as OpenWRT will happily let you shoot yourself in the foot on this one) Don't turn on firewalling as it's pointless.

  2. Setup the Catalyst and make sure that both VLANS are accessible from the switch. The easiest way to do this, by the way, is set one port on the switch switchport mode access/switchport access vlan 201 the another the same except switchport access vlan 101 and then plug in a plain old client PeeCee into each port in turn and make sure it pulls an IP and is able to do it's thing.

  3. Login to the AP with Luci and also (if you care to know what the heck is going on) login to the AP via SSH and dump contents of /etc/config/network and /etc/config/wireless

  4. In Luci:

a) Click Network, select Interfaces, select Devices tab
b) click Add device configuration
c) select the dropdown under Device Type, select VLAN (802.1q)
d) select under Base device, br-lan. You can ALSO select Base Device of lan0.
e) type in 101 to VLAN ID
f) Device Name will auto-fill with br-lan.101 or eth0.101 if you selected that device.
g) Save it and go back to Devices, click Save and Apply

This creates the following virtual device in /etc/config/network and names it br-lan.101 or eth0.101 depending on which base device you built the device on.

config device
        option type '8021q'
        option ifname 'br-lan'
        option vid '101'
        option name 'br-lan.101'

a) Back in Luci, click network->interfaces-Devices
b) click add device configuration
c) select the dropdown under Device Type, select Bridge Device
d) For Device name, name it br-lan-101 (OK ok, I'm not that creative, name it what you like)
e) for Ports, select br-lan.101 or eth0.101 (this is the virtual vlan interface we just created)
g) Save it and go back to Devices, click Save and Apply

This creates the following virtual bridge in /etc/config/network and ties it to the virtual device you just created

config device
        option type 'bridge'
        option name 'br-lan-101'
        list ports 'br-lan.101'

a) Back in Luci, click network->interfaces-Interfaces tab
b) click add new interface
c) name it "publan" (you can name it whatever you want)
d) select protocol Unmanaged
e) Select Device br-lan-101 (this is the bridge we just created)
f) Save it and go back to Devices, click Save and Apply

This creates the following virtual interface in /etc/config/network and ties it to the virtual bridge you just created

config interface 'publan'
        option proto 'none'
        option device 'br-lan-101'

a) In Luci, click Network Wireless
select Edit on radio you want to put on the OutWithTheGarbage network
under Interface Configuration
b) add publan, delete lan
c) save and apply

This changes

/etc/config/wireless

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'publan'
        option mode 'ap'

[you don't need to see the rest]

Now, associate to your DulocThePerfectPlace SSID and make sure your getting connectivity. Then disconnect and associate to OutWithTheGarbage SSID and make sure your getting connectivity. Reboot everything to make sure the configs are saved and it all holds and then relax with a nice pint.

We is done!

1 Like

Sounds like it's working now, unless I'm misunderstanding your latest post.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.