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 configuration:

Wireless Config Snippet
config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/18000000.wmac'
	option band '2g'
	option htmode 'HT20'
	option country 'US'
	option cell_density '0'
	option log_level '1'
	option channel '11'
	option txpower '6'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option band '5g'
	option country 'US'
	option cell_density '0'
	option he_bss_color '30'
	option htmode 'HE80'
	option log_level '1'
	option channel '157'
	option he_su_beamformer '1'
	option he_su_beamformee '1'
	option he_mu_beamformer '1'
	option he_mu_beamformee '1'
	option txpower '19'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option key '<redacted>'
	option dtim_period '3'
	option ssid '<redacted>'
	option ieee80211r '1'
	option ft_over_ds '0'
	option ft_psk_generate_local '1'
	option reassociation_deadline '20000'
	option ieee80211k '1'
	option time_advertisement '2'
	option time_zone 'GMT0'
	option wnm_sleep_mode '1'
	option bss_transition '1'
	option rrm_neighbor_report '1'
	option rrm_beacon_report '1'
	option encryption 'psk2+ccmp'
	option ieee80211w '1'
	option max_inactivity '15'
	option mbo '1'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option key '<redacted>'
	option dtim_period '3'
	option ssid '<redacted>'
	option ieee80211r '1'
	option ft_over_ds '0'
	option ft_psk_generate_local '1'
	option reassociation_deadline '20000'
	option ieee80211k '1'
	option time_advertisement '2'
	option time_zone 'GMT0'
	option wnm_sleep_mode '1'
	option bss_transition '1'
	option rrm_neighbor_report '1'
	option rrm_beacon_report '1'
	option encryption 'psk2+ccmp'
	option ieee80211w '1'
	option max_inactivity '15'
	option mbo '1'
...
4 Likes

Thanks for posting this @_FailSafe. I suspect the significance of 802.11k and 802.11v is not that well understood by many OpenWrt users.

It seems like many of the settings listed in the usteer page are available in LuCi:

but perhaps not:

option rrm_neighbor_report '1'
option rrm_beacon_report '1'

FWIW, given my config posted in the OP, this is how the UI looks for my present setup:

1 Like

Do you think those settings should be enabled both for all access points and also WDS clients? Since LuCi has the same options for both.

No worries. This forum attracts many different great minds with all their nuances.

Do you happen to know whether it makes sense to enable these 802.11k and 802.11v settings for WDS clients?

2 Likes

I tried enabling 802.11k + v on WDS clients (set up as repeaters), it works in a mixed lab environment: Linksys E8450 + Netgear WAX202 + TP-Link Archer C7. I have tried that with WPA2 PSK only.

2 Likes

I wonder whether or when it makes sense to do so? I understand the idea behind the protocols and have an idea about what enabling it on access points will do, but I am less clear on the significance of enabling on WDS clients. Would the latter only make sense if the WDS clients were to be moving around (in which case mesh would presumably be the better choice?).

1 Like

OK, I misunderstood your question then.

See - when configuring a client, you can't actually enable or disable 802.11k + v, as these are options for hostapd, not for wpa_supplicant. What I was talking about is enabling these features on the AP that is bridged to that client to form a repeater.

Here's what confused me. Those features are listed in LuCi and presumably you can enter them in the wireless config too. Does the same apply for settings like DTIM?

Also on 802.11k and 802.11v in general, what do you think the best way to enable these protocols is in OpenWrt? It's a little unclear to me with so many differing bits and pieces of information. Like consider those GitHub commits linked above apparently rendering certain options unnecessary.

I wonder why things like this aren't just enabled by default. Makes me think of: 'tick me to improve performance' disabled by default.

2 Likes

dtim_period is mentioned in wpa_supplicant.conf template, but I think it still applies only for the AP mode (which wpa_supplicant has some limited support for).

Regarding the best practice, well, for me, it was to revert to a single-router configuration and accept a weak but clean signal in the place where my desktop is. All those multi-AP solutions have a downside that the clients have to scan in order to know the radio situation, and this leads to periodic lags.

With a new adapter (Alfa Networks AWUS036ACM) it is still enough for the 300 Mbps that I pay for. And in a single-AP configuration, 802.11k + v make no sense.

Thanks. OK who else can advise here? @bluewavenet can you advise how to best enable 802.11k and 802.11v on OpenWrt?

1 Like

Hmm OK - understood and thanks - but the OP is about how to best enable 802.11k and 802.11v. What are your recommendations on that?

1 Like

Sorry no.
Way back ~15 or so years ago 802.11k/v/r was going to be the new_exciting_best_thing_ever /s
Since those heady days not much has changed with very few if any client devices actually supporting "roaming" correctly and proprietary attempts coming and going, usually going into obscurity.

(Note: It is a different story with 802.11s mesh because we can guarantee the same implementation between nodes with OpenWrt.)

In my opinion and experience, careful tweaking of AP Tx power, channel and location can be made to work very well, whereas kvr config attempts are a waste of time.
If someone can show me otherwise, I will be very interested to see the details.......

4 Likes

Could you elaborate on which options are unnecessary? And are you speaking specifically about @Lynx's WDS configuration or generally?

I feel this thread is going to digress into very nuanced places if we are not careful with the various configurations we refer to here.

2 Likes

UPDATE Some of these questions are addressed here: Proper configuration of 802.11k and 802.11v - #5

I have each of my three APs configured with a different BSS color. If this is randomly assigned now, how do I know that random selection doesn't land the same value across my APs?

psk2 and psk2+ccmp both result in CCMP ciphers, do they not? I don't have a problem with psk2+ccmp today, but I suppose I could change it for the heck of it.

As for ieee80211w being enabled, if I am not having problems with it today, what would be the driver to disable it, then?

While I legitimately am not in the GMT timezone, my understanding is that as long as the time_zone on each AP was identical, life was good. What am I missing there?

As a related question to all of these posts, is there a way to sort of see the effect of 802.11k and 802.11v on terms of logs or so?

1 Like

in terms of logs - no. What you can do is to use a Linux device (e.g. a spare RT3200) and run iw dev wlan0 scan. 802.11k looks like this:

	RM enabled capabilities:
		Capabilities: 0x72 0x00 0x00 0x00 0x00
			Neighbor Report
			Beacon Passive Measurement
			Beacon Active Measurement
			Beacon Table Measurement
		Nonoperating Channel Max Measurement Duration: 0
		Measurement Pilot Capability: 0
2 Likes

Based off of _FailSafe's proposed configuration I managed to make it more likely to roam and easier. Works quite alright for me. At least it did last night (I reckon if WiFi generally is a bit mystical sometimes going against all odds and calculations then roaming is the black magic wizardy itself).

config usteer
  # The network interface for inter-AP communication
  option 'network' 'lan'

  # Log messages to syslog (0/1)
  option 'syslog' '1'

  # Disable network communication (0/1)
  option local_mode '0'

  # Use IPv6 for remote exchange
  option 'ipv6' '0'

  # Minimum level of logged messages
  # 0 = fatal
  # 1 = info
  # 2 = verbose
  # 3 = some debug messages
  # 4 = network packet information
  # 5 = all debug messages
  option 'debug_level' '2'

  # Maximum number of neighbor reports set for a node
  #option max_neighbor_reports 8

  # Maximum amount of time (ms) a station may be blocked due to policy decisions
  #option sta_block_timeout 30000

  # Maximum amount of time (ms) a local unconnected station is tracked
  #option local_sta_timeout 120000

  # Maximum amount of time (ms) a measurement report is stored
  #option measurement_report_timeout 120000

  # Local station information update interval (ms)
  #option local_sta_update 1000

  # Maximum number of consecutive times a station may be blocked by policy
  #option max_retry_band 5

  # Maximum idle time of a station entry (ms) to be considered for policy decisions
  #option seen_policy_timeout 30000

  # Minimum number of stations delta between APs before load balancing policy is active
  #option load_balancing_threshold 0

  # Minimum number of stations delta between bands before band steering policy is active
  #option band_steering_threshold 5

  # Interval (ms) between sending state updates to other APs
  #option remote_update_interval 1000

  # Number of remote update intervals after which a remote-node is deleted
  #option remote_node_timeout 10

  # Allow rejecting assoc requests for steering purposes (0/1)
  option assoc_steering 1

  # Allow ignoring probe requests for steering purposes (0/1)
  #option probe_steering 0

  # Minimum signal-to-noise ratio or signal level (dBm) to allow connections
  option min_connect_snr -60

  # Minimum signal-to-noise ratio or signal level (dBm) to remain connected
  option min_snr -70

  # Timeout after which a station with snr < min_snr will be kicked
  #option min_snr_kick_delay 5000

  # Timeout (ms) for which a client will not be steered after rejecting a BSS-transition-request
  option steer_reject_timeout 10000

  # Timeout (in ms) after which a association following a disassociation is not seen
  # as a roam
  #option roam_process_timeout 5000

  # Minimum signal-to-noise ratio or signal level (dBm) before attempting to trigger
  # client scans for roaming
  option roam_scan_snr -55

  # Maximum number of client roaming scan trigger attempts
  option roam_scan_tries 2

  # Retry scanning when roam_scan_tries is exceeded after this timeout (in ms)
  # In case this option is set to 0, the client is kicked instead
  #option roam_scan_timeout 0

  # Minimum time (ms) between client roaming scan trigger attempts
  option roam_scan_interval 1000

  # Minimum signal-to-noise ratio or signal level (dBm) before attempting to trigger
  # forced client roaming
  #option roam_trigger_snr -60

  # Minimum time (ms) between client roaming trigger attempts
  option roam_trigger_interval 1000

  # Timeout (ms) for client roam requests. usteer will kick the client after this times out.
  option roam_kick_delay 5000

  # Minimum signal strength difference until AP steering policy is active
  option signal_diff_threshold 10

  # Initial delay (ms) before responding to probe requests (to allow other APs to see packets as well)
  #option initial_connect_delay 0

  # Enable kicking client on excessive channel load (0/1)
  #option load_kick_enabled 0

  # Minimum channel load (%) before kicking clients
  #option load_kick_threshold 75

  # Minimum amount of time (ms) that channel load is above threshold before starting to kick clients
  #option load_kick_delay 10000

  # Minimum number of connected clients before kicking based on channel load
  #option load_kick_min_clients 10

  # Reason code on client kick based on channel load (default: WLAN_REASON_DISASSOC_AP_BUSY)
  #option load_kick_reason_code 5

  # Attempting to steer clients to a higher frequency-band every n ms.
  # A value of 0 disabled band-steering.
  option band_steering_interval 5000

  # Minimal SNR or absolute signal a device has to maintain over band_steering_interval to be
  # steered to a higher frequency band
  option band_steering_min_snr -70

  # Interval (ms) the device is sent a link-measurement request to help assess
  # the bi-directional link quality. Setting the interval to 0 disables link-measurements.
  #option link_measurement_interval 30000

  # Script to run after bringing up a node
  #option node_up_script ''

  # Message types to include in log
  # Available types:
  # - probe_req_accept
  # - probe_req_deny
  # - auth_req_accept
  # - auth_req_deny
  # - assoc_req_accept
  # - assoc_req_deny
  # - load_kick_trigger
  # - load_kick_reset
  # - load_kick_min_clients
  # - load_kick_no_client
  # - load_kick_client
  # - signal_kick
  list event_log_types 'signal_kick'
  list event_log_types 'auth_req_accept'
  list event_log_types 'auth_req_deny'
  list event_log_types 'assoc_req_accept'
  list event_log_types 'assoc_req_deny'

  # List of SSIDs to enable steering on
  list ssid_list 'My_Only_SSID_for_both_2G_and_5G'

