Fantastic thread overall. I've read the whole thing from start to finish and am a little unclear on a few questions:
Is there a full How-to document for this functionality posted somewhere on the Wiki yet?
Is it still necessary to replace wpad-basic-wolfssl with the full wpad-wolfssl, or has this been rendered unecessary by later OpenWRT versions?
Is it true/correct that basically this feature won't work with WPA3 / SAE, and that there's not likely to be a fix for that due to the way SAE itself works?
(Fwiw: my setup is a single Unifi UAP-AC-LITE running OpenWRT 23.05.2, configured as a pure WAP AP with 3 VLANs, routing handled upstream by a separate Opnsense router/firewall/gateway.)
(ath79/generic, kernel 5.15.137)
Does using wifi-vlan (without vlan_tagged_interface and vlan_bridge) work for anybody on Git master? I am not able to get the wifi interface added to the bridge. It works with vlan_bridge option (I am using br-vlan<n> pattern), but I cannot get it working with just wifi-vlan (without vlan_bridge option). I read several times in Forums that it should work, some mentioning I have to add none-protocol interface (which I did), so maybe something is broken on master, or I am still doing something wrong.
I'm new to this forum but not new to openwrt, although there is alot of virgin grounds within the domain I've never tried..
I've recently setup a new linksys ea8300 with 23.05.2 and am trying some things out before putting this router in my network (my active router, same linksys ea8300 runs 22.03.5) and I am trying to setup vlans for my wifi to use what other brands call Dynamic psk but haven't managed to get it working as explained by @takimata or @grauerfuchs , I assume this setup should work too if router is running DSA switch ?
I would assume likewise, but I can't offer any actual first-hand experience, I actually exclusively used this method on switchless single-port devices I use as access points. What I could imagine is that DSA requires the bridges to be set up first through the network configuration, and hostapd being configured to latch onto those bridges instead of creating new ones.
76x8
brctl show
bridge name bridge id STP enabled interfaces
br-vlan100 7fff.0e0001030101 no eth0.100
wlan0-vl100
br-vlan2 7fff.0e0001020101 no eth0.2
wlan0
br-vlan200 7fff.0e0001040101 no wlan0-vl200
eth0.200
br-vlan1 7fff.0e0001010101 no eth0.1
br-vlan255 7fff.0e0001050101 no wlan0-vl255
eth0.255
Just in case there's still confusion about PSK2 vs. SAE with regard to multiple PSKs and VLAN:
PSK-/MAC-based VLAN assignments work in principle (scroll down to Solution if you don't care about the details).
There are problems when the assignment is ambiguous. Because both parties in SAE find out whether they are using the same password at the same time, the AP has only one attempt at checking a password (when the AP checks a non-matching password, the client will think they entered the wrong password).
That means that, in theory, no more than one 'default' PSK can exist.
All other station definitions must include the MAC address.
PSK2 authentication uses hostapd_wpa_auth_get_psk from src/ap/wpa_auth_glue.c which can be called multiple times to return more than one password. It looks for a matching PSK first in hostapd_get_psk (src/ap/ap_config.c) and then goes through the list on the sta_info corresponding to the MAC - that doesn't really work with SAE.
Because everything is so different with SAE, it has different code paths. For instance sae_get_password from src/ap/ieee802_11.c: It first looks for a match in sae_passwords (see below), then it tries wpa_passphrase, and - only if none of those yielded a password - will it check the station-specific PSKs. And it'll take only the first non-PMK. BUT even if you manage to get a match through there, auth_build_sae_commit only considers VLAN IDs from a sae_password_entry.
Solution
There is a config option sae_password.
From hostapd.conf:
# The last matching (based on peer MAC address and identifier) entry is used to
# select which password to use. Setting sae_password to an empty string has a
# special meaning of removing all previously added entries.
Dynamic VLAN assignment is definitely supported with SAE - it's just done differently than it is with PSK2.
For it to be practical to use with Openwrt, a lot still needs to be done.
A first step could be to convert the stations from UCI to sae_password= config entries and reloading them through ucode.
A better idea could be to have hostapd read SAE passwords from a file that can be reloaded separately (more work).
Is there a way to apply the same wifi-vlan and wifi-station stanzas to more than one virtual AP but not to all? E.g. I have 5 APs (2x 2.4Ghz, 2x 5GHz UNII-1 and 1x 5GHz UNII-2c) and 10 VLANs, which I want applied to just 2 of the APs. I tried adding a second "option iface" line for wifi-vlan and wifi-station but it didn't work (as expected).
LE: In case you are wondering why I want to set them like this - it's because I want SAE on one AP on each band and until @roshii manages to complete the PR for this SAE won't play nice with wifi-vlan and wifi-station. Hence I added a 2nd AP with just PSK2 on 2 of the 3 bands.
I have a question for everyone....I am trying to implement this feature on my TP-Link EAP-615v1 AP. However when I try to install the package (based on the second post in this thread), I get the error below.
root@OpenWrt:~# opkg install wpad-wolfssl
Installing wpad-wolfssl (2023-09-08-e5ccbfc6-6) to root...
Collected errors:
* check_conflicts_for: The following packages conflict with wpad-wolfssl:
* check_conflicts_for: wpad-basic-mbedtls *
* opkg_install_cmd: Cannot install package wpad-wolfssl.
So when I try to install the full wpad_mbedtls package, it says it can't (I believe it's due to the dependencies).
Does anyone know if this feature available for my device? I'd love to implement it if possible. TIA
The easiest solve is to replace the firmware with a custom build from the firmware selector on the OpenWRT site. Just open up the Customize installed packages and/or first boot script option and edit away. Just make sure you don't delete anything without replacing it with the alternative, or you could end up with a firmware that doesn't work properly.
Generally speaking you need to remove the basic wpad and install the non-basic wpad.
My post you are referring to was written when the then-current release version of OpenWrt, 22.03, used wolfssl as its SSL library. With 23.05, OpenWrt switched to mbedtls.
Consequently you now need to opkg remove wpad-basic-mbedtls, killall hostapd, and then opkg install wpad-mbedtls.