802.11 krv fast roaming test

[chrisliush]

I am testing 802.11krv fast roaming with 2 APs. I have 2 APs and 1 client.

Currently it seems, only when associated AP disconnect, for example beacon lost (disconnect power supply), so client will switch to another AP.
Ideally I think AP should detect RSSI, if the RSSI is lower than threshold, client will switch to another one, so that no more packets loss, this is the purpose of fast roaming.

My understanding, from 802.11krv, the behavior should like below:
(1) current associated AP detect RSSI lower than threshold, it will inform client for potential switch
(2) client will send neighbor request and receive neighbor report
(3) ....

After searched, somebody says:

A) in the wirelss interface configuration,

 RSSI threshold for joining 
            0 - not using RSSI threashold
            1 - do not chane driver default

in my case, I installed OpenWrt 22.03, no this options via LuCI interface.

B) adjust below parameters.

    option signal_connect “-50”
    option signal_stay “-60”
    option signal_strikes “3”
    option signal_poll_time “5”
    option signal_drop_reason “3”

LuCI doesn't those parameters, so I have to set those with command line, right ?

If so, the question:
(1) these parameters are all the parameters to tune for fast roaming ?
(2) Is there document to explain those parameters ?

[psherman]

The first, and most important thing to do with your wifi setup is to optimize it for operation without 802.11k/r/v. This will make your traditional roaming performance as good as it can be, and it is foundational. Roaming in this context is a client side operation... while APs can kick a client off based on minimum RSSI and other similar metrics, it is not the preferred method.... proper tuning of each radio is the way to do this.

So start here... I like this video from Crosstalk Solutions as an explainer for how to optimize your wifi. Once this is done (with 802.11k/r/v/), you should see your clients roaming fluidly between the APs. Then you can experiment with the supplimental standards.

[chrisliush]

yes, completely agreed. The first thing is to make traditional roaming performance. In fact, we did this for long time, say many years. Now want to test/verify 802.11krv, how well the performance to improve, if it can meet the requirement.

[chrisliush]

Client is running wpa_suppliant.
conf file set to

bgscan="simple:1:-65:3"

it seems trigger scanning when the signal is below -65, however, it cannot roam to another better RSSI AP, until the current associated AP is gone
Is there others parameters need to check ?

[chrisliush]

check wpa_supplicant log, it did attempt to roam another better RSSI AP, but fail with status code 53:
invalid PMKID. Why? Key should be correct. since client can connect to any 2 of AP if one is gone.

 WIFI1: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-51 noise=-105 txrate=1000
 WIFI1: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-49 noise=-105 txrate=1000
 WIFI1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-64 noise=-105 txrate=1000
 WIFI1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-68 noise=-104 txrate=1000
 WIFI1: SME: Trying to authenticate with yy:yy:yy:yy:yy:yy (SSID='OpenWrt' freq=2412 MHz)
 WIFI1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
 WIFI1: CTRL-EVENT-AUTH-REJECT yy:yy:yy:yy:yy:yy auth_type=2 auth_transaction=2 status_code=53
 WIFI1: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='OpenWrt' freq=2422 MHz)
 FT: Failed to set PTK to the driver
 WIFI1: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='OpenWrt' freq=2422 MHz)
 WIFI1: Associated with xx:xx:xx:xx:xx:xx
 WIFI1: WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=CCMP]
 WIFI1: CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=0 id_str=]