Relevant changes are:

  option band_steering_interval 5000
  option band_steering_min_snr -70

In my understanding this is the minimal RSSI that the client should be able to hold for 5000ms in order to be steered from 2.4GHz to 5GHz. I set this quite low & fast as I want everything possibly on 5GHz and even -70dBm is quite usable and quick compared to 2.4GHz.

option roam_scan_snr -55
option signal_diff_threshold 10
option roam_scan_interval 1000
option roam_scan_tries 2

signal_diff_threshold should be the minimum difference in dBm that's required in order to be steered. Should work on its own IMO but I found in another thread that it requires roam_scan_snr to be non-zero (as usteer seems to use 0 values as "disabled" even if 0 should be a completely valid measurement)
So basically what I'm trying to do by these 2 lines is "start scanning for better signals at just -55dBm and if there's something better than current by just 10dBm then steer"
roam_scan_interval - trying to agitate scans very frequently, hoping it'd scan & find sooner, better, faster, more efficiently
roam_scan_tries - lowered to only 2, after which the station theoretically gets kicked. I did this hoping stations would find a better AP by then if not get kicked and find one on their own.
The latter 2 are just to make things snappier, hopefully.

option min_connect_snr -60
option min_snr -70

This is pretty easy - I don't want clients connecting with less than -60dBm and anything worse than -70dBm for persisted times should be kicked

That's pretty much it. Last night it worked flawlessly with my phone and laptop with very few exceptions "being sticky" and in those cases, unfortunately, RSSI of the "further away AP" justified this as reception was still too good. Personally battling another demon, namely so that 1 AP is able to cover a whole floor but trying to not go to the upper/lower floor. Well, that's not what WiFi thinks, not always..

Channels were chosen to be as least overlapping as possible, 25dBm / 80MHz each.

Please, do correct me! I'm here to learn and better myself and the config too! :slight_smile:

3 Likes

We are still a little hazy though. For 22.03 is this still the best way to set 802.11k and 802.11v:

      option bss_transition '1'
      option wnm_sleep_mode '1'
      option time_advertisement '2'
      option time_zone 'GMT0'
      option ieee80211k '1'
      option rrm_neighbor_report '1'
      option rrm_beacon_report '1'

But with having set the time_zone correctly?

Or are any further changes necessary?