I don't know what you mean by "not an option".
Yes they are. I may not be picking that number in OpenWrt, but that is the end goal wide channel that we're arriving at by picking a width and a 20 MHz primary or beacon or whatever you want to call it.
Maybe someone else can better explain if you're still confused. We've have a good chat. I hope you gained some knowledge.
Good day to you.
hostapd.conf is about as good as you’ll get to the truth without reading the 802.11 standards.
By the way, expired standards are available $free$ through institutions and are available broadly on the internet.
Read this: https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
In conjunction with this: https://github.com/openwrt/openwrt/blob/main/package/network/config/wifi-scripts/files/lib/netifd/wireless/mac80211.sh
And all mysteries are solved.
Selected channel is always what beacons sent on.
Valid channels are only the 20MHz set, i.e. only the left most column in all of these Wikipedia screenshots.
Higher channel widths invoke various parameters depending on whether you are talking about HT, VHT, HE or EHT modes.
These are called “center segments” and are now referring to the right hand columns in the screenshots.
These are calculated by the above linked script.
For example, at 80MHz, channel is translated to a center segment as:
case "$(( (($channel / 4) + $chan_ofs) % 4 ))" in
1) idx=$(($channel + 6));;
2) idx=$(($channel + 2));;
3) idx=$(($channel - 2));;
0) idx=$(($channel - 6));;
esac
Picking channel 48.
48 / 4 =12
12 % 4 =0
48 - 6 =42 center segment.
48 is still the selected channel.
The math breaks down if you picked 42 as a “channel” to start.
Referring to the “wide” channels by their center names, or by their start names or even end names is just user preference and understanding. Whatever helps you convey message. I would say however that by the standard they are not “real” channels. They are centers of a wide set of real channels each occupying 20MHz.
Hope that puts an end to the circular conversation.
Holy crap, what did i start? I was sleeping guys.
Did we lead to anywhere other than where we started?
I agree with @lantis1008 the larger "center channels" are not "real" in a sense.
I guess let me try this one more time for the confused.
If you set the AP to channel 44 and 80Mhz:
20Mhz clients use beacon and data on channel 44
40Mhz clients use beacon on ch 44 and data on channel 46 (44+48)
80Mhz clients use beacon on ch 44 and data on channel 42 (36->48)
If you set the AP to channel 40 and 80Mhz:
20Mhz clients use beacon and data on channel 40
40Mhz clients use beacon on ch 40 and data on channel 38 (36+40)
80Mhz clients use beacon on ch 40 and data on channel 42 (36->48)
Notice the slight difference?
Now lets say OpenWRT changed the channel number list based on bandwidth selected. So if you set 80mhz, it only gave you the option to pick channel 42 like a few people here want. Now, tell me what channel will 40Mhz clients use for data? 20Mhz clients?
Anyone? Anyone?
Suddenly it's not so clear now right? This is why that convention is incorrect. Picking 20Mhz channels always is correct and not ambiguous to the operator (who understands this concept).
Remember not all clients support large bandwidths.
You provided a much clearer description, thanks!
I think I focused too much on the chart highlights.
I'd love a link, if you happen to have time, because none of my searches turned up a usable resource. It was pretty frustrating.
To the rest of your post, especially pointing out the relevant section of mac80211.sh, that was extremely helpful. Thank you very much for providing a source that fully backs up exactly what @madsci1016 was discussing.
I should have been sleeping too... 
Yes, absolutely. We now have a more fleshed-out explanation, with the actual source code to confirm the behaviour in terms of actual implementation, and we have the alternate, incorrect but plausible option being laid out plainly and now refuted.
Most importantly, it's now clearer that only a few channel selection options available in LuCI would lead to failure, rather than "most" under the other interpretation. That was part of the reason I was having such a hard time earlier, but this makes much more sense.
I'd call it a win, even though it was frustrating for a while. Thanks for your help.
It looks like openwrt it is not working with normal WiFi settings normally 
I was using channel 149 and width 80MHz, now i wanted to change it to channel 106 and also use Width 80, but channel is missing, I manually set it to 106, but wifi isn’t working.
My Region is Europe, Estonia.
Based on wiki I’m using correct settings, while in Luci UI i cannot select correct channels.
Also wifi is tuck on channels 42[44], but status in console shows that it is up on channel 106
Why OpenWRT perfectly works with wrong settings?
Linksys WRT32X
Powered by LuCI openwrt-24.10 branch (26.121.58405~6736f0f) / OpenWrt 24.10.5 (r29087-d9c5716d1d)
See: https://www.engeniustech.com/go-guide-channel-transmit-power-wi-fi-networks-2/
I can understand you want centre frequency 106, using channel 100, 104, 108, 112
But for Openwrt you pick the centre frequency of the 20 Mhz channel and then OpenWRT adds the other channels.
In case you choose 104 that would be LUU so one Lower channel and two Upper channels combining to 80 Mhz
Choosing 108 would be LLU
At least that is how I interpret it 
They're short-range rules on this channel in Europe.
You set the 20 MHz channels, the references/indexes of the 40, 80 and 160 MHz channels are not listed.
Set 100, 104 or 108 at 80 MHz - setting 106 is invalid.
If you read the last few replies in this thread you jumped onto the back of there are very detailed explanations as to why “106” is not a “real” channel and what you should be selecting instead.