Comment 0 for bug 1987252

When running a laptop with a mesh WiFi network, frequent disconnections happen like 10 to 20 times per hour. 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.

How to reproduce:

[environment]
- two or more access points as a mesh with 802.11k/v enabled
- client with jammy and wpasupplicant=2:2.10-6ubuntu2
  - make sure a laptop is power-supply connected
  - make sure a WiFi device has "Power Management:off" in `iwconfig` to exclude the influence of power saving features
- use 11ac(5GHz)

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 in Japan 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.

$ 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)