Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
openwrt-bot opened this issue Apr 9, 2021 · 0 comments
Open

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

openwrt-bot opened this issue Apr 9, 2021 · 0 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Apr 9, 2021

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant