"Beacon request: No valid channels" for 802.11k measurement (RRM)

[Nobuto Murata]

When running a laptop with a mesh WiFi network, frequent errors/notices are recorded on an access point. And the issue has disappeared by applying the following patch.

https://w1.fi/cgit/hostap/commit/?id=8e0ac53660aaa9691e140156c47fddb7cd8c62b6
> RRM: Include passive channels in active beacon report scan
> When receiving a beacon report request with the mode set to active,
> channels that are marked as NO_IR were not added to the scan request.
> However, active mode just mean that active scan is allowed, but not
> that it is a must, so these channels should not be omitted.
> Include channels that are marked as NO_IR in the scan request even
> if the mode is set to active.

So I'd like to request a backport of it.

I believe the following combination of parameters is the key to trigger the "Beacon request: No valid channels" issue.

- two or more access points as a mesh with 802.11k/v enabled
- wpasupplicant 2.10 series or lower
  - kinetic with wpasupplicant=2.10-9ubuntu1  - jammy and wpasupplicant=2:2.10-6ubuntu2
  - or lower
- Running two AP in 5GHz
- and all of used 5GHz channels by the APs are marked as:
  - NO_IR (sudo wpa_cli get_capability freq)
  - or PASSIVE-SCAN (iw reg get)
- walking around with a laptop among multiple access points to trigger signal strength changes and measurements

The log has a sudden "Connection to AP lost" with "No beacon heard and the time event is over already" as follows:

> kernel: [136930.972759] wlp3s0: Connection to AP 6c:5a:b0:xx:yy:zz lost
> kernel: [136931.217753] wlp3s0: authenticate with 6c:5a:b0:xx:yy:zz
> kernel: [136931.229486] wlp3s0: send auth to 6c:5a:b0:xx:yy:zz (try 1/3)
> kernel: [136931.234536] wlp3s0: authenticated
> kernel: [136931.239353] wlp3s0: associate with 6c:5a:b0:xx:yy:zz (try 1/3)
> kernel: [136931.253596] wlp3s0: RX AssocResp from 6c:5a:b0:xx:yy:zz (capab=0x1511 status=0 aid=2)
> kernel: [136931.255411] wlp3s0: associated
> kernel: [136931.843561] iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
> kernel: [136931.843650] wlp3s0: Connection to AP 6c:5a:b0:xx:yy:zz lost
> kernel: [136932.067556] wlp3s0: authenticate with 6c:5a:b0:xx:yy:zz
> kernel: [136932.078277] wlp3s0: send auth to 6c:5a:b0:xx:yy:zz (try 1/3)
> kernel: [136932.085292] wlp3s0: authenticated
> kernel: [136932.087341] wlp3s0: associate with 6c:5a:b0:xx:yy:zz (try 1/3)
> kernel: [136932.100737] wlp3s0: RX AssocResp from 6c:5a:b0:xx:yy:zz (capab=0x1511 status=0 aid=2)
> kernel: [136932.103238] wlp3s0: associated
> kernel: [136932.392477] wlp3s0: Limiting TX power to 20 (23 - 3) dBm as advertised by 6c:5a:b0:xx:yy:zz

And wpa_supplicant considers it in syslog as:
wlp3s0: CTRL-EVENT-DISCONNECTED bssid=6c:5a:b0:xx:yy:zz reason=4 locally_generated=1

By enabling debug of wpa_supplicant with `sudo wpa_cli log_level DEBUG`, I found "Beacon request: No valid channels" message on the client (Ubuntu laptop) at the same timing as 11k measuremrent on the AP every 6 seconds.

