Documentation on 802.11r

[oxwivi]

Where can I find documentation on 802.11r? As far I can tell, the only thing on wiki about roaming is small section in the Wi-Fi setup guide. The entire page is about different options and value that can go into /etc/config/wireless and while I don't expect any explanation on this specific page for the feature, there doesn't appear to be any page that explains what 802.11r needs for it to work. Besides the toggle to enable it, what do the other options do and under what circumstances do I need to use them?

The reason I bring it up is because I've hit a dead end on my setup to roam without having my VPN connection broken up. It's only recently that I learned that there's an almost two year old open bug on 802.11r not working with SAE. And I only learned of this issue after coming across a few forum topics discussing roaming and WPA3, and there are even workarounds, like this and this—both are using the same method, IIUC.

Again, the knowledge was gained from googling; searching "fast roaming" on the wiki only brings up text from changelog pages and "802.11r" brings up a result that can take you to the aforementioned option and values page in Wi-Fi /etc/config/wireless. I don't know if there is any existing page and documentation on fast roaming, but search results certainly doesn't come up with anything. I don't want to flood the forum with what might be basic questions, but I don't know what and where to learn to come up with the workarounds I linked earlier.

TL;DR I want to RTFM, but there doesn't seem to be any FM.

[Falco]

I do not know about the official documentation but I've configured my fast roaming according to OneMarcFifty's excellent Openwrt videos. Maybe it helps you as well.

CHEAP WI-FI MESH ALTERNATIVE with fast roaming OpenWrt Wi-Fi Access points

[Lynx]

@oxwivi

TL;DR I want to RTFM, but there doesn't seem to be any FM.

Hahaha. That's pretty much OpenWrt and I don't blame anyone at all. Writing documentation is utterly boring and takes time away from the fun stuff. Since those that work on OpenWrt are almost all unpaid and doing it for fun, it's to be expected that there is no manual. I have some first-hand experience of this based on my various OpenWrt projects like cake-autorate and adblock-lean.

There is a wiki, and feel free to spend hours providing guidance for others based on your experiences dealing with 802.11r when you've got it all working. But you might want to skip that since once you've got it working you'll probably rather be doing else like walking the dog or going for a run.

[oxwivi]

@Falco

I do not know about the official documentation but I've configured my fast roaming according to OneMarcFifty's excellent Openwrt videos. Maybe it helps you as well.

I've watched it, but he basically just sets up dump AP and toggles 802.11r in LuCi. No offense to the guy, but that could've been a 10 min video and he doesn't really explain what setting does what.

[oxwivi]

@Lynx

Hahaha. That's pretty much OpenWrt and I don't blame anyone at all. Writing documentation is utterly boring and takes time away from the fun stuff. Since those that work on OpenWrt are almost all unpaid and doing it for fun, it's to be expected that there is no manual.

You're right, and I agree with you, as a volunteer project, devs are free to do whatever TF they want. I'm just bemoaning the fact there are a variety of knowledge but pretty much scattered over the forums. I mean, if at least the options were explained somewhere, I could've pieced together something. And referencing the forum posts in a central wiki page could be a skeleton for a full-blown explainer like guest Wi-Fi, dumb AP, etc wiki pages.

Mad respect to however TF Arch Wiki manages to do its thing.

[Lynx]

It's true. Happily the forum does work very well and there is such a huge army of rather gifted nerds here that if you put on your query you'll see responses within minutes typically.

[oxwivi]

Ugh, while that's lovely for a community, personally I hate the redundancy. And, eventually, even the most enthusiastic contributor will tire of answering basically the same question but worded differently over and over again.

Anyway, if this thread gets enough attention, if everybody familiar with 802.11r could contribute the part they know, I'm happy to volunteer my time to compile a proper wiki page.

[Lynx]

This 802.11k and 802.11v stuff could be woven in perhaps:

Proper configuration of 802.11k and 802.11v

