Next steps now that Fast Transition is working again

Installing and Using OpenWrt Network and Wireless Configuration
1

Now that Fast Transition (802.11r) is working again, my attention moves on to further advances in my home WiFi setup. I'd like to adopt WPA3.

WPA3 requires Protected Management Frames (OpenWRT terms 802.11w Management Frame Protection). It seems that OpenWRT requires more than just the default wpad-basic-wolfssl for PMF. I have now replaced that with wpad-wolfssl and . Yet Analiti suggests that PMF is still "Not supported". This on BT Home Hub 5A (lantiq/xrx-200) & TP-Link EAP235-Wall & EAP615-Wall (both ramips/mt7621) devices.

With wpad-wolfssl, 802.11w MFP & WPA3 installed/enabled, WPA3 itself works despite the apparent lack of PMF, but my Android device doesn't roam at all well. It would rather drop back to mobile data than find the next access point as I walk through the house. The are no auth_alg=ft messages in any of my logs.

By the way, a surprising side effect of upgrading wpad is that the 3 802.11k Radio Resource Management options appeared in luci (Network ¦ Wireless ¦ Edit ¦ Interface Configuration - Advanced Settings). Before I had to enable this in /etc/config/wireless with option ieee80211k '1' (plus option rrm_neighbor_report '0' & option rrm_beacon_report '0' if these 2 options aren't desired - unusually an absence of these entries enables the option(s)). Analati had already reported this as supported when enabled in config. It seems luci thinks that 802.11k RRM requires more than wpad-basic when this isn't a strict requirement.

That said 802.11k RRM lists don't seem to be populated on their own via radio measurements. Likely too early for me to give up on https://github.com/simonyiszk/openwrt-rrm-nr-distributor.

Has anyone gotten WPA3 working with Fast Transition? How about 802.11k RRM?

UPDATE: Further testing suggests that neighbor report via radio management doesn't actually populate the RRM neighbor report. Same for beacon report, although the latter relies on client (STA) functionality so can't be sure that my device isn't to blame. Thus reliance on rrm-nr-distributor plus option rrm_neighbor_report '0' & option rrm_beacon_report '0' remains sensible. And that I can go back to wpad-basic-wolfssl without missing anything important.

4 Likes
2

Very interested in your findings. I have observed the same: my Android phone does not roam at all, I'm using a mixed WPA2/WPA3 configuration. I've been doing tests but I didn't get to anything.

3

My phone reports WPA2 and WPA3 SSIDs as different networks by showing both of them in the SSID list, and refuses to roam between them. You should use the same encryption method on all SSIDs.

4

When I say I'm using WPA2/WPA3 mixed configuration, what I mean to say is that I have "WPA2-PSK/WPA3-SAE MIXED MODE" selected as encryption, in both APs.

5

@andybjackson can you expand on this statement?

"now that Fast Transition is working again"

Is this due to a broken master code train or that you had to configure something to make it working again?

3 Likes
6

Have updated my post with link to reporting of the change here: Daemon.err hostapd: nl80211: kernel reports: key addition failed - is this a problem? - #53 by andybjackson

2 Likes
7

FT is now working with WPA3 for me. Generate PMK couldn't be selected, in addition to underlying changes, it's seems.

In fact, the generate PMK option tickbox has now disappeared from the Luci network config page.

Key addition failed message still appears in the log, but seems to cause no observable problem.

Wonderful. Thanks all.

1 Like
8

Do you have sample wireless files you could share of your working configuration?

9

I haven't done anything unusual to get SAE (WPA3) to work with FT (802.11r). Mostly chose the appropriate options & left everything else blank.

802.11k takes a little more work in my experience. But that's a separate topic already will covered elsewhere in this forum and above in this thread.

/etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '5'
        option band '2g'
        option htmode 'HT20'
        option country 'GB'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'SSID'
        option encryption 'psk2'
        option key 'PASSWORD'
        option ieee80211k '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option channel '161'
        option band '5g'
        option htmode 'VHT80'
        option country 'GB'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'SSID'
        option encryption 'sae'
        option key 'PASSWORD'
        option ieee80211r '1'
        option ieee80211k '1'
        option ft_over_ds '0'
10

11k options require wpad not basic, just remove them.

11

Except the I use https://github.com/simonyiszk/openwrt-rrm-nr-distributor to populate the Neighbor Reports & this seems to work and be helpful in practice.

Am I missing something? Is wpad (vs. wpad-basic) required both to put out 802.11k NRs AND to work out what they should be? Or is it just the latter?

12

Only wpad (package: e.g. wpad-mbedtls) supports 802.11r/k/v; you need an additional daemon to provide the roaming information like usteerd (packages: luci-app-usteer usteer) or dawn (luci-app-dawn dawn); they must be configured.

1 Like
13

The description of wpad-basic-mbedtls in Luci's System ¦ Software is:
This package contains a basic IEEE 802.1x/WPA Authenticator and Supplicant with WPA-PSK, SAE (WPA3-Personal), 802.11r and 802.11w support.

So 802.11r should be included. Further, I suspect 802.11k also works as long as you have a parallel method to specify the neighbours. I say this because various client tools report Neighbour Reports as being present. Wireshark and some appropriate filtering should be definitive, and is my next step. Unless @Double-G clarifies further.