LuCI support for PPSK in wpad-mbedtls?

Installing and Using OpenWrt
1

Hi everyone,

I'm currently running OpenWRT 25.12.0 from the official image release and planning to upgrade to 25.12.2. Right now, I'm just using wpad-basic-mbedtls, but I’m considering switching to the full wpad-mbedtls package because I need to implement PPSK (Private Pre-Shared Key).

I've seen the documentation for the manual UCI setup here. However, before I make the jump, I’d like to know if the latest LuCI builds now have a native GUI option to manage PPSK, including the wpa_psk_file and VLAN-related settings such as dynamic_vlan and vlan_file?

Managing it via CLI is doable, but having it integrated into LuCI would be much more convenient for my use case. Does the full wpad-mbedtls package enable any hidden PPSK menus in LuCI, or is it still strictly a manual UCI configuration?

Thanks for the help!

2

Apparently there is some support since

But @systemcrash may know more, as he merged the commit in.

3

The LuCI interface for configuring PPSK seems to be made specifically for using PPSK with a RADIUS server, where the RADIUS server knows each PPSK a client may connect with, and the OpenWrt device forwards the Wi-Fi connection attempt to the RADIUS server. FreeRADIUS is available as a package in OpenWrt, but configuring a full FreeRADIUS server is not a straightforward task, and LuCI doesn’t have a web interface to configure it.

Note that there is a third option that lets you write pure UCI configuration to set up PPSK (some argue that this isn’t “real” PPSK - I don’t know, but it does allow multiple PSKs to work on the same SSID, which is what I understand PPSK to be). You write it out in UCI, and OpenWrt generates the -psk- and -vlan- files correctly for you. I use this and prefer it, although LuCI doesn’t support these sections and don’t show anything about it. Here is my wireless configuration with edits:

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'untrusted'
        option mode 'ap'
        option ssid 'One SSID to rule them all'
        option encryption 'psk2+ccmp'
        option key 'theKeyMyHumansUse'
        option dynamic_vlan '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'untrusted'
        option mode 'ap'
        option ssid 'One SSID to rule them all'
        option encryption 'psk2+ccmp'
        option key 'theKeyMyHumansUse'
        option dynamic_vlan '1'

config wifi-vlan
        option name 'iot1'
        option network 'iot1'
        option vid '51'

config wifi-station
        option key 'theFirstLongRandomString'
        option vid '51'

config wifi-vlan
        option name 'iot2'
        option network 'iot2'
        option vid '52'

config wifi-station
        option key 'longRandomStringNumber0'
        option vid '52'

config wifi-vlan
        option name 'iot3'
        option network 'iot3'
        option vid '78'

config wifi-station
        option key 'longRandomStringNumber1'
        option vid '78'

config wifi-vlan
        option name 'iot4'
        option network 'iot4'
        option vid '79'

config wifi-station
        option key 'longRandomStringNumber2'
        option vid '79'

config wifi-station
        option key 'longRandomStringNumber3'

config wifi-station
        option key 'longRandomStringNumber4'

config wifi-station
        option key 'longRandomStringNumber5'

I skipped the wifi-devicesections as they don’t need any specific settings for this. Along with this I have several network interfaces added in /etc/config/network named untrusted, iot1, iot2, iot3 and iot4. Each IoT device that only needs to access the internet has its own iot* network to live in, as I neither trust them to talk freely to my regular devices nor each other. Some devices do need to be on the same network as my normal clients for things like AirPlay and Chromecast to work well. So my human users connect to the SSID with theKeyMyHumansUse and the AirPlay/Chromecast devices connect with the passkey listed in one of the last three wifi-station sections. These last sections simply attach to the default_radio* interfaces, as there is no wifi-vlan section linked to them to connect to a different VLAN.

One thing to be aware of with this configuration is that LuCI doesn’t think the dynamic_vlan option should be set since it assumes it is only linked to the PPSK-with-RADIUS settings, so dynamic_vlan will be deleted if you edit the wireless configuration in LuCI after setting this up.

4

Thank you,

So my assumption was correct that LuCI doesn’t support non-RADIUS-based PPSK configuration. I’m asking this just to make sure, since I’m not an enterprise/advanced user where RADIUS-based PPSK setups are the norm.

By the way, your write-up was already quite clear, and I picked up some new info from you about how you configured non-RADIUS PPSK on OpenWRT via UCI. But unfortunately there’s one thing missing, so I have to ask you one more question: which OpenWRT version were you using when you did this setup?

5

I run recent snapshots of the main branch, but I have used this for between two and three years. It should certainly work in both 24.10 and 25.12. Support for this format was introduced back in 2020 so it could possibly work as far back as 22.03 and 21.02. Note that this feature does have some compatibility issues, for example it didn’t work with WPA3 for a long time, there have been commits to support WPA3 in the last year I think, but I still run WPA2 as I understand psk2+ccmp with long keys to be reasonably secure.

6

That commit is a small part of a back-then long-running PPSK saga. The UI reflects what the underlying system was known to support (i.e. only RADIUS for PPSK in that commit).