You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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).
The text was updated successfully, but these errors were encountered: