outdoor_chanlist needs to depend on channel_width #3678
Description
Right now outdoor_chanlist is mostly using the same parameter as hostapd which is very unintuitive to communities (not self explanatory)
It chooses only the primary channel and does not limit which secondary channels are chosen like the user would expect. Secondary channels are chosen solely based on channel width.
As an example:
We allow 100-116, 132-140 in the site.conf for DFS.
So DFS selects primary channel 116 since it is allowed and channel width is set to 80MHz: this would lead to center frequency 122 (channels 116-128) even though the community expected 120-128 to be forbidden.
It needs to be translated imho.
100-116, 132-140
should be translated into a list of allowed hostapd channels depending on the channel width.
- For 80MHz it's just 100-112 then (only one slot for this type of config that leaves out weather radar channels, not ideal obviously)
- For 40MHz it's 100-112, 132-136
- For 20MHz it's the full range defined in the site.conf: 100-116, 132-140
- For 160MHz you cannot limit DFS this far. There is only center channel 114 (100-128) which this config would prohibit from being used all together.
The translation should probably generate a config using the singular channels instead of channels connected by dashes like I did here.
side note:
Since we have the possibility to define 40MHz as the default now: #3659
The site.conf can by accident define invalid configs which we should prevent from happening by reworking outdoor_chanlist like I described above
wifi5 = {
channel_width = 40,
outdoor_chanlist = "140",
...
}
This is invalid because it uses channels 140+144 (known as 142). 144 is invalid for clients in Europe so they cannot connect
related comment: #3101 (comment)
Once this is implemented then #3101 can be implemented safely.