(When the parameter variables were implemented in LEDE), you actually do not need to change more than one or two defaults to get roaming to just work. WPA3 and SAE is another story... use psk2+ccmp.
Each AP wifi-iface entry needs wpad (full) installed and the following which enables 802.11r features:
option ieee80211r '1' # enable FT
option mobility_domain "4f57" # defaults to "4f57" if left empty - so leave it empty (00004f577274 = OWrt in ASCII ;)
option nasid '704F579E84A4' # give the AP a unique ID - same as its MAC
option ft_over_ds '0' # don't use wired distro system, use over the air (faster)
option ft_psk_generate_local '1' # greatly reduces complexity of config
The following settings assist in speeding up association:
option rsn_preauth 1 # only works if used on an I/F which is a bridge (Wi-Fi is a bridge to a LAN)
The following settings help kick any 'sticky' client off when its RSSI is 'too low' - i.e. helps it to roam:
I was using 2x RT3200 at home. One, as a main router and one, as dumb AP. I set them up by reading a lot of comments in the forum about k,v,r protocols.Roaming was fine except with my corp laptop, which disconnected MS Teams meetings for 3-5 seconds when moving around the nodes.
I put x86 between both RT3200 (making them dumb AP) without changing any wireless setup at both of them- and now I do not have any disconnects to the same laptop and same app. So if I can explain myself this behavior - I can contribute to the wiki as well.
Kr
K.
Have you read my post above? PMK-R0 is what the client and the AP derive from MSK. This key stays the same for the whole time the client is associated with any AP while roaming. From R0 a set of new keys - R1 is generated for each AP requesting it. R1 is AP specific and used to authenticate with the new AP.
I learned what r1kh and r0kh is, and just with that I don't want to jump to conclusion what PMK is. And this part I didn't understand before, what R0 and R1 signified:
And the next thing I asked on my last comment is, what does that have to do with my WireGuard connection failing when I roam back to my first AP?
I found this a long time ago - you can use if for all of the scenerios discussed to simplify your calculations for the values
As for the other settings everyone has done a great job explaining them. I just remember my rule - generate locally = psk types, otherwise no generate locally.
I don't know what device you are using wireguard on, but generally, one of it's headline features is that it like QUIC should survive changing the connected network entirely - including reconnecting to the same network. It does so on all my linux pcs and android phones.
PMKSA is a map Station ID to PMK keys (R0,R1,PTK) caching them so they don't need to be recomputed each time a station re-connects.
Wireguard's official Android app (Go implementation). But the behavior persists over other implementation as well, like Cloudflare 1.1.1.1 app (for its Warp service) and Proton VPN.
Funny thing is, when I get back home and it connects to WiFi, WireGuard just works, no need to disconnect, reconnect, anything. But just as I roam AP, this thing happens. I go into more detail and circumstance of this behavior in this thread—that I couldn't figure out what's going on and couldn't find documentation is why this thread came to be.
Install one of the following full wpad packages
i) wpad-openssl
ii) wpad-wolfssl
iii) wpad-mbedtls
iv) ^ the mesh versions of the above packages
v) wpad - similar but doesn't seem to include SAE support
Question - Are we sure that the basic wpad variants aren't sufficient, because the package description of them often mentions "802.11r and 802.11w support, [0][1] ?
Under each AP wifi-iface entry add the following
option ieee80211r '1' # enable FT
option nasid '704F579E84A4' # give the AP a unique ID - same as its MAC
option reassociation_deadline '20000' # as per https://github.com/openwrt/openwrt/issues/7907
Confusingly, even without nasid roaming seems to work for me , I assume this was because ft was working but 11r wasn't. Perhaps something like set_default nasid "$(echo "$macaddr" | tr -d ':' | tr 'A-F' 'a-f')" should be added - as suggested here).
Users should also consider setting
option rsn_preauth 1 # only works if used on an I/F which is a bridge (Wi-Fi is a bridge to a LAN) but this likely depends upon a RADIUS server being available on the network.
Basic wpad is absolutely enough for 11r, not sure about 11w but since it's part and parcel of WPA3 which works with basic wpad, I'd conjecture you don't need more.
NAS ID is automatically generated (using BSSID), as are the mobility domain and the R1 and R0 keys. So really, whether it's WPA2 or WPA3, it's just toggling 11r, and an aditional workaround, ft_psk_generate_local 0 if you're using SAE. With just that, roaming will Just Work™.
Oh, and option reassociation_deadline '20000' for fruit company products.
Where does that happen on 23.05.x, is it done within wpad/hostapd itself as unless I explicitly specified a nas id it didn't end up in the hostapd configuration seen in /tmp/run/*.conf ?
I'm not sure, sorry. I did come across an explainer about patching something in OpenWrt to do it, and I tried to find it while making my last reply but I couldn't find and cite it.
It's not complicated at all—when you finally understand what's going on, that is. And that's why documentation is necessary to allay any FUD. It doesn't help that nothing on LuCi indicates that the rest of the WLAN roaming tab is only optional, only necessary when you know what you're doing. And if you're doing it over SSH and config files, there are no documentation to refer to besides only the relevant options.
My saltiness aside, I think we've gathered here a pretty good explainer what all the options mean and how to do very basic/minimal configuration, workarounds for WPA3-SAE, etc. Maybe we can go ahead and make a dedicated wiki page? Does anyone have permission for wiki here?
The introduction can be what's the basic requirements for currently supported OWrt (wpad-basic), a link to dumb AP set up page, and finally enabling 11r (toggling on LuCi or option ieee80211r '1').
Workaround section for Apple devices (Reassociation Deadline/option reassociation_deadline '20000'), and for WPA3-SAE (Generate PMK Locally/option ft_psk_generate_local 0). Of course, this section specially needs to be more up-to-date with OWrt changes for changed defaults or fixed bugs.
Finally, an advanced section explaining NAS IDs, Mobility Domains, the keys, etc. And other options that influence 11r like option disassoc_low_ack 1, option rsn_preauth 1, etc. What they do, and under what scenarios they might be useful to manually configure them.
That has been my experience too, which makes me wonder whether the 'nasid' really does need to be set. What do you mean about 'ft' working but '11r' not working?
So do we definitely not need to specify the 'nasid' from 22.05.2?
, I assume this was because