Without deeper insight, that sounds to me like you have the bridge both manually created and simultaneously configured to be created on-demand by hostapd.
Hmm. I don't think so, but maybe some option is not correct.
/etc/config/wireless
...
option vlan_file '/etc/config/hostapd.5-vlan_iface'
option vlan_tagged_interface 'eth0'
option vlan_bridge 'dynbr.'
option dynamic_vlan '1'
...
'/etc/config/hostapd.5-vlan_iface
...
31 wlan5.31 br.31
...
So the dynamic bridge would be (and had been) dynbr.31 and none of those is created after I added the manual bridge br.31 to the interface file.
Is your bridge configured as an empty bridge? Without explicit configures enslaved interfaces?
And yes when you create a bridge manually then OpenWrt can not ensure proper handling. This is expected and more the result of wrong doing...
Sorry, missed this reply somehow!
No, the bridge is not empty but has an interface attached. The point of the exercise is to get an interface with an IP for the AP on the wireless VLAN network in order to be able to eg. ping the AP through VLAN for testing purposes.
It seems the only reliable way of doing this, that does not interfere with the infrastructure of OpenWrt+hostapd-setup, is assigning an IP to the dynamic bridge interfaces and add a route (via CLI) on-demand.
Then you "have to" configure all your VLANs upfront on the AP then.
Configure them with proto static or proto dhcp/proto dhcp6.
With "empty bridge" I was referring to option bridge_empty ("Enables creating empty bridges" aka bridge will be set up even without an enslaved/attached interface) just in case that this was somehow misleading/unclear.
... which interferes with wireless up/down when using this per-passphrase VLAN.
If the bridge is pre-defined, wireless will use it fine. However, in case of wifi down it will then still tear does bridges (even though not generated by wireless automatically). And after that, the only way of getting the interfaces back onto the bridges is a restart with start up at boot option for the interfaces.
On top, it seems somewhat a bet - maybe reliable for now, maybe no longer in future - that this will do the right things in the right order upon booting.
Given that this is usually not needed at all, I think using CLI on-demand is ok.
ip addr add 192.168.12.34 dev dynbr.31
ip route add 192.168.12.34/24 dev dynbr.31
An improvement would be to get that executed through some kind of trigger automatically after eg. the dynamic bridges are brought up by hostapd.
Don't use wifi up and down then?
Restart the whole network stack.
I assume you have a more or static/defined list of vlans. So just dump them all on all AP and switches in your network and be done.
I may just don't see your issue but I do it that way just fine.
This is what I don't understand, because ... it really shouldn't. How are you creating that bridge in the first place? Manually?
I will concede that I'm not great at reading source code, but as far as I can see hostapd keeps track whether it created the bridge by itself, and only tears it down if it did. It also checks if the tagged wifi interface is the only remaining port in the bridge before tearing it down. But again, I could be wrong.
My apporach would probably be to start fresh, with one bridge, one attached network interface, and one vlan-tagged wifi interface inside. And rebuild from there.
Yes. Manually through Luci. When wifi starts, all is fine and it works. When hostapd is tearing down bridges for whatever reason, it is including those manually created ones.
There is basically these two options in the /etc/config/wireless (among the other necessary ones):
option vlan_bridge 'dynbr.'
option dynamic_vlan '1'
So I can clearly distinguish the bridge devices that are created by hostapd (named dynbr.xx) and the manual ones (named br.xx) and can tell it is using the manually created ones. I can as well tell, that it does not work without that "vlan_bridge xxx" option (error message) - even though there is no need for it to create any bridge.
I have not tested if I could actually turn off "dynamic_vlan".
Well, that could turn out disastrous, given it would (I assume) reset the connection that I am logged in through SSH. If there it fails to start (maybe incorrect edits by me), I am effectively locked out. Restarting only wifi is safe 
Yes, that's what I meant by "that this is usually not needed at all". After the initial setup and after things work, there is usually neither a need to wifi up/down nor having those IPs/interfaces on the VLANs.
How often do you introduce new vlans so that this is a real issue?
Lost ssh connections are not the end of the world.
If you need to ensure the session then use a session manager like tmux.
It is not a real issue. As stated, it's fine to assign an IP on-demand through CLI. If those commands could get executed automatically by a trigger it is an improvement for sure. If not, it is still a non-issue but rather a small inconvenience.
No, not the end of the world. However, if you cannot connect to the AP anymore, because it fails to start up the interfaces due to eg. a typo in the config, it can be a pain for sure. Some APs and their reset buttons for failsafe boot are not that easy to access.
Ok let's recap here.
First. Decide/dedicate 1 management vlan. For this interface you either do DHCP or static. Don't miss the IPv6 config 
Second. For all the other interfaces. Either use link local addresses which can be kind of static if use assign static Mac addresses to each known vlan interface. Or if you already config a device and interface then setup an IP address if you really need it.
This is usually be done in some enterprise and ISP networks when it's critical to identify an interface and path. But dude, on a dump ap home network? No way.
I configure all vlan interfaces nether the less because I want static mac addresses for my batman adv mesh. But besides that? Only the management interface and loopback get an uniq ipv4 and IPv6 address.
I may just not get your issue so please be invited to continue this conversation.
I think you keep missing, that this is a non-issue
You are absolutely correct, that there is no need for an IP on the VLAN bridge of the AP. Usually. Hopefully. In the ideal world, the AP will work transparently until it's EOL, automatically update itself without interference and never ever require any kind of changes to it's configuration after you have complete the initial setup.
We all know, that this is but a dream. It's those - hopefully very rare - occasions, where something is off and you need to for example trace connectivity between two devices.
For me, just having started to get VLANs introduced to my home network, those occasions had been plenty early on 
Especially during setup of the first AP with OpenWrt and introducing the first VLANs, being able to trace the connection from OPNsense down to the wireless link via tagged VLAN had been very helpful...well, let's say required.
And that's all there is and what started the discussion. Debugging connectivity until it works. And hopefully never ever again afterwards 
I see... but:
- A dumb AP is a better switch. It does no routing
[1], you could/should even disable routing, seesysctland itsnet.ipv4.ip_forwardandnet.ipv6.conf.all.forwarding; therefore you can not trace (follow a path), you can only test (endpoint) reach ability, but tracing layer-2 is an other kind of beast. - Again, if you need to reach a switch or dumb ap, then use a dedicated management vlan and/or in addition an address on loopback; that's the way how you do it in large/enterprise networks, and it makes sense on smaller networks too.
In general: When you are done with your VLAN setup you are more or less done. I may have to introduce a new VLAN once a year. (a couple of user vlans; printer; tv; and the like; 2 work from home networks; one of the kiddo, but after that? there is no much movement.)
I just want to avoid that you do silly extra work without any benefit.
And if your config has "stabilized" then a restart of the whole network is just done in 30 to 60 sec and should not leave you worrying. (Yes I say that with configence even I, too, loose a device from time to time, and it then needs a good old clean power cycle to recover ^^)
My 2 cents
[1] Routing happens with IP Packets on Layer-3; while switching/forwarding of Ethernet Frames happen on Layer-2.
EDIT2:
Guess this really didn't belong in here as it pertained to RADIUS.
I have now decided to use the invaluable advice in this thread and use PPSK for wifi clients and save RADIUS for dynamic switch ports.
EDIT: So I manually created an interface called Guest using br-lan.26 and added a tagged port for it to br-lan and this resulted in stations getting an IP address, so I'm a little confused by 'VLAN Tagged Interface' and 'Bridge Naming Scheme'
Hi all,
I'm doing something very similar to this, but using FreeRADIUS
I have OpenWrt set up with hostapd-mbedtls and an SSID called RADIUS using WAP2-EAP/WPA3-EAP
The OpenWrt AP has a tagged uplink to VLAN31, therefore I have enabled VLAN filtering on br-lan and tagged the port connected to the uplink switch. I have created an interface called Infra that uses br-lan.31 to get an IP address from the uplink switch.
I have configured the RADIUS SSID to use the Free RADIUS server and chosen br-lan for vlan_tagged_interface and br-vlan for vlan_bridge. I have also chosen 'Dynamic VLAN Assignment' as Required
I have added a user in FreeRADIUS called stephen with password radiustest and VLAN26
When I connect to SSID RADIUS, with username stephen and password radiustest, I can see OpenWrt creating br-vlan26: port 1(br-lan.26) and my station authenticates, but doesn't get an IP address.
I'm sure I'm missing something obvious, but for the life of me can't figure out what. If I understand correctly, VLAN26 doesn't need prior configuration, as hostapd does that on the fly, but why no IP?
[3 Jun 2026, 13:57:47 BST] daemon.info: hostapd: phy0-ap1: STA 4c:23:38:**:**:** IEEE 802.11: authenticated
[3 Jun 2026, 13:57:47 BST] daemon.info: hostapd: phy0-ap1: STA 4c:23:38:**:**:** IEEE 802.11: associated (aid 1)
[3 Jun 2026, 13:57:47 BST] daemon.notice: hostapd: phy0-ap1: CTRL-EVENT-EAP-STARTED 4c:23:38:**:**:**
[3 Jun 2026, 13:57:47 BST] daemon.notice: hostapd: phy0-ap1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
[3 Jun 2026, 13:57:47 BST] daemon.notice: hostapd: phy0-ap1: CTRL-EVENT-EAP-STARTED 4c:23:38:**:**:**
[3 Jun 2026, 13:57:47 BST] daemon.notice: hostapd: phy0-ap1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
[3 Jun 2026, 13:57:48 BST] daemon.info: hostapd: phy0-ap1: STA 4c:23:38:**:**:** RADIUS: VLAN ID 26
[3 Jun 2026, 13:57:48 BST] daemon.notice: hostapd: phy0-ap1: CTRL-EVENT-EAP-SUCCESS2 4c:23:38:**:**:**
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.870000] br-vlan26: port 1(br-lan.26) entered blocking state
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.880000] br-vlan26: port 1(br-lan.26) entered disabled state
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.880000] br-lan.26: entered allmulticast mode
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.890000] br-lan: entered allmulticast mode
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.890000] br-lan.26: entered promiscuous mode
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.900000] br-lan: entered promiscuous mode
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.910000] br-vlan26: port 1(br-lan.26) entered blocking state
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.910000] br-vlan26: port 1(br-lan.26) entered forwarding state
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.920000] br-vlan26: port 2(phy0-ap1.26) entered blocking state
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.930000] br-vlan26: port 2(phy0-ap1.26) entered disabled state
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.930000] ath10k_pci 0000:02:00.0 phy0-ap1.26: entered allmulticast mode
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.940000] ath10k_pci 0000:02:00.0 phy0-ap1.26: entered promiscuous mode
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.950000] br-vlan26: port 2(phy0-ap1.26) entered blocking state
[3 Jun 2026, 13:57:48 BST] kern.info: [ 2851.950000] br-vlan26: port 2(phy0-ap1.26) entered forwarding state
[3 Jun 2026, 13:57:48 BST] daemon.info: hostapd: phy0-ap1: STA 4c:23:38:**:**:** WPA: pairwise key handshake completed (RSN)
[3 Jun 2026, 13:57:48 BST] daemon.notice: hostapd: phy0-ap1: EAPOL-4WAY-HS-COMPLETED 4c:23:38:**:**:**
[3 Jun 2026, 13:57:48 BST] daemon.notice: hostapd: phy0-ap1: AP-STA-CONNECTED 4c:23:38:**:**:** vlanid=26 auth_alg=open
[3 Jun 2026, 13:57:48 BST] daemon.info: hostapd: phy0-ap1: STA 4c:23:38:**:**:** RADIUS: starting accounting session 63A4C30AC725F13A
[3 Jun 2026, 13:57:48 BST] daemon.info: hostapd: phy0-ap1: STA 4c:23:38:**:**:** IEEE 802.1X: authenticated - EAP type: 25 (PEAP)