gluon-core: fix htmode on devices with channel widths < site ch-width#3771
Conversation
|
Btw. with this change the fallback/promise to "if preferred htmode is not available select the last one we got" is not available anymore. But I couldn't quite see when this could legitimately happen anyway. And I didn't want to add even more complexity for such a fallback. |
|
Does your device report |
No, The HE40 comes from a Hm, maybe I'll split the patch into two fixes, to make it easier to follow, give me a second. |
On a TP-Link TL-WDR3600 v1 running Gluon v2025.1.1 with an 80MHz channel width in the site config for the 5GHz radio it was observed that the 5GHz radio would not be created anymore since the addition of the channel width setting. The issue could be narrowed down to the UCI htmode setting wrongly being set to HE40 instead of HT40: ``` $ uci get wireless.radio1.htmode HE40 ``` HE40 is not available on this 802.11n/Wi-Fi 4/5GHz radio though: ``` $ iwinfo phy1 htmodelist HT20 HT40 ``` Further investigation showed that in the get_htmode() function it would eventually find and set the "last_mode = HT40". However unless it is not exactly matching the site.conf channel width then it would overwrite it again and finally return the last htmode it checked, even if it was not available on the radio. Fixing this by only overwriting the last found, chosen mode if the new one is available on this hardware. Fixes: c634d83 ("gluon-core: add setting of htmode channel_width per radio") Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
On a TP-Link TL-WDR3600 v1 running Gluon v2025.1.1 iwinfo.nl80211.htmodelist(phy) returns the various modes in the following order: HE80+80, HE20, VHT20, EHT80, EHT160, HE80, NOHT, HT20, HT40, VHT40, VHT160, EHT20, VHT80+80, EHT320, EHT80+80, VHT80, EHT40, HE160, HE40. Note that they are not sorted lowest to highest channel bandwidth. This results in HE40 to be prefered over HE160 even if the site config is set to 160MHz or VHT80 is prefered over VHT160, for example. This is because the current algorithm only considers the last option it has found in this unsorted list if the device only supports a channel bandwidth which is lower than the one configured in the site config. Fixing this by only changing the currently selected htmode if it has a larger channel bandwidth. Fixes: c634d83 ("gluon-core: add setting of htmode channel_width per radio") Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
|
Changelog v2:
|
3 participants
On a TP-Link TL-WDR3600 v1 running Gluon v2025.1.1 with an 80MHz channel width in the site config for the 5GHz radio it was observed that the 5GHz radio would not be created anymore since the addition of the channel width setting. The issue could be narrowed down to the UCI htmode setting wrongly being set to HE40 instead of HT40.
HE40 is not available on this 802.11n/Wi-Fi 4/5GHz radio though:
Further investigation showed that in the get_htmode() function it would eventually find and set the "last_mode = HT40". However unless it is not exactly matching the site.conf channel width then it would overwrite it again and finally return the last htmode it checked, even if it was not available on the radio. The order in which get_htmode() checked modes: HE80+80, HE20, VHT20, EHT80, EHT160, HE80, NOHT, HT20, HT40, VHT40, VHT160, EHT20, VHT80+80, EHT320, EHT80+80, VHT80, EHT40, HE160, HE40. Resulting in the last item, HE40 being picked.
Fixing this by only overwriting the last found, chosen mode if the new one is available on this hardware for one thing. For another ensure to select the widest channel width allowed by site config, as the output of iwinfo.nl80211.htmodelist(phy), as can be seen above, is not ensured to be sorted by channel width.