For enablement of 802.11k and 802.11v across my three dumb APs, I have followed this guide as I also use Usteer: https://openwrt.org/docs/guide-user/network/wifi/usteer?s[]=usteer#configure_80211k_and_80211v_on_all_ap-nodes There was some recent discussion around this in this thread as well: Instead of taking that thread more off-topic, I wanted to kick off this thread to gather input from the community on the proper configuration for enabling 802.11k+v. Here is a snippet of my current confi…

[zekica]

I might be wrong, but, a quick intro to 802.11r would go like this:

WPA2-PSK:

• MSK is deterministically calculated using the SSID and the PSK
• PMK-R0 is deterministically derived from the MSK (I think also using the mobility domain specified)
• a client does a four-way-handshake with the AP and PMK-R0 is provided to the client
• PMK-R1 is deterministically calculated from PMK-R0 and the BSSID for each AP, but R0 cannot be calculated from R1
• there are also PMK-S0 and S1 - equivalents for the station
• when roaming, the client proves that he knows (derives is from PMK-R0 it got during the initial authentication and the BSSID) the PMK-R1 to the second AP using a 4-way FT authentication
  • this can be done over-the-air (talking directly to the second AP) - client disconnects from the first one and does the 4-way FT authentication
  • this can be done over-ds (first AP relays messages to the second one) - client is still connected to the first one and after FT over DS completes, he is already associated so just starts exchanging data via the second AP
• since the keys in WPA2-PSK can all be calculated independently just using SSID, PSK (and possibly mobility domain), "Generate PMK locally" can work and no communication is required between the APs

When using WPA2-EAP, WPA3-EAP, WPA3-SAE or OWE, in all three cases MSK is not a static value calculated from the SSID and the PSK, but assigned to each station separately - either after SAE or 802.1x authentication completes.

So then in any case except WPA2-PSK, "Generate PMK Locally" cannot work as other APs don't know the MSK.

To use 11r without the option above, you need to set up a way for hostapd on each of the APs to talk to one another. They do it by exchanging R1 keys via the backbone (11s mesh, wds or wired). The following hostapd configuration options are relevant:

• ft_over_ds=[0 | 1] - specifies whether hostapd should (advertise support for and) relay FT 4-way handshake to the target AP
• reassociation_deadline=20000 - max time in 1024th parts of ms - this is 19.53ms for the FT handshake to complete
• r0_key_lifetime=10000 - how long to cache R0 for the station
• pmk_r1_push=1 - whether to immediately push R1 to all known roaming APs whenever a new station connects
• r0kh=ff:ff:ff:ff:ff:ff * 0123456789abcdef0123456789abcdef - this parameter specifies from APs to accept R1 keys from - and specified a key. This key can be 128bit or 256bit. New hostapd versions always use 256bit keys and if you specify a 128bit key a 256bit one will be calculated from it
• r1kh=00:00:00:00:00:00 00:00:00:00:00:00 0123456789abcdef0123456789abcdef - this specifies what APs to send R1 keys to

The values above with ff, * and 00 are special as they allow dynamic discovery of other APs on the ethernet segment.

Hostapd uses a non-standard protocol to communicate R1 keys and is not compatible between 19.07.x and earlier and versions used in 21.03.x and later.

Why 11r doesn't work in hostapd when management frame protection is enabled (required for WPA3), I'm still not sure.

[oxwivi]

@zekica

ft_over_ds=[0 | 1] - specifies whether hostapd should (advertise support for and) relay FT 4-way handshake to the target AP

IIUC, this parameter should be 1 so as to let APs talk to each other, correct? (In case of WPA2-EAP, WPA3-EAP, WPA3-SAE or OWE)

@zekica

• reassociation_deadline=20000 - max time in 1024th parts of ms - this is 19.53ms for the FT handshake to complete
• r0_key_lifetime=10000 - how long to cache R0 for the station
• pmk_r1_push=1 - whether to immediately push R1 to all known roaming APs whenever a new station connects

Are the defaults fine for most cases? From your description, I can't figure out what kind of situation might need me to mess around with those values.

@zekica

