Without this configuration it is not possible to run the radio using HE160 on channels 149-177.
Fixes: #14906
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
(cherry picked from commit a91b79fd04)
Link: https://github.com/openwrt/openwrt/pull/15898
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
With mac80211_hwsim I have seen such entries in OpenWrt 22.03:
HE Iftypes: managed, AP
The mac80211.sh script did not detect the entry and failed. Allow
arbitrary other entries before to fix this problem.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 5df7a78e82)
This prevents min_tx_power from functioning properly in some circumstances.
Add the missing newline.
Signed-off-by: Rany Hany <rany_hany@riseup.net>
(cherry picked from commit 6ca8752a9c)
noscan option was changed to hostapd_noscan but the entry in
wpa_supplicant was never updated resulting in the noscan option actually
never set.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit 1070fbce6e)
This significantly improves config reload behavior and also fixes some
corner cases related to running AP + mesh interfaces at the same time.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This adds missing HE modes to mac80211_prepare_ht_modes.
Previously mesh without wpa_supplicant would be initialized with 802.11g
/NO-HT only, as this method did not parse channel bandwidth for HE
operation.
Signed-off-by: David Bauer <mail@david-bauer.net>
When reloading modules and running wifi, a phy can sometimes be renamed
while in the middle of a hotplug call that tries to detect new phys
This can lead to bogus wifi-device sections being created
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This makes it clear, which phy a wlan device belongs to and also helps with
telling them apart by including the mode in the ifname.
Preparation for automatically renaming PHYs
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Reported-by: Chad Monroe <chad.monroe@smartrg.com>
Fixes: 590eaaeed5 ("mac80211: fix issues in HE capabilities")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Enable HE SU beamformee by default
Fix spatial reuse configuration:
- he_spr_sr_control is not a bool for enabling, it contains multiple bits
which disable features that should be disabled by default
- one of the features (PSR) can be enabled through he_spr_psr_enabled
- add option to disable bss color / spatial reuse
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The "tx_burst" option which should control the value was
expecting more of a list and hence tx_queue_data2_burst
value wasn't updated.
Yes, it would make sense to have a list for this, the
existing code only updates tx_queue_data2_burst and
not the other tx_queue_data[0134]_burst values.
Signed-off-by: Alberto Martinez-Alvarez <amteza@gmail.com>
(formatted commit message, wrote extra information into commit,
moved tx_burst to existing json_get_vars)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
It is common for 802.11ax NICs to support more than just AP mode, which
results in there being a distinct set of HE capabilities for each mode. As
(bad) luck would have it, iw prints out info for each HE mode in sequential
order according to `enum nl80211_iftype`, and AP mode isn't always first.
As a result, the wrong set of HE capabilities can be parsed if an AP NIC
supports station (managed) mode or any other mode preceding AP mode, since
only the first set of HE capabilities printed by iw is parsed from awk's
output.
This has a noticeable impact on beamforming for example, since managed mode
usually doesn't have beamformer capabilities enabled, while AP mode does.
Hostapd won't be set up with the configs to enable beamformer capabilities
in this scenario, causing hostapd to disable beamforming to HE stations
even when it's supported by the AP.
Always parse the correct set of HE capabilities for AP mode to fix this.
This is achieved by trimming all of iw's output prior to the AP mode
capabilities, which ensures that the first set of HE capabilities are
always for AP mode.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Add support for randomly generating a MAC address for a wifi-iface
instance by setting `macaddr` to `random`
When set to `random`, a new locally administered unicast MAC address
is generated and assigned to the iface everytime it is (re-)configured
Signed-off-by: Manas Sambhus <manas.sambhus+github@gmail.com>
Introduce a new option background_radar to toggle hostapd's background
radar feature. Enabling this allows DFS CAC to run on dedicated radio RF
chains while the radio(s) are otherwise running normal AP activities on
other channels.
As OpenWrt configures hostapd to use a channel list even when a single
channel is configured, using this feature requires a list of channels in
/etc/config/wireless. Alternatively, channel can be set to auto.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: David Bauer <mail@david-bauer.net>
In case no specific BSS color is configured, set it to a random value.
Signed-off-by: David Bauer <mail@david-bauer.net>
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
On systems using brmcfmac (e.g. Raspberry Pi Zero W) without this fix,
the final setup-call:
iw dev wlan0 ibss join ...
fails with returncode 161 and message:
"command failed: Not supported (-95)"
So this patch calls an explicit:
iw dev wlan0 set type ibss
just prior to the 'ibss join' command.
I have tested several ath9k and mt76xx devices
with different revisions: this patch does not harm.
please also apply to stable branch.
Signed-off-by: Bastian Bittorf <bb@npl.de>
drv_mac80211_teardown fails silently if the device to be torn down is
not defined. This commit prints an error message.
branches affected: trunk, 21.02
Signed-off-by: Bob Cantor <coxede6557@w3boats.com>
When wifi is turned off, drv_mac80211_teardown sometimes fails (silently)
because the device to be torn down is not defined.
This situation arises if drv_mac80211_setup was called twice when
wifi was turned on.
This commit ensures that the device to be torn down is always defined
in drv_mac80211_teardown.
Steps to reproduce:
1) Use /sbin/wifi to turn on wifi.
uci set wireless.@wifi-iface[0].disabled=0
uci set wireless.@wifi-device[0].disabled=0
uci commit
wifi
2) Use /sbin/wifi to turn off wifi.
uci set wireless.@wifi-device[0].disabled=1
uci commit
wifi
3) Observe that wifi is still up.
branches affected: trunk, 21.02
Signed-off-by: Bob Cantor <coxede6557@w3boats.com>
If drv_mac80211_setup is called twice with the same wifi configuration,
then the second call returns early with error HOSTAPD_START_FAILED.
(wifi works nevertheless, despite the fact that setup is incomplete. But
"ubus call network.wireless status" erroneously reports that radio0 is down.)
The relevant part of drv_mac80211_setup is,
if [ "$no_reload" != "0" ]; then
add_ap=1
ubus wait_for hostapd
local hostapd_res="$(ubus call hostapd config_add "{\"iface\":\"$primary_ap\", \"config\":\"${hostapd_conf_file}\"}")"
ret="$?"
[ "$ret" != 0 -o -z "$hostapd_res" ] && {
wireless_setup_failed HOSTAPD_START_FAILED
return
}
wireless_add_process "$(jsonfilter -s "$hostapd_res" -l 1 -e @.pid)" "/usr/sbin/hostapd" 1 1
fi
This commit sets no_reload = 0 during the second call of drv_mac80211_setup.
It is perhaps worth providing a way to reproduce the situation
where drv_mac80211_setup is called twice.
When /sbin/wifi is used to turn on wifi,
uci set wireless.@wifi-iface[0].disabled=0
uci set wireless.@wifi-device[0].disabled=0
uci commit
wifi
/sbin/wifi makes the following ubus calls,
ubus call network reload
ubus call network.wireless down
ubus call network.wireless up
The first and third ubus calls both call drv_mac80211_setup,
while the second ubus call triggers wireless_device_setup_cancel.
So the call sequence becomes,
drv_mac80211_setup
wireless_device_setup_cancel
drv_mac80211_setup
In contrast, when LuCI is used to turn on wifi only a single call
is made to drv_mac80211_setup.
branches affected: trunk, 21.02
Signed-off-by: Bob Cantor <coxede6557@w3boats.com>
Some drivers advertise it, but it's not supported at the moment
Reported-by: John Thomson <git@johnthomson.fastmail.com.au>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The colon does not directly follow the "VHT Capabilities" string
Reported-by: John Thomson <git@johnthomson.fastmail.com.au>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Testing with hwsim reveals two problems:
1. phyX/addresses has two addresses and mac80211_get_addr keeps
returning the last one when asked for more;
2. The base address has the local bit set and the operation unsets it.
Fix both.
Fixes: 866790fd82
Reported-by: Zero_Chaos
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
If mac80211_setup_supplicant() is called with enabled=0 then it should just
destroy the interface and remove the configuration from wpa_supplicant. But
the ubus method call always returned
Command failed: Method not found
because the actual name of the method is "config_remove".
Fixes: b5516603dd ("mac80211: more wifi reconf related fixes")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[bump PKG_RELEASE]
Signed-off-by: David Bauer <mail@david-bauer.net>
hostapd_set_bss_options expects the PHY as second and the VIF as third
argument. However, only the VIF was passed as second argument without a
third argument at all.
This was never a problem, as both PHY and VIF were never accessed.
However, with FTM support the PHY is needed to determine the HW support
when configuring the BSS.
Signed-off-by: David Bauer <mail@david-bauer.net>
This is useful to bring up multiple client mode interfaces on a single
channel much faster without having to scan through a lot of channels
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Some 5GHz wifi interfaces, especially in Tri-band routers, can't use
channel 36. In these cases, the default configuration for 5GHz
interfaces, once enabled, doesn't work.
This patch selects the first non-disabled channel for 5GHz interfaces.
Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
