Configuring VLAN for WiFi without switch

I've set up a good dozen VLANs across a hanful of interconnected OpenWrt routers/switches i.e. with actual "Switch VLAN" devices. But now I'm back in learning territory trying to set up a "just plain eth0" device for VLANs.

Specifically this is a a Raspberry Pi 4 and my goal is to have its:

  • Ethernet port connected to a "trunk" supporting several VLANs (all tagged)
  • WiFi interface hosting an AP corresponding to one of those VLANs

I've added a lan0 interface for a DHCP client on eth0.1, which automatically set up a "VLAN (802.1q)" device over in that tab. That's working and allows me to connect to LuCI alongside all the other routers that live on VLAN1.

But what I'm struggling to set up now is the WiFi portion. I want to set up an SSID mynetwork-iot that basically dumps in/out of eth0.666. So that means I need an Interface to associate with the wireless station, and I believe that interface needs to have a bridge as its device?

Now in order to set up that bridge, I need to tell it which ports are involved. And the only way I've found to get an eth0.666 that doesn't show up as a greyed out "Software VLAN" or only a "Custom Interface" entry is to first create another unmanaged interface and type in eth0.666 as its device, which then automatically generates.

So now I have two interfaces:

  • iot (br-iot)
  • iot-vlan (eth0.666)

and two devices:

  • br-iot — which I created, associated with port eth0.666
  • eth0.666 — automatically created "under" the iot-vlan interface

And after selecting that first iot as the "network" for the WiFi AP, it does get associated with the little wlan0 wireless icon back over in the Interfaces section of the UI. But clients on that AP aren't getting IP addresses :-/

Now, this could just be a misconfiguration throughout the rest of the "trunk" and maybe VLAN666 packets just aren't making it all the way back to the main router that assigns DHCP. But this seems like quite a bit more steps/entries than I've had to take before with switch-based VLAN setup. I'm also a bit wary — on the newer OpenWrt builds as I upgrade my routers it seems like VLAN setup moved from the nice big "Switch" interface into the raw hidden-away little "Bridge VLAN filtering" tab. Is that what I should be using straight from just a bridge directly on eth0 to set this up, instead of all the extra interfaces?

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

I discovered there was a break in the chain of VLAN forwarding and resolved that, but I'm still not getting DHCP leases as a WiFi client. I did replace the unmanaged interface vlan666 with a DHCP client itself and the RasPi router is getting a lease for itself, just not any of its AP-connected clients now.

root@mynetwork-pi-fi:~# ubus call system board
{
	"kernel": "5.10.176",
	"hostname": "mynetwork-pi-fi",
	"system": "ARMv8 Processor rev 3",
	"model": "Raspberry Pi 4 Model B Rev 1.1",
	"board_name": "raspberrypi,4-model-b",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "22.03.5",
		"revision": "r20134-5f15225c1e",
		"target": "bcm27xx/bcm2711",
		"description": "OpenWrt 22.03.5 r20134-5f15225c1e"
	}
}
root@mynetwork-pi-fi:~# 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 'xxxx:xxxx:xxxx::/48'

config interface 'lan0'
	option proto 'dhcp'
	option device 'eth0.1'

config interface 'iot'
	option proto 'none'
	option type 'bridge'
	option device 'br-iot'

config device
	option type 'bridge'
	option name 'br-iot'
	list ports 'eth0.666'

config interface 'vlan666'
	option proto 'dhcp'
	option device 'eth0.666'

root@mynetwork-pi-fi:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/fe300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
	option cell_density '0'
	option band '2g'
	option channel 'auto'

config wifi-iface 'wifinet0'
	option device 'radio0'
	option mode 'ap'
	option ssid 'mynetwork-iot-rc'
	option encryption 'psk2'
	option key '-redactolated-'
	option network 'iot'

root@mynetwork-pi-fi:~# 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 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'

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@mynetwork-pi-fi:~# cat /etc/config/firewall

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

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

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

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

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'

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'

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'

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'

root@mynetwork-pi-fi:~# 

Remove the line that specifies option type bridge -- that does not belong there.

If your devices still are unable to get an address on the iot SSID, check your router and switch to make sure you've configured the trunk ports correctly to carry vlan 666 as your iot.

You have two options - first:

  • create a bridge in Network -> Interfaces -> Devices for each SSID you want and assign "custom interface" eth0.XX as a port
  • create an interface for each ssid as either unmanaged if you don't need to access the device via that vlan or static/dhcp client if you do, and select that bridge device you created
  • create a virtual ap and select the "interface" you created in the "network" field (I know that naming is not that clear)

