wifi: scan 5GHz channels on dual-band radios

[mikeysklar]

Stacked on #11297. Base is esp32c5-board, so only the top commit is new here.

What

Lets wifi.radio.start_scanning_networks() reach 5 GHz on dual-band radios.

Why

Three things blocked it:

Problem	Fix
scan_pattern stopped at channel 14	Added the U-NII channels, gated on SOC_WIFI_SUPPORT_5G
A rejected channel ended the whole scan	Skip it, keep scanning the rest of the pattern
stop_channel defaulted to 11	Raised to 165

DFS channels are left out. They need radar detection before transmitting.

Open question

Raising the default from 11 to 165 also changes 2.4 GHz boards, which now
scan channels 12, 13 and 14. 11 is the FCC-legal maximum, so that may have
been deliberate. Happy to make the default band-dependent instead.

Hardware tested

ESP32-C5-DevKitC-1-N8R8, 10.3.0-22-ge514194c68-dirty, host Ubuntu 24.04.
That is the stack tip, so it also carries #11309, which does not touch scanning.

def scan(**kw):
    ch = set()
    for net in wifi.radio.start_scanning_networks(**kw):
        ch.add(net.channel)
    wifi.radio.stop_scanning_networks()
    return sorted(ch)

Call	Channels seen	Nets	Secs
scan()	1, 2, 5, 6, 8, 10, 36, 44, 48, 149, 153	19	3.57
scan(start_channel=1, stop_channel=165)	1, 2, 5, 6, 8, 10, 36, 40, 44, 48, 149, 153	21	3.57
scan(start_channel=1, stop_channel=11)	2, 5, 6, 10	6	1.35
scan(start_channel=36, stop_channel=165)	36, 40, 44, 48, 149, 153	12	1.13
scan(stop_channel=166)	ValueError: stop_channel must be 1-165

The 36-165 row is the skip fix: it starts above the 2.4 GHz part of the pattern,
and the scan completes instead of ending at the first rejected channel.

Not tested: a 2.4 GHz only board. The scan_pattern change is gated on
SOC_WIFI_SUPPORT_5G, but the stop_channel default of 165 applies everywhere.

AI assistance

Claude wrote the scan-skip loop and the docstring. I found both defects on
hardware, ran the scans, and verified the channel lists myself.

[anecdata]

As I understand it scanning is a passive activity, so there's no harm in scanning channels 12, 13, or even 14. I'm in the US, and I actually do see traffic on channels 12 and 13. It would be useful to see if there is something running that (presumably) shouldn't be.

[tannewt]

Looks like ESP-IDF handles active vs passive scanning for us. From here:

The total time for scanning depends on:

• Active scan (by default) or passive scan.
• The time spent on each channel is 120 ms for active scanning and 360 ms for passive scanning.
• The country code and configured channel range from 1~13 channels (by default).
• Fast scan (by default) or full-channel scan.
• Station mode or Station-AP mode, and if any active connections are currently maintained.

By default, channels 1 to 11 use active scans, and channels 12 to 13 use passive scans.

• In the absence of connection in Station mode, the total time for a full-channel scan is: 11 × 120 + 2 × 360 = 2040 ms.
• With active connections in Station mode or Station-AP mode, the total time for a full-channel scan is: 11 × 120 + 2 × 360 + 13 × 30 = 2430 ms.

For 5 GHz channels, DFS channels must use passive scanning in accordance with regulatory requirements. DFS channel allocation differs across countries and regions. Refer to esp_wifi_regulatory.c: channels with the DFS flag set to 1 are DFS channels.