• r0kh=ff:ff:ff:ff:ff:ff * 0123456789abcdef0123456789abcdef - this parameter specifies from APs to accept R1 keys from - and specified a key. This key can be 128bit or 256bit. New hostapd versions always use 256bit keys and if you specify a 128bit key a 256bit one will be calculated from it
• r1kh=00:00:00:00:00:00 00:00:00:00:00:00 0123456789abcdef0123456789abcdef - this specifies what APs to send R1 keys to

Sorry, I still don't understand. Is r0kh AP's MAC address and a common key? Do I need to edit the MAC address of every other AP in the network? Do you have any live roaming network set up, can you show me a screenshot of how r0kh and r1kh values show in the WLAN roaming tab?

Also, in the workaround post that I linked, you mentioned some documentation automatically generating for user; what documentation were you referring to?

@zekica

Why 11r doesn't work in hostapd when management frame protection is enabled (required for WPA3), I'm still not sure.

A comment in the bug report says 11w and WPA2 was working in 23.05-rc3.

[Lynx]

I think this highlights the difficulty of coming up with comprehensive documentation. It reminds me of the 3GPP standards - see here:

The 3GPP's System of Parallel Releases

https://www.3gpp.org/ftp/Specs/latest

This only exists because corporates fight over it by endeavouring to patent as many elements of the standard as possible, and each incremental change to the standard is therefore a very hot topic. Such motivation to document in meticulous detail will never exist in a non-commercial context.

[hnyman]

@oxwivi

Are the defaults fine for most cases? From your description, I can't figure out what kind of situation might need me to mess around with those values.

Some clients have trouble with the defaults.

I have got 802.11r roaming for WPA2 working nicely by

• changing some of the defaults,

802.11r Fast Transition how to understand that FT works?

Just documenting here, that I got the 802.11r functioning after I increased the reassociation_deadline to 20000 (from the default of 1000), based on advice from the discussions at Rekeying Issue - “driver can’t safely do that.” - #18 by dsouza and https://bugs.openwrt.org/index.php?do=details&task_id=3159 . My Android 11 tablet roamed between ipq806x/R7800 with ath10k-ct wifi in 802.11ac mode (VHT160) mt7622/RT3200 with mt76 wifi in 802.11ax mode (HE80) (So the even AC/AX mode differen…

