Individual per-passphrase Wifi VLANs using wpa_psk_file (no RADIUS required)

Look into the syslog when starting up wifi. I can't test it right now but I suspect the bridges fail to set up correctly and the respective vlanid=... entries are then ignored, leading to what basically amounts to "wrong password" messages.

Edit: I can't try to reproduce your problem because I don't have any access points with a switch inside. However, what stands out to me is your

        option vlan_bridge 'br-vlan'

I'm not entirely sure, but I believe hostapd will try to create the br-vlan.xxx devices then, and fail because the already exist. Since you actually name all the bridges to which you want to attach the wifi interfaces, you can state

        option vlan_bridge 'proforma'

or something similarly nonexistant/unneeded. The vlan_bridge option must exist, but it doesn't have to make sense.

I could also be barking up the wrong tree here. Again, the syslog should tell you a bit more about what exactly fails. And if it doesn't, check the output of brctl show if the wifi interfaces got correctly inserted into your already existing bridges.

@takimata does FT working ?
i find when i move to another AP, the STA is bind to wrong interface.
example, wlan0 with wlan-vlan5.
for the first time it bind correctly to wlan-vlan5, but when i move to another AP, it bind to wlan0.
so the STA is in the wrong vlan.

perhaps @nbd can help my issue?
or FT is not supported with this kind of configuration?

FT is working but only on the 23.05 branch - 23.05.0-rc3. You also need to disable "Generate PMK locally"

So thanks to the additional UCI functionality adding multiple psk+vlan to my wpa3 and wpa2 APs was as simple as adding the following to /etc/config/wireless:

 config wifi-vlan
         option name 'guest' 
         option vid '33'
         option network 'guest_lan'

config wifi-station
         option vid '33'
         option key 'yournewpassword'

vid can be any number but must match, network is the bridge you want to attach to (in this case my guest wifi / IOT restricted bridge), and name can be anything.

For me this greatly simplifies adding IOT devices safely without having to spin up a bunch more virtual APs to separate them from my trusted wifi clients. Shame this feature isn't more widely known and better documented.

5 Likes

thanks, my build is the lateset snapshot.
i did try with pmk local and pmk r1 push, same result,
always back to master interface after roaming (checked with iwinfo iface assoclist), instead of designated vlan interface.
will try 23 branch.

also, can you share your wireless config ?

Latest snapshot should work fine - it is using even newer code. This is the commit that made it work with 11r FT. There is nothing special in my wifi config except that it uses . What device are you using?

is your wireless config for network defined?

This is great and something I really wanted to try. I believe this is what others are calling ePSK, dPSK(Dynamic PSK), mPSK and pPSK.

I can relate to all the buzzwords but also heard these days that multiple SOHO products offer now similar features as this setup.

Sorry if it's already mentioned (I did not find any information on this), but is this limited to WPA2 like Unifi? I read that this was not a Unifi limitation...

Just guessing but should work with other encryption modes too, because why not? As far as I know hostapd does not care. Could even work without a password at all, besides if you ignore the side effects.

It is not limited to WPA2-PSK. In fact it was working fine in hostapd for WPA3-SAE, WPA2-EAP and WPA3-EAP before it was ever working for WPA2-PSK.

2 Likes

That's lovely :+1:

There is a very annoying bug when using WPA3 and a wpa_psk_file : if you choose WPA3-SAE, fill in a key in luci (obviously, you can put only one key there) and use a wpa_psk_file where each client have his own key, this wpa_psk_file is completely ignored and the only valid key to connect to the AP is the one you put in luci (option key 'your key') Thus, you can't connect with the key in the wpa_psk_file, you may believe that the AP is not working properly...

If you choose WPA2-PSK/WPA3 SAE mixed mode, then the wpa_psk_file is NOT IGNORED but the client is forced to connect in WPA2 mode, even if he support WPA3. If you want to connect in WPA3 mode, you have to use the key entered in luci (option key 'your key')

tested on OpenWrt 22.03.5

1 Like

i think for WPA3-SAE need to use sae_password, just a thought.

3 Likes

This certainly appears to be a real issue to me, too. I converted from WPA2 using the uci wifi-vlan/wifi-station sections and the configuration which works perfectly on WPA2-PSK does not work at all on WPA3-SAE. As previously mentioned, only the primary key entered via/recognized by luci is the one that works. The appropriate network interfaces appear to exist after a full reload of wpad and no errors exist in the system log, but it's acting almost as if the declarations aren't present when it comes to connecting to the AP. I'm wondering if it's not internally converting these sections into the sae_password declaration as it does for wpa_psk_file, but I haven't yet been able to track down the effective config file(s) that wpad is consuming when it loads.

This doesn't work for me on Xiaomi AX3600. Could you please share a full config example of /etc/config/network and /etc/config/wireless without passwords?

Nov  1 14:08:41 hostapd: nl80211: kernel reports: Attribute failed policy validation
Nov  1 14:08:41 hostapd: Failed to create interface phy1-ap0-test: -22 (Invalid argument)
Nov  1 14:08:41 hostapd: VLAN: Could not add VLAN phy1-ap0-test: No such device
Nov  1 14:08:41 hostapd: VLAN initialization failed.
Nov  1 14:08:41 hostapd: Interface initialization failed

I'm using wpad-mesh-openssl and my first SSID is 802.11s mesh. Then the SSID that should have multiple PSK but fails startup follows. Do I still need the "config wifi-iface" section? Or is this header replaced by "config wifi-vlan"? How does OpenWrt know which "config wifi-vlan" sections corresponds to which SSID?

The wifi-vlan and wifi-station config sections referenced work in addition to the rest of the configuration sections. Consider it an add-on/bolt-on feature. By default, the sections refer to any and all wifi networks present on the device. If you want to limit it to a specific ssid (and in your case you do), you also need to add a line to the sections:

 option iface 'wifi-ifacename'

The iface referenced is the named wifi-iface. For instance, 'wifinet0' is usually the first luci-created wifi interface.

The following example sets up a multi-PSK configuration with the guest wireless being the primary and the LAN being a secondary. Any additional radios or SSIDs would be unaffected:

{radio definitions}
...
config wifi-iface 'wifinet0'
        option device 'radio0'
        option mode 'ap'
        option ssid 'ExampleWiFi'
        option key '*redacted*'
        option network 'GUEST'
        option encryption 'psk2+ccmp'

config wifi-vlan
        option iface 'wifinet0'
        option name 'secondary'
        option vid '3'
        option network 'LAN'

config wifi-station
        option iface 'wifinet0'
        option vid '3'
        option key '*redacted*'

...
1 Like

ath11k doesn't support this right now. @robimarko wanted to upstream a patch that I fixed and refreshed but didn't find the time yet.

2 Likes