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>
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: 866790fd827cb0187353cdf484eb46a9b38fb6ba
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: b5516603dd90 ("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>
Don't kill the wireless daemon on teardown. hostapd as well as
wpa_supplicant are managed by procd which would detect the shutdown of
either process as a crash loop.
Signed-off-by: David Bauer <mail@david-bauer.net>
When retrieving the PID for hostapd and wpa_supplicant via ubus the
wrong service name is currently used. This leads to the following error
in the log:
netifd: radio0 (1409): WARNING (wireless_add_process):
executable path /usr/sbin/wpad does not match process path (/proc/exe)
Fixing the service name retrieves the correct PID and therefore the
warning won't occur.
Signed-off-by: David Bauer <mail@david-bauer.net>
Currently a device which has a DFS channel selected using the UCI
channel setting might switch to a non-DFS channel in case no chanlist is
provided (UCI setting "channels") when the radio detects a DFS event.
Automatically add a chanlist consisting of the configured channel when
the device does not operate in auto-channel mode and no chanlist set to
circumvent this issue.
Signed-off-by: David Bauer <mail@david-bauer.net>