• by defining fixed MACs to all relevant interfaces in all three related routers, as wifi drivers may change the MAC when you have multiple SSIDs enabled for a radio, and
• by providing fixed r0kh and r1kh data for all of them. (note that r1_key_holder reflects each router's own MAC in each router. otherwise same on each router)

Screenshot from one of my routers:
(note, a few WPA3 related unncessary options like sae_pwe and ocv are showing due to old experiments)

[oxwivi]

@hnyman

• by defining fixed MACs to all relevant interfaces in all three related routers, as wifi drivers may change the MAC when you have multiple SSIDs enabled for a radio, and
• by providing fixed r0kh and r1kh data for all of them. (note that r1_key_holder reflects each router's own MAC in each router. otherwise same on each router)

If I'm understanding this correctly, r1_key_holder should be each radio's BSSID (without the colons). And for r0kh and r1kh, I need to enter all APs on the network, including itself.

[zekica]

@oxwivi

this parameter should be 1 so as to let APs talk to each other, correct?

No, APs talk to each other always unless if Generate PMK Locally is enabled.

FT Over DS is only for clients to do FT handshake before disconnecting from the original AP.

@oxwivi

Are the defaults fine for most cases?

Everything except reassociation deadline, is fine. iOS and macOS devices won't work with the default value of 1000.

In hostapd R0KH is the AP you connected to intially. R1KH are all APs.

[oxwivi]

@zekica

In hostapd R0KH is the AP you connected to intially. R1KH are all APs.

I see. Then I should be fine following @hnyman's example in the his screenshot?

[oxwivi]

Thank you all for the help. I'm about to try it now, so I've one last clarification to make. I have a single 2.4GHz broadcasting on just main AP/router. I guess, this interface will have to be added alongside the 5GHz from the same device?

[oxwivi]

This is the config I ended up with (did it all on LuCi); this is the first AP:

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'Redacted SSID'
        option key 'redactedpsk'
        option encryption 'sae'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '0'
        option nasid 'E8:9F:80:5D:37:2B'
        option r1_key_holder 'E89F805D372B'
        list r0kh 'E8:9F:80:5D:37:2B,E8:9F:80:5D:37:2B,0000000000000000000000000000000000000000000000000000000000000000'
        list r0kh 'E8:9F:80:5D:37:2C,E8:9F:80:5D:37:2C,0000000000000000000000000000000000000000000000000000000000000000'
        list r0kh 'E4:C3:2A:47:4A:3B,E4:C3:2A:47:4A:3B,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E8:9F:80:5D:37:2B,E8:9F:80:5D:37:2B,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E8:9F:80:5D:37:2C,E8:9F:80:5D:37:2C,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E4:C3:2A:47:4A:3B,E4:C3:2A:47:4A:3B,0000000000000000000000000000000000000000000000000000000000000000'
        option reassociation_deadline '20000'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'Redacted SSID'
        option key 'redactedpsk'
        option encryption 'sae'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '0'
        option nasid 'E8:9F:80:5D:37:2C'
        option r1_key_holder 'E89F805D372C'
        list r0kh 'E8:9F:80:5D:37:2C,E8:9F:80:5D:37:2C,0000000000000000000000000000000000000000000000000000000000000000'
        list r0kh 'E8:9F:80:5D:37:2B,E8:9F:80:5D:37:2B,0000000000000000000000000000000000000000000000000000000000000000'
        list r0kh 'E4:C3:2A:47:4A:3B,E4:C3:2A:47:4A:3B,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E8:9F:80:5D:37:2C,E8:9F:80:5D:37:2C,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E8:9F:80:5D:37:2B,E8:9F:80:5D:37:2B,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E4:C3:2A:47:4A:3B,E4:C3:2A:47:4A:3B,0000000000000000000000000000000000000000000000000000000000000000'
        option reassociation_deadline '20000'

I tried to be clever and have the NAS ID the same as my BSSID and then r0kh and r1kh would be the same. The second AP:

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'Redacted SSID'
        option encryption 'sae'
        option key 'redactedpsk'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '0'
        option nasid 'E4:C3:2A:47:4A:3B'
        option reassociation_deadline '20000'
        option r1_key_holder 'E4C32A474A3B'
        list r0kh 'E4:C3:2A:47:4A:3B,E4:C3:2A:47:4A:3B,0000000000000000000000000000000000000000000000000000000000000000'
        list r0kh 'E8:9F:80:5D:37:2C,E8:9F:80:5D:37:2C,0000000000000000000000000000000000000000000000000000000000000000'
        list r0kh 'E8:9F:80:5D:37:2B,E8:9F:80:5D:37:2B,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E4:C3:2A:47:4A:3B,E4:C3:2A:47:4A:3B,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E8:9F:80:5D:37:2C,E8:9F:80:5D:37:2C,0000000000000000000000000000000000000000000000000000000000000000'
        list r1kh 'E8:9F:80:5D:37:2B,E8:9F:80:5D:37:2B,0000000000000000000000000000000000000000000000000000000000000000'

[oxwivi]

Preliminary observation: for the first time, my phone hitched on connecting to second AP. (Disconnected for a few seconds and reconnected to next AP) Returning to first AP, phone seems to seamlessly transition, Wi-Fi signal just changed from weak to strong, no hitching in-between. But my WireGuard connection didn't survive.

Withholding final judgement until I've experience this for a few days.

[zekica]

Returning to first AP - I'm not sure but you may already have PMK-R0 for the device in PMKSA (PMK Security Association).

[oxwivi]

I'm sorry, what is PMK-R0? Where and what can I do about it? Is that what's potentially killing my VPN connection? Because non-VPN connection appears to work fine (as they did before trying 11r).

As an aside, I came across this post while googling for PMK-R0. It says OpenWrt could've generated key by itself. Does it work as intended?