> Aug 21 14:01:06 deco daemon.notice nrd[22822]: estimatorPerformMeasurement: Do 11k measuremrent for D4:3B:04:XX:YY:ZZ on channel 48 from serving BSS APId 255 ChanId 48 ESSId 0
> Aug 21 14:01:06 deco daemon.err nrd[22822] estimatorCmnHandleBeaconReportEvent: Invalid beacon report for D4:3B:04:XX:YY:ZZ
>
> Aug 21 14:01:06 t480 wpa_supplicant[1613]: Beacon request: No valid channels
>
> Aug 21 14:01:12 deco daemon.notice nrd[22822]: estimatorPerformMeasurement: Do 11k measuremrent for D4:3B:04:XX:YY:ZZ on channel 48 from serving BSS APId 255 ChanId 48 ESSId 0
> Aug 21 14:01:12 deco daemon.err nrd[22822] estimatorCmnHandleBeaconReportEvent: Invalid beacon report for D4:3B:04:XX:YY:ZZ
>
> Aug 21 14:01:12 t480 wpa_supplicant[1613]: Beacon request: No valid channels
>
> Aug 21 14:01:18 deco daemon.notice nrd[22822]: estimatorPerformMeasurement: Do 11k measuremrent for D4:3B:04:XX:YY:ZZ on channel 48 from serving BSS APId 255 ChanId 48 ESSId 0
> Aug 21 14:01:18 deco daemon.err nrd[22822] estimatorCmnHandleBeaconReportEvent: Invalid beacon report for D4:3B:04:XX:YY:ZZ
>
> Aug 21 14:01:18 t480 wpa_supplicant[1613]: Beacon request: No valid channels

This suggests that there is a clear disagreement around 11k between the client and the AP. And after applying the patch above, the AP can see the proper response to 11k measurement, and frequent disconnections are not reproducible.

> Sun Aug 21 18:15:55 2022 daemon.notice nrd[22822] estimatorPerformMeasurement: Do 11k measuremrent for D4:3B:04:XX:YY:ZZ on channel 48 from serving BSS APId 255 ChanId 48 ESSId 0
> Sun Aug 21 18:15:55 2022 daemon.notice nrd[22822] wlanifBSteerEventsHandleBeaconReport: Beacon report from D4:3B:04:XX:YY:ZZ: APId 1 ChanId 48 ESSId 0 bssid 6C:5A:B0:XX:YY:AA rcpi: 104
> Sun Aug 21 18:15:55 2022 daemon.notice nrd[22822] wlanifBSteerEventsHandleBeaconReport: Beacon report from D4:3B:04:XX:YY:ZZ: APId 255 ChanId 48 ESSId 0 bssid 6C:5A:B0:XX:YY:BB rcpi: 68

[AP]
- TP-Link Deco X60 as the main AP with the bridge mode
- another Deco X60 as the sub AP

[client]
- Intel AC 8265

$ lspci -nnkv | sed -n '/Network/,/^$/p'
03:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
        Subsystem: Intel Corporation Dual Band Wireless-AC 8265 [8086:0010]
        Flags: bus master, fast devsel, latency 0, IRQ 159
        Memory at dc100000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi

[available frequencies]
As the patch description suggests, NO_IR flag matters. And Intel AC 8265 running with Japan's regulation at least, all of the available channels in 5GHz are marked as NO_IR so it makes sense that params->freqs gets empty by excluding NO_IR and gets into "Beacon request: No valid channels" before patching.
https://wireless.wiki.kernel.org/en/developers/regulatory/processing_rules#post_processing_mechanisms

$ sudo wpa_cli get_capability freq
...
Mode[A] Channels:
 36 = 5180 MHz (NO_IR)
 40 = 5200 MHz (NO_IR)
 44 = 5220 MHz (NO_IR)
 48 = 5240 MHz (NO_IR)
 52 = 5260 MHz (NO_IR) (DFS)
 56 = 5280 MHz (NO_IR) (DFS)
 60 = 5300 MHz (NO_IR) (DFS)
 64 = 5320 MHz (NO_IR) (DFS)
 100 = 5500 MHz (NO_IR) (DFS)
 104 = 5520 MHz (NO_IR) (DFS)
 108 = 5540 MHz (NO_IR) (DFS)
 112 = 5560 MHz (NO_IR) (DFS)
 116 = 5580 MHz (NO_IR) (DFS)
 120 = 5600 MHz (NO_IR) (DFS)
 124 = 5620 MHz (NO_IR) (DFS)
 128 = 5640 MHz (NO_IR) (DFS)
 132 = 5660 MHz (NO_IR) (DFS)
 136 = 5680 MHz (NO_IR) (DFS)
 140 = 5700 MHz (NO_IR) (DFS)
 144 = 5720 MHz (NO_IR) (DFS)

