search

openwrt / openwrt

This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.
Other
19.84k stars 10.33k forks source link

netifd mac80211.sh: he_bss_color_enabled incorrectly adds he_bss_color_disabled=1 to hostapd.conf files #15145

Open anonymous-one opened 5 months ago

anonymous-one commented 5 months ago

Describe the bug

Although undocumented, inside the netifd/wireless/mac80211.sh file there is a setting labeled he_bss_color_enabled:

json_get_vars \
                        he_su_beamformer:1 \
                        he_su_beamformee:1 \
                        he_mu_beamformer:1 \
                        he_twt_required:0 \
                        he_spr_sr_control:3 \
                        he_spr_psr_enabled:0 \
                        he_spr_non_srg_obss_pd_max_offset:0 \
                        he_bss_color:128 \
                        he_bss_color_enabled:1

I wanted to disable bss coloring or at least all the other options that netifd/wireless/mac80211.sh enables when bss coloring is enabled.

I set this to 0 in my wireless config like so:

option he_bss_color_enabled '0'

Which in turn adds he_bss_color_disabled=1 to the generated hostapd.conf file which causes hostapd to fail loading since this setting does not exist.

Yes, I am running a full version of hosapd (hostapd-openssl in my case). I have done some quick searching and this setting is nowhere to be found in the hostapd.conf files online.

Furthermore, a bit dirty, but none the less:

root@OPENWRT-SALON:/lib/netifd/wireless# cat /usr/sbin/hostapd | strings | grep he_bss
he_bss_color
he_bss_color_partial
he_bss_color=%d

he_bss_color_disabled is not a valid setting to be added to hostapd.conf.

For quick reference, I am adding the part of netifd/wireless/mac80211.sh that adds this to the generated hostapd.conf files.

                if [ "$he_bss_color_enabled" -gt 0 ]; then
                        append base_cfg "he_bss_color=$he_bss_color" "$N"
                        [ "$he_spr_non_srg_obss_pd_max_offset" -gt 0 ] && { \
                                append base_cfg "he_spr_non_srg_obss_pd_max_offset=$he_spr_non_srg_obss_pd_max_offset" "$N"
                                he_spr_sr_control=$((he_spr_sr_control | (1 << 2)))
                        }
                        [ "$he_spr_psr_enabled" -gt 0 ] || he_spr_sr_control=$((he_spr_sr_control | (1 << 0)))
                        append base_cfg "he_spr_sr_control=$he_spr_sr_control" "$N"
                else
                       append base_cfg "he_bss_color_disabled=1" "$N"
                fi

OpenWrt version

r25870-08639a5e47

OpenWrt release

SNAPSHOT

OpenWrt target/subtarget

mediatek/filogic

Device

GL.iNet GL-MT6000

Image kind

Official downloaded image

Steps to reproduce

No response

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

No response

Terms

brada4 commented 5 months ago

script is wrong, avoid using that parameter, no way in protocol for it to work.

color is defined ax header field, you need to disable ax to get rid of new header format. https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n836 Normally you would randomize it to save low power device usage

rany2 commented 5 months ago

@brada4 setting an invalid value outside of the range is the only way I know how to disable this.

brada4 commented 5 months ago

@rany2 that selects random parameter within range. Like really really enabled.

anonymous-one commented 5 months ago

apprecaite the feedback / clarification.

i was able to resolve what was causing me to want to experiment with turning off bss coloring, so i no longer have a need to disable it.

none the less, the script does need a slight rework to remove any sort of bss coloring disable / enable.

i guess all the dependent params should be set to some sort of reasonable (hostapd.conf?) default, and if set, set as provided.

anonymous-one commented 5 months ago

oh, on a slightly related note. the docs state that if bss color is not provided in /etc/config/wireless, a random value is chosen. this is not true.

checking the generated /var/un/hostapd*conf files, it defaults to 128. here is an example from 2 of my devices where bss color is not set in wireless config... thus, it should be random.

root@OPENWRT-SALON:~# grep bss /etc/config/wireless ; grep he_bss_color /var/run/hostapd*conf ; ssh root@192.168.1.5 "grep bss /etc/config/wireless" ; ssh root@192.168.1.5 "grep he_bss_color /var/run/hostapd*conf";
        option bss_transition '1'
/var/run/hostapd-phy1.conf:he_bss_color=128
        option bss_transition '1'
/var/run/hostapd-phy1.conf:he_bss_color=128
anonymous-one commented 5 months ago

sigh while we are here:

when i use this app : https://play.google.com/store/apps/details?id=com.analiti.fastest.android&hl=en&gl=US on my android device, it shows quite a nice detailed list of details about the various access points in my area. as well as the one im connected to.

under bss_color, on mt76 and ipq807x devices (only 2 type of device i have on hand), it shows bss color as "0".

could very well be an issue with the app, but could also be an issue with hostapd.

i am running win10 on all my devices which have wifi so the hurdle to get wireshark in monitor mode is a bit high so i have been unable to capture some packets to see if its actualy being changed in the headers or not.

brada4 commented 5 months ago

https://www.rfwireless-world.com/Terminology/WLAN-802-11ax-frame-structure.html hesiga field is mandatory you are right about scripts being mistaken

KanjiMonster commented 5 months ago

oh, on a slightly related note. the docs state that if bss color is not provided in /etc/config/wireless, a random value is chosen. this is not true.

checking the generated /var/un/hostapd*conf files, it defaults to 128. here is an example from 2 of my devices where bss color is not set in wireless config... thus, it should be random.

root@OPENWRT-SALON:~# grep bss /etc/config/wireless ; grep he_bss_color /var/run/hostapd*conf ; ssh root@192.168.1.5 "grep bss /etc/config/wireless" ; ssh root@192.168.1.5 "grep he_bss_color /var/run/hostapd*conf";
        option bss_transition '1'
/var/run/hostapd-phy1.conf:he_bss_color=128
        option bss_transition '1'
/var/run/hostapd-phy1.conf:he_bss_color=128

OpenWrt has a local patch where setting a value > 63 causes hostapd to generate a random value: https://github.com/openwrt/openwrt/blob/main/package/network/services/hostapd/patches/465-hostapd-config-support-random-BSS-color.patch

anonymous-one commented 5 months ago

i stand corrected! thanks!

oh, on a slightly related note. the docs state that if bss color is not provided in /etc/config/wireless, a random value is chosen. this is not true. checking the generated /var/un/hostapd*conf files, it defaults to 128. here is an example from 2 of my devices where bss color is not set in wireless config... thus, it should be random.

root@OPENWRT-SALON:~# grep bss /etc/config/wireless ; grep he_bss_color /var/run/hostapd*conf ; ssh root@192.168.1.5 "grep bss /etc/config/wireless" ; ssh root@192.168.1.5 "grep he_bss_color /var/run/hostapd*conf";
        option bss_transition '1'
/var/run/hostapd-phy1.conf:he_bss_color=128
        option bss_transition '1'
/var/run/hostapd-phy1.conf:he_bss_color=128

OpenWrt has a local patch where setting a value > 63 causes hostapd to generate a random value: https://github.com/openwrt/openwrt/blob/main/package/network/services/hostapd/patches/465-hostapd-config-support-random-BSS-color.patch