gluon-core: add override setting for htmode per radio

[maurerle]

This is a follow up PR from #3563 and implements the missing parts of #3550

Fixes #3550
Fixes #2947

This allows to set a custom bandwidth, which should be supported by all devices with that band.

add a txpower and htmode per radio section, which can be set using
uci set gluon.wradio0.htmode="HE40"

Similarly, gluon.wradio0.txpower can be adjusted.
This is based on the radio name which should stay the same once created with wifi config
The migration of the existing txpower value takes already place in 022-wireless-roles.

There might be a better option to tie this setting to, but radio0 seems more consistent than "phy0" as we have seen.

[neocturne]

The whole point of moving this config from /etc/config/wireless to /etc/config/gluon was to make it independent of the radio indices. We can't add sections with radio names to gluon now, they should be identified by their paths (or PHY names in the future, when renaming works...)

It may make sense to disallow this for now and wait for working PHY renaming.

[maurerle]

I fixed this in the latest push (not cleaned up though)

[neocturne]

Types are inconsistent - check_site.lua enforces a number, but here the default value is a string.

[neocturne]

Also, shouldn't this be called channel_width?

[neocturne]

Also, the abstraction should be the same in site.conf and /etc/config/gluon (with values 20, 40, ...). The conversion to HE20 etc. should happen when applying the configuration to `/etc/config/wireless.

[maurerle]

I would like to have the option to set 'HT20' instead of 'HE20' in the /etc/config/gluon as well..?
I only need this to debug an issue from time to time and could adjust /etc/config/wireless myself.
So I guess it is fine to only have the "highest" mode configured in gluon

[neocturne]

I also remember meshing getting broken because of dynamic switching of primary and secondary channel by hostapd with HT40 modes (if another radio is seen on the primary channel, which will... always happen when meshing), which could only be workarounded with the potentially non-compliant noscan setting. We must make sure that this issue has been resolved before allowing wider channels.

[maurerle]

Thanks! I did not have any issue with this so far. Tested with:
20-20 MHz
20-40 MHz
20-80 MHz
40-80 MHz

I guess that I should have run into this issue, if it would still be a problem.
I deployed this on around 30 nodes already.

[maurerle]

The uci show wireless.radioX.path is always the same to determine a radio. So this should be used as a mapping from radioX names instead.

I guess I have to somehow implement this somewhat like this:

1. If no gluon.wradioX exists, create according entries from the existing /etc/config/wireless and migrate the existing settings
2. then remove the existing /etc/config/wireless
3. run wifi config to generate new radio names
4. adjust the /etc/config/wireless with settings in /etc/config/gluon, using the configured parts

I could also just create the wifi-device section myself, but I don't know how I will know about phy renaming then..?

I guess this works fine, but also is a little bit of work.
This removes all "preserve_channels" options as well

I wonder how this could adhere to wifi path changes like this:
migrate_radio 'platform/18000000.wifi' 'platform/soc/18000000.wifi'
https://github.com/openwrt/openwrt/blob/9934c716edbc68d9d223c6290fd7f073d0715351/target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/05-wifi-migrate#L56

[maurerle]

Until I have some guidance to this change, the htmode site setting (#3659) is unrelated from this and should work without introducing regrettable changes.
(unlike this PR which really should get the identification of a radio right throughout all cases to not change this again)