[Nobuto Murata (nobuto)]

I've been using the custom build with the patch for one and a half days and it's far stable now.

https://launchpad.net/~nobuto/+archive/ubuntu/experimental-packages/+build/24301259/+files/wpasupplicant_2.10-6ubuntu2.1~ppa1_amd64.deb

[Nobuto Murata (nobuto)]

I forgot to mention; 2.10-9ubuntu1 in kinetic didn't make a difference so I went down the path of finding a commit in upstream.

My colleague in EU kindly shared an output of `sudo wpa_cli get_capability freq` and it had 5GHz channels *without* NO_IR. So the key to reproduce the issue would be regulations set for countries/regions.

> Mode[A] Channels:
> 36 = 5180 MHz (NO_IR)
> 40 = 5200 MHz (NO_IR)
> 44 = 5220 MHz (NO_IR)
> 48 = 5240 MHz (NO_IR)
> 52 = 5260 MHz (NO_IR) (DFS)
> 56 = 5280 MHz (NO_IR) (DFS)
> 60 = 5300 MHz (NO_IR) (DFS)
> 64 = 5320 MHz (NO_IR) (DFS)
> 100 = 5500 MHz (NO_IR) (DFS)
> 104 = 5520 MHz (NO_IR) (DFS)
> 108 = 5540 MHz (NO_IR) (DFS)
> 112 = 5560 MHz (NO_IR) (DFS)
> 116 = 5580 MHz (NO_IR) (DFS)
> 120 = 5600 MHz (NO_IR) (DFS)
> 124 = 5620 MHz (NO_IR) (DFS)
> 128 = 5640 MHz (NO_IR) (DFS)
> 132 = 5660 MHz (NO_IR) (DFS)
> 136 = 5680 MHz (NO_IR) (DFS)
> 140 = 5700 MHz (NO_IR) (DFS)
> 144 = 5720 MHz (NO_IR) (DFS)
> 149 = 5745 MHz
> 153 = 5765 MHz
> 157 = 5785 MHz
> 161 = 5805 MHz
> 165 = 5825 MHz

[Nobuto Murata (nobuto)]

The output above was with Intel Wi-Fi 6 AX201. And another colleague in EU had Intel 8200 series and the output was all *with* NO_IR.

> Mode[A] Channels:
> 36 = 5180 MHz (NO_IR)
> 40 = 5200 MHz (NO_IR)
> 44 = 5220 MHz (NO_IR)
> 48 = 5240 MHz (NO_IR)
> 52 = 5260 MHz (NO_IR) (DFS)
> 56 = 5280 MHz (NO_IR) (DFS)
> 60 = 5300 MHz (NO_IR) (DFS)
> 64 = 5320 MHz (NO_IR) (DFS)
> 100 = 5500 MHz (NO_IR) (DFS)
> 104 = 5520 MHz (NO_IR) (DFS)
> 108 = 5540 MHz (NO_IR) (DFS)
> 112 = 5560 MHz (NO_IR) (DFS)
> 116 = 5580 MHz (NO_IR) (DFS)
> 120 = 5600 MHz (NO_IR) (DFS)
> 124 = 5620 MHz (NO_IR) (DFS)
> 128 = 5640 MHz (NO_IR) (DFS)
> 132 = 5660 MHz (NO_IR) (DFS)
> 136 = 5680 MHz (NO_IR) (DFS)
> 140 = 5700 MHz (NO_IR) (DFS)
> 144 = 5720 MHz (NO_IR) (DFS)
> 149 = 5745 MHz (NO_IR)
> 153 = 5765 MHz (NO_IR)
> 157 = 5785 MHz (NO_IR)
> 161 = 5805 MHz (NO_IR)
> 165 = 5825 MHz (NO_IR)

So it must be dependent on the vendor/model/generation of WiFi cards. In any case, I'm more than happy to offer any information required and test something as necessary. Thanks,

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "rrm-include-passive-channels-in-active-beacon-report-scan.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]