FS#3732 - hostapd: VLAN-assignment via sae_password sometimes fails

[openwrt-bot]

Crazyachmed:

Device: Ubiquiti UniFi AC LR (OpenWrt SNAPSHOT r16382-209c5918b5)

For some time I successfully run a per-device WPA2-PSK setup using the following options:

option network 'dummy'
option dynamic_vlan '2'
option vlan_file '/root/ogb-hostapd-vlans-phy0'
option wpa_psk_file '/root/ogb-hostapd-psks'
option key 'invalid-fallback-psk-used-by-no-device-at-all'

This setup forces all devices to use a MAC-PSK combination from the wpa_psk_file, where they are reassigned to a working VLAN that is mapped to a specific bridge via the vlan_file. Meaning: If a device were to use the PSK from the key-option they would be bridged into br-dummy, a bridge that uses a VLAN not present on the upstream switchport.

To reiterate: This works absolutely perfectly and rock stable - until I switch a device over to WPA3. I comment out the MAC from the wpa_psk_file and add it via the sae_password option:

list hostapd_bss_options 'sae_password=device-psk|mac=xx:xx:xx:xx:xx:xx|vlanid=8'

This works for some of the time only. Sometimes the device is assigned to the br-dummy bridge as if hostapd correctly uses the per-device-PSK, but ignores the vlanid-option. Usually a reconnect or two solves the problem. Using tcpdump I can clearly see the clients DHCP-requests in the br-dummy bridge when the issue occurs.

In the past I already tried to troubleshoot this issue by using the newest upstream hostapd but failed due to all the custom openwrt patches. I am really not a developer, but only a network engineer. Can someone please help me troubleshoot this? I would like to retry this with the newest hostapd before investing any time into troubleshooting something that might be already solved upstream (there were a couple of sae-patches).