FS#65470 - [wpa_supplicant] enable CONFIG_WNM for full 802.1r/k/v support

Attached to Project: Arch Linux
Opened by Lukas Redlinger (rel) - Wednesday, 12 February 2020, 15:26 GMT
Last edited by Jan Alexander Steffens (heftig) - Wednesday, 23 February 2022, 03:41 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
stuggling at a customer with 802.11r/k/v infrastructure as my client is internally blacklisting all APs after some time, as it tries to connect APs that are temporarily disallowed as of 802.11k optimizations (CISCO Prediction Based Roaming-Assisted Roaming).

to my understanding 802.11v is needed to fully benefit (use neighbouring AP information) from 802.11k
support for 802.11v is enabled via CONFIG_WNM

add CONFIG_WNM=y to packages/wpa_supplicant/config
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Wednesday, 23 February 2022, 03:41 GMT
Reason for closing:  Implemented
Additional comments about closing:  wpa_supplicant 2:2.10-3
Comment by Jan Alexander Steffens (heftig) - Wednesday, 12 February 2020, 16:11 GMT
Have you actually tested this? It is marked as "experimental" and "incomplete".
Comment by Lukas Redlinger (rel) - Thursday, 13 February 2020, 09:18 GMT
at least it builds and additional commands in wpa_cli appear (wnm_*)

As our infrastructure doesn't support 802.11r/k/v, I'll ask the customer if he's willing to let me update wpa_supplicant via 4G connection. What could possibly go wrong? ;-)
Comment by Lukas Redlinger (rel) - Tuesday, 18 February 2020, 10:06 GMT
Seems to work - it is now respecting a "preferred list" as you see in the log below. Therefore it's not trying to connect to temporarily blocked/disabled access points.


<3>SME: Trying to authenticate with 00:a7:42:xx:xx:xx (SSID='xxxxxxxx' freq=5620 MHz)
<3>CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
<3>Trying to associate with 00:a7:42:xx:xx:xx (SSID='xxxxxxxx' freq=5620 MHz)
<3>Associated with 00:a7:42:xx:xx:xx
<3>WPA: Key negotiation completed with 00:a7:42:xx:xx:xx [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 00:a7:42:xx:xx:xx completed [id=0 id_str=]
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
----- this is new -----
<3>WNM: Preferred List Available
----- -----
<3>CTRL-EVENT-SCAN-STARTED
Comment by Jan Alexander Steffens (heftig) - Saturday, 22 February 2020, 18:18 GMT
Disabled again, see  FS#65588 
Comment by Lukas Redlinger (rel) - Monday, 24 February 2020, 10:53 GMT
Too bad that never got fixed in the broadcom driver/firmware.
I'm on an Intel 8265 chipset here.

I can still confirm that enabling CONFIG_WNM is needed in order to have 802.11r/k/v working proper.
Comment by David Bauer (blocktrron) - Tuesday, 22 February 2022, 22:36 GMT
The bug in broadcom-wl is now fixed, see  FS#73495 

It confirmed CONFIG_WNM can now be enabled without causing problems with broadcom-wl: http://lists.infradead.org/pipermail/hostap/2022-January/040188.html

Debian enabled WNM back in last September: https://metadata.ftp-master.debian.org/changelogs//main/w/wpa/wpa_2.10-2_changelog

NixOS has a pending PR: https://github.com/NixOS/nixpkgs/pull/158174

Loading...