802.11r and supported Encryptions

I just configured a few devices with 802.11r active ( ieee80211r set to '1') and it didn't work at all. Devices stayed for ever on an Access Point.
Then I changed the encryption from 'sae-mixed' to 'psk2' and it worked perfectly (it was some hint somewhere that not all encryptions were supported).

Is there somewhere a list of supported encryptions against 802.11r?
And is that limitation against the standard of 802.11r or a 'choice' in Openwrt?

Walter

supported ciphers and 802.11r are two separate things

things is 802.11r:

which wifi encryptions have been implemented:

ps: at most errors are detected (lack of connections) if high wpa3 encryptions are chosen with 802.11r activated (which depend on the hardware used or due to the lack of drivers optimized for that specific hardware)

openwrt document:
https://openwrt.org/docs/guide-user/network/wifi/basic

if you look there are "Warnings" on some 802.11r options that depend on documented hardware/software problems:
https://openwrt.org/docs/guide-user/network/wifi/basic#fast_bss_transition_options_80211r

1 Like

802.11r won’t help with this. It only allows devices to switch between WiFi networks much faster (ms vs seconds). It isn’t needed per se for a device to switch between access points or bands. Device itself decides when to do that. Unfortunately some devices don’t like to roam until they completely loose signal.

What devices are affected? Describe some scenarios. For example: Brand SmartPhoneModel 123 is connected to 2.4 with signal -56. I want it to connect to 5 GHz that has signal -70 in this place. Use apps on phone to determine signal strength.

I would also have expected this; but by adapting the encryption on the Access Point, roaming really started to work. Before it was useless: from there my question on the relation between 802.11r and encryptions options.

Tested on devices: Android Samsung S23, and a Lenovo Laptop running Linux.
When not working the devices would just jump when the wifi really just was so bad, it didn't work anymore, (like on -85dB is still was staying connecting).

A bit strange I'd say. Roaming should work without 802.11r enabled. It'd just take longer time to switch between networks.

Did all your wifi networks had exactly the same name (SSID), encryption and password earlier? Also 802.11w Management Frame Protection might need to be set to the same value for all networks between which you want to roam. The most sure way to ensure these all match is to look at the settings in /etc/config/wireless for each access point.

1 Like

In the latest master sae-mixed works with 802.11r. It was fixed some time ago. I'm using it.

EDIT: the problem of devices that don't roam, you need to use some app like usteer. I had the same problem and fixed with this.

1 Like

Yes. I only changed the encryption as described (on 4 access points in a mesh 802.11s).

Apperently no extra app needed...

No apps or packages or special techniques are required for normal roaming.

The very first step in roaming is to make sure your APs are all tuned properly. This means:

  • Setting non-overlapping channels for all neighboring APs
  • Ensuring good placement within the space
  • Adjusting power (almost always reducing it) to minimize the overlapping area and to encourage devices to roam sooner.

802.11r works on top of a good foundation of the above, so if this is not completed as a prereq, roaming will not work well.

I always recommend disabling 802.11r and concentrating on the AP tuning first until it performs well. Done correctly, this can result in roaming that is nearly seamless. Only then should one enable 802.11r, and only do this if there is a need for further improvement. Why? Because some client devices still don't play well with 802.11r enabled, so better to have a classical situation that works well than to add standards that cause some devices to behave poorly.

Also, don't use mixed mode sae-mixed... choose either WPA2 or WPA3. Again, this comes down to a client issue where some devices don't work properly when mixed mode is enabled.

3 Likes

Shouldn't the 'auto' setting do that?

Ideally, yes... but it's always better to set your channels manually.

2 Likes

Yes, that is what some people say ... I've several phones, some roam alone, without help, but others not. Some of them only roam when they lost totally the signal. The only way to make them change of AP is with some help like usteer. I tried without it for months without luck.

To be clear, usteer, 802.11r, and other roaming 'enhancements' are not required for roaming to work. Roaming itself is a client side process, and it relies on the proper tuning of the APs that I mentioned earlier. Most commonly, client devices will 'hang on' to a distant AP longer when the AP's power is set too high. But for devices that don't roam well, that is a function of the roaming logic on the device itself. In some limited cases, that can be improved with these additional methods, but the biggest gains are made in properly tuning the APs in the first place.

When a device, with signal of -80, does not change to the AP that is at one meter of distance, yes, the device is doing it wrong, but it's what happens with my old Pixel 4 or the Pixel 3a. In this cases usteer is mandatory in my opinion.
802.11r is an extra, not mandatory. But in my case all my devices work right with it, I had one tv with problems but an update fixed it. So enabling it makes roaming perfect.

To expand on this, users just can't use "Generate PMK locally" like with WPA2, you have to use the r0 and r1 key approach.

The commit shows both WPA3-SAE and WPA2/WPA3 Personal Mixed fixed for 802.11r:

2 Likes

I agree, the basis is proper tuning, and a really ill behaved client cannot be helped other than kicking them off (which is a really bad idea). But 801.11k/v do help the clients by e.g. providing a list of APs and frequencies, which should limit the amount of scanning needed to be done.

In reality, they are not kicked off (it's an option, but not the only). But usteer sends a beacon asking the device to "scan" when the signal is low, thing that some Android for some reason didn't do by itself. After this scan the device decides to change from AP, as expected.

I know dawn and usteer can advice clients to start scanning via hostapd, but the point is, if the client is ill behaved it likely just ignores the request and will just do what it likes. My point was, they can then instruct hostapd to kick clients off, im just saying i would not go that way. I think especially 802.11r and 802.11v can really help with roaming, adding too much intelligence on top of that I would not do. Excessive scanning may also drain battery etc.