Additional SSID not working + OpenWrt revert question (GL-BE9300)

[godlev]

Hello,

I’m trying to create an additional SSID (for IoT) on my GL-BE9300, but I’m unable to get it working.

What I observe:

• SSID is visible

• Wrong password → authentication fails (expected)

• Correct password → connection fails / times out

• Interface does not seem to initialize properly (no IP / traffic)

Only the default LAN and Guest SSIDs work reliably.

Questions

1. Is there an official way to create additional SSIDs (beyond Guest) on this device?

2. Are there limitations per radio or firmware restrictions?

If this is not supported:

3. Is it safe to flash pure OpenWrt to achieve this?

4. Can I revert back to GL.iNet firmware, and what are the official steps?

[will.qiu]

Hi

Please refer to: How to set up the VLAN for IoT Wi-Fi on Flint 3(GL-BE9300)

[godlev]

Thank you for your swift replyt
I followed the instructions and DHCP is malfunctioning - here is a summary:

• Static IP on client works immediately (full connectivity confirmed)
  • This proves bridge, routing and firewall are correct
• Issue seems specific to DHCP/broadcast traffic
  • when client tries to connect with DHCP it stays for 2 mintues on connecting and then returns error that it cannot obtain ip adress, meanwhile log for dhcp is empty.

Relevant log:
"Ignore set station for ap vlan ath01"

Conclusion:
It appears that the secondary SSID (ath01 on 2.4GHz radio) is not forwarding broadcast traffic properly, which breaks DHCP.

Questions:

1. Is this a known limitation/bug on GL firmware (Qualcomm driver)?
2. Is there an official way to create a fully functional additional SSID (non-guest) on 2.4GHz?
3. Are there required settings (AX mode, VLAN, driver flags, etc.) to make DHCP work on additional SSIDs?

edit:

I have confirmed that DHCP broadcast traffic does not reach br-iot from ath01.

Evidence:

• WPA handshake completes
• Client connects successfully
• Static IP works immediately
• No DHCPDISCOVER appears in logs for br-iot

This indicates broadcast forwarding is broken on secondary SSID (2.4GHz).

Can you confirm if this is a known limitation of the current firmware/driver?

[will.qiu]

Did you enable the DHCP server on the corresponding IoT interface as described in step 4 of the guide?

@Miles

4. Enable DHCP for IoT Network
We configure a DHCP server to assign IP addresses to IoT devices.

uci set dhcp.iot=dhcp
uci set dhcp.iot.interface='iot'
uci set dhcp.iot.start='100'
uci set dhcp.iot.limit='150'
uci set dhcp.iot.leasetime='12h'

We’ve tested this locally, and by simply following the tutorial steps, a new SSID can be created successfully, with other devices able to connect and function normally—no additional steps are required.

If possible, please follow the guide and share your device with us via GoodCloud so we can check it remotely?

Technical Support via GoodCloud - GL.iNet Router Docs 4

Kindly note to send us the MAC address and the router password via private message so we can access it

[godlev]

Thanks for your suggestion
i prefer to resolve it without giving you direct access.

Yes, DHCP is already configured exactly as in step 4:

config dhcp 'iot'
option interface 'iot'
option start '100'
option limit '150'
option leasetime '12h'

Additional observations:

• Client connects successfully to the IoT SSID (WPA handshake completes)
• Static IP connects immediately (connectivity confirmed)
• However, no DHCPDISCOVER appears in logs for br-iot

Example:
logread -f | grep DHCP → no entries when connecting to IoT SSID

At the same time:

• DHCP works correctly on br-lan
• dnsmasq is functioning normally

[pearl_am]

It seems, that Ihave a similar problem on a Flint3e GL-BE6500. Firmware: v4.8.7 (Based on OpenWrt 23.05-SNAPSHOT). Since the above mentioned guide explicitly mentions Flint3 only I did not try it.

Any attempt to create a third isolated network fails. While devices can successfully authenticate to the third WiFi SSID (e.g., ETM_Guest), they never receive an IP address and eventually disconnect. The system log shows a critical error from the wireless driver:
kern.err kernel: ... wlan_cfg80211_change_station: Ignore set station for ap vlan

Summary of Troubleshooting Steps:

1. Standard VLAN Tagging (Failed): Using the standard OpenWrt method of creating VLAN-tagged sub-interfaces (e.g., br-lan.20, br-lan.30). This failed with the Ignore set station for ap vlan error.

2. Separate Software Bridges (Partially Successful): creating fully separate software bridges.

   • IP issue: Changing the default lan IP address from 192.168.8.1e.g. to 192.168.10.1 breaks DHCP functionality for the primary 2.4GHz radio (wlan0). Reverting to 192.168.8.1 fixes this.

   • Successful Two-Network Workaround: By keeping the lan at 192.168.8.1, the router's built-in guest network can be repurposed by renaming from guest interface to iot, changing its IP to 192.168.20.1, and assigning a wireless SSID to it. Works perfectly.

   • Creating a Third Network (Failed): Manuall creating a new, third network with a new guest interface (192.168.30.1) with its own bridge, DHCP pool, and firewall zone, precisely duplicating the configuration of the now-working iot network failed with the same Ignore set station for ap vlan kernel error.

It appears the firmware on the GL-BE6500 only the default lan interface and the default guest interface can be attached to a wireless radio.

[will.qiu]

If GoodCloud access cannot be provided, could you export the LuCI backup file and send it to us via private message so we can import your configuration for testing?

The backup file can be exported from LuCI → System → Backup / Flash Firmware:

[will.qiu]

Hi

The tutorial mentioned in this post also applies to the BE6500—please give it a try:

How to set up the VLAN for IoT Wi-Fi on Flint 3(GL-BE9300)

For Flint3 (GL-BE9300) only. Describes how to configure a dedicated IoT network on SSH by creating a VLAN (VID 25), a bridge, DHCP, firewall rules, and a separate 2.4 GHz Wi-Fi SSID. 1. Define VLAN 25 on eth1 We create a VLAN subinterface eth1.25 using IEEE 802.1Q tagging. uci set network.eth1_25=device uci set network.eth1_25.type='8021q' uci set network.eth1_25.ifname='eth1' uci set network.eth1_25.vid='25' uci set network.eth1_25.name='eth1.25' 2. Create the IoT Bridge We define a new b…

[will.qiu]

Thank you for providing the backup configuration file.

After reviewing it, we found that a required step appears to have been missed, which caused DHCP requests from devices to the IoT network to be blocked by the firewall.

After importing your backup to our local router and adding this step, devices connected to the IoT SSID were able to obtain IP addresses via DHCP.

@Miles

7. Allow DHCP and DNS for IoT
Firewall rules are added to allow IoT clients to obtain DHCP leases and resolve DNS.

uci add firewall rule
uci set firewall.@rule[-1].name='Allow-DHCP-IoT'
uci add_list firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].dest_port='67-68'
uci set firewall.@rule[-1].target='ACCEPT'

uci add firewall rule
uci set firewall.@rule[-1].name='Allow-DNS-IoT'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].target='ACCEPT'

Please try again and let us know if this resolves the issue.

Note that after re-excute these commands, we will need to save the configuration again and restart the system .

@Miles

9. Apply and Reboot
Finally, commit all changes and restart the router.

uci commit
reboot