Second:

  • create one bridge in Network -> Interfaces -> Devices and assign eth0 as a port, then enable VLAN filtering and add each vlan you want to use
  • create an interface for each ssid as either unmanaged if you don't need to access the device via that vlan or static/dhcp client if you do, and select br-name.XX as the device
  • do the exact same for the third step

The first option will create a separate bridge for each ssid where ports will be eth0.XX and wifi ap interface you create.

The second option will create only one bridge where one port will be eth0 and others will be all the wifi ap interfaces you created, but this bridge will have vlan filtering enabled (functions almost exactly like what swconfig vlan configuration does), and the wifi ap interfaces will get assigned the correct vlan membership defined in "interface" section.

1 Like

Note that the raspberry pi (all variants) can only support a single SSID. This means that only a single bridge is necessary (the bridge for the network that will be connected to the wifi radio), but it is perfectly acceptable to have a bridge for each network even if there is only a single physical interface associated.

Also keep in mind that the performance of the wifi system on a Pi (again, all variants) is poor -- single radio 1x1 arrangement, small PCB based antena, low sensitivity. Yes, it will create a wifi network, but it's not a good one.

That seems to have done the trick! I deleted that interface, added a new one and reconnected it to the WiFi. (I had not shelled in to this setup until the request for config dump, so LuCI must have added that hidden line at some point in all my experimentation.)

Now clients get an IP in the same range as the corresponding/underlying "DHCP client" interface. I might test re-creating that back as an "Unmanaged" but otoh for now I might just leave it be.

Great! Glad I could help!

This is recommended for situations where the network in question is not the management network and there is no need for the hosts on that network to be able to access the OpenWrt router/device. A good example is a guest or iot network -- normally there is no need for devices in these categories to be able to access the router/ap, and it is best scurity practice to simply not include an address when the device is serving as a dumb AP.

And thanks for this explanation! So in all cases I do need an interface for each "SSID" (really it's each VLAN that needs an interface if I'm not mistaken…?) and then the question is just how I bridge them:

  1. separate bridge device per VLAN
  2. one "global" bridge with the new (DSA switch?)–style VLAN table

Yep, unfortunately found this out after thinking this would be a quick and easy way to replace a router I bootlooped today. Instead it's been yet another round of "continuing education", ah well… :joy:

Yep, at least for now I've landed on:

  • a bridge device for the WiFi↔︎Ethernet connection to the IoT vlan (configured: vlan iface w/autocreated device + underlying bridge device [edit, see downthread: this alone is sufficient to autocreate the VLAN device] + "Unmanaged" bridge iface)
  • only an auto-created eth0.1 device for the "DHCP client" for ssh/LuCI on the router itself (configured: just the "DHCP client" iface, device autocreated)

Still getting a handle on what's the difference between devices that already exist from hardware, devices that get autocreated [seemingly only when referenced from "interfaces"], devices that I have to create, and all vs. those "interfaces" in the other tab… but at least getting a feel for when I need what.

Thanks all for the tips and pointers!

correct, yeah I really don't want the router to actually listen or participate in the IoT network. was more for expedience when testing/troubleshooting the backhaul and I should clean that up before actually deploying this tomorrow.

Here's an updated dump, working and now simplified back to original intent, if it helps anyone else finding this thread:

root@mynetwork-pi-fi:~# 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 'xxxx:xxxx:xxxx::/48'

config device
	option type 'bridge'
	option name 'br-iot'
	list ports 'eth0.666'

config interface 'iot'
	option proto 'none'
	option device 'br-iot'

config interface 'vlan1'
	option proto 'dhcp'
	option device 'eth0.1'

config interface 'vlan666'
	option proto 'none'
	option device 'eth0.666'

root@mynetwork-pi-fi:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/fe300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
	option cell_density '0'
	option band '2g'
	option channel 'auto'

config wifi-iface 'wifinet0'
	option device 'radio0'
	option mode 'ap'
	option ssid 'mynetwork-iot-rc'
	option encryption 'psk2'
	option key '-redonkedout-'
	option network 'iot'

root@mynetwork-pi-fi:~# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option synflood_protect '1'
	option forward 'ACCEPT'

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


(the dhcp config omitted as not really at play; the firewall mostly irrelevant as well…)

Remove this. You already have be-iot with this vlan id.

Oh, nice! Early on during my setup it seemed like when I specified the VLAN only from the bridge device, it wouldn't autocreate and so eth0.666 ended up listing as a "Custom Interface" rather than a "Software VLAN".

But I just deleted it [and rebooted the whole device to be double-sure] and still works just fine now without it!

Much appreciate you noticing and flagging that detail, since it's a relief to not need that. Seemed like extra clutter and an extra step that wasn't needed when using switch-based VLANs; nor here in the end which is nice. I'll lightly edit my post above to note one of its details being wrong.

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