RRM Beacon Report Issues w/ Channel Widths Larger than 40MHz

[Alex Gavin]

Hi there,

In recent testing with an AP that regularly sends Beacon Report measurement requests, I see scan
failures with measurement requests for channel widths larger than 40 MHz. Testing done with latest
vanilla upstream.

Details below, but I'm primarily reaching out to seek insight on how best to fix this. For our use
case, the primary effect of this issue is polluted logs with many repeated 'CTRL-EVENT-SCAN-FAILED'
errors.

Take for example the following AP configuration (issue also seen with 160 MHz and 320 MHz channel
widths):
- 2.4 GHz: channel 6,  20 Mhz
- 5 GHz:   channel 36, 40 MHz
- 6 GHz:   channel 37, 80 MHz

In this scenario, the AP sends Radio Measurement Requests for each of its three operating channels.
The requests for both 2.4GHz and 5GHz both succeed. However, the request for 6 GHz with the 80 MHz
channel width fails.

Looking closer at the code, 'wpas_add_channel()' generates the expected 2437 MHz and 5180 MHz
control channel frequencies, based on the channel and operating class sent by the AP. However, it
fails to generate expected frequencies for channel 37 operating with channel width 80 MHz and
operating class 133. In this case, it generates 6105 MHz, 6215 MHz, 6415 MHz, and 6615 MHz. These
are all center frequencies of larger bonded channel widths, rather than individual 20 MHz channel
center frequencies. This causes the scan request to the driver to fail.

>From what I see, the calculation for channel scanning causes the issue. With channel 36 and the
'num_primary_channels' set to 4 (80MHz), the function generates channels 30 (not a valid channel),
34, 38, and 42. The following line stands out in combination with the special case VHT logic below.

u8 primary_chan = chan - (2 * num_primary_channels - 2) + i * 4;


Best,

Alex