aboutsummaryrefslogtreecommitdiffstats
path: root/package/kernel/mac80211/files
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: use 802.11ax iw modesDavid Bauer2023-01-281-3/+3
| | | | | | | | | | 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>
* mac80211: work around a race condition on detecting a phy while bringing it upFelix Fietkau2022-12-161-0/+4
| | | | | | | | 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>
* hostapd: use wpa_supplicant for unencrypted mesh connectionsFelix Fietkau2022-12-101-1/+1
| | | | | | It's more reliable than using iw Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: use board.json provided phy names in generated default configFelix Fietkau2022-10-141-51/+62
| | | | | | The phy will be automatically renamed on setup Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: change the default config for a renamed wiphyFelix Fietkau2022-10-141-21/+28
| | | | | | use option phy to reference the device instead of path/macaddr Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix detecting highest radio* config section indexFelix Fietkau2022-10-141-5/+10
| | | | | | Deal with gaps by iterating over existing sections instead of counting Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: rename phy according to board.json entries on bringupFelix Fietkau2022-10-141-3/+65
| | | | | | | This allows phy names specified in board.json to be used directly instead of the path option Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: change default ifname to <phy>-<type><index>Felix Fietkau2022-10-141-2/+17
| | | | | | | | 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>
* mac80211: fix typo in netifd scriptFelix Fietkau2022-10-131-1/+1
| | | | | | Reported-by: Chad Monroe <chad.monroe@smartrg.com> Fixes: 590eaaeed59a ("mac80211: fix issues in HE capabilities") Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix issues in HE capabilitiesFelix Fietkau2022-10-131-10/+22
| | | | | | | | | | | 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>
* mac80211: fix parameter reading for AC_BE tx burstingAlberto Martinez-Alvarez2022-09-241-2/+2
| | | | | | | | | | | | | | | 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>
* mac80211: parse the correct set of HE capabilities for AP modeSultan Alsawaf2022-08-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* base-files: wifi: add random MAC support for wifi-ifaceManas Sambhus2022-08-111-2/+5
| | | | | | | | | 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>
* hostapd: introduce min_tx_power optionStijn Tintel2022-06-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new option min_tx_power to configure the minimum permitted max TX power (in dBm) for ACS and DFS channel selection. Imagine the following regulatory rules: * 5180 MHz [36] (21.0 dBm) * 5200 MHz [40] (21.0 dBm) * 5220 MHz [44] (21.0 dBm) * 5240 MHz [48] (21.0 dBm) * 5260 MHz [52] (20.0 dBm) (radar detection) * 5280 MHz [56] (20.0 dBm) (radar detection) * 5300 MHz [60] (20.0 dBm) (radar detection) * 5320 MHz [64] (20.0 dBm) (radar detection) * 5500 MHz [100] (21.0 dBm) (radar detection) * 5520 MHz [104] (21.0 dBm) (radar detection) * 5540 MHz [108] (21.0 dBm) (radar detection) * 5560 MHz [112] (21.0 dBm) (radar detection) * 5580 MHz [116] (21.0 dBm) (radar detection) * 5600 MHz [120] (21.0 dBm) (radar detection) * 5620 MHz [124] (21.0 dBm) (radar detection) * 5640 MHz [128] (21.0 dBm) (radar detection) * 5660 MHz [132] (21.0 dBm) (radar detection) * 5680 MHz [136] (21.0 dBm) (radar detection) * 5700 MHz [140] (21.0 dBm) (radar detection) * 5720 MHz [144] (13.0 dBm) (radar detection) * 5745 MHz [149] (13.0 dBm) * 5765 MHz [153] (13.0 dBm) * 5785 MHz [157] (13.0 dBm) * 5805 MHz [161] (13.0 dBm) * 5825 MHz [165] (13.0 dBm) * 5845 MHz [169] (13.0 dBm) * 5865 MHz [173] (13.0 dBm) When ACS or DFS end up selecting channel 144 or higher, some clients might no longer be able to communicate with the AP due to the TX power being limited to 13 dBm. Setting min_tx_power to 20 will result in hostapd not considering these channels during ACS or after a DFS event. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> Acked-by: David Bauer <mail@david-bauer.net>
* hostapd: introduce background_radar optionStijn Tintel2022-06-281-1/+6
| | | | | | | | | | | | | | 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>
* hostapd: randomize default BSS colorDavid Bauer2022-06-081-1/+3
| | | | | | | 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>
* mac80211: set beamformer/beamformee number of antennas in VHT capsFelix Fietkau2021-11-221-0/+16
| | | | | | Without this, beamforming is probably not working Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix IBSS/adhoc mode for brcmfmacBastian Bittorf2021-11-191-0/+1
| | | | | | | | | | | | | | | | | | | | 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>
* mac80211: allow retry of wifi setup if an iw interface add command failsFelix Fietkau2021-09-301-1/+1
| | | | | | In some cases, spurious failures might be cleared by teardown and retry Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix HT40 mode for 6G bandFelix Fietkau2021-08-241-3/+4
| | | | | | The channel offset used for VHT segment calculation was missing for HT Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: print an error if wifi teardown failsBob Cantor2021-06-281-0/+4
| | | | | | | | | 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>
* mac80211: always call wireless_set_data (FS#3784)Bob Cantor2021-06-281-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mac80211: fix no_reload logic (FS#3902)Bob Cantor2021-06-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mac80211: fix processing HE capabilities (FS#3871)Felix Fietkau2021-06-171-1/+1
| | | | | | Use the right argument to fix setting unsupported capabilities to 0 Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: rely on iwinfo for phy->path and path->phy lookupsFelix Fietkau2021-06-103-41/+3
| | | | | | This avoids inconsistencies from having multiple implementations do the same thing Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix typoFelix Fietkau2021-06-031-1/+1
| | | | | | Remove stray parenthesis Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: do not enable VHT in the default config on 2.4 GHzFelix Fietkau2021-06-021-1/+1
| | | | | | | 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>
* mac80211: fix detecting VHT capabilities when generating the default configFelix Fietkau2021-06-021-1/+1
| | | | | | | 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>
* mac80211: add more HE capabilitiesFelix Fietkau2021-05-261-5/+81
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix center freq selection for 6 GHzFelix Fietkau2021-05-261-6/+20
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: set hostapd op_class for 6 GHzFelix Fietkau2021-05-261-0/+8
| | | | | | This is needed to disambiguate it from 5 GHz channels Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: rework default config scriptFelix Fietkau2021-05-261-20/+85
| | | | | | | Emit the new band option instead of hwmode Support 6 GHz band and HE options Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: make use of the new 'band' optionFelix Fietkau2021-05-261-14/+31
| | | | | | | Use it to look up frequencies only in the configured band to better deal with channel number overlap Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix incorrect parameterDavid Bauer2021-02-011-1/+1
| | | | | | | he_mu_beamformer only accepts values of 0 and 1 according to the hostapd documentation. Signed-off-by: David Bauer <mail@david-bauer.net>
* mac80211: improve error handling when adding hostapd configDaniel Golle2021-01-141-7/+7
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mac80211: use hostapd PID returned from config_addDaniel Golle2021-01-101-2/+1
| | | | | | | Use PID returned from config_add instead of querying procd when adding configuration to hostapd. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mac80211: add 802.11ad-supportGary Cooper2021-01-051-0/+6
| | | | | | This adds logic to properly populate defaults in /etc/config/wireless. Signed-off-by: Gary Cooper <gaco@bitmessage.de>
* hostapd: do not restart hostapd instance on wireless restartsFelix Fietkau2020-12-311-1/+1
| | | | | | Add the flag that prevents netifd from killing hostapd/wpa_supplicant Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: fix MAC address allocations when local bit set on base addrPaul Fertser2020-12-221-2/+2
| | | | | | | | | | | | | | | 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>
* mac80211: Fix wpa_supplicant config removal ubus callSven Eckelmann2020-10-281-1/+1
| | | | | | | | | | | | | | | 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>
* mac80211: pass phy name to hostapd_set_bss_optionsDavid Bauer2020-10-281-1/+1
| | | | | | | | | | | | 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>
* mac80211: add support for specifying a per-device scan listFelix Fietkau2020-09-291-0/+2
| | | | | | | 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>
* mac80211: select the first available channel for 5GHz interfacesDavide Fioravanti2020-09-201-2/+2
| | | | | | | | | | 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>
* mac80211: add preliminary support for enabling 802.11ax in configFelix Fietkau2020-09-041-12/+37
| | | | | | No advanced features are configurable yet, just basic enabling of HE modes Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: don't kill wireless daemon on teardownDavid Bauer2020-07-311-2/+0
| | | | | | | | 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>
* hostapd: fix incorrect service nameDavid Bauer2020-07-311-1/+1
| | | | | | | | | | | | | | 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>
* mac80211: create channel list for fixed channel operationDavid Bauer2020-07-201-0/+3
| | | | | | | | | | | | 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>
* mac80211: allow ACS restriction with fixed channelJan Hoffmann2020-07-061-1/+1
| | | | | | | | | | | This can be useful when a DFS channel is configured, as the ACS channel list is taken into account when switching channels after a radar event. For example, this allows to prevent the SRD channels from being used in that case. Signed-off-by: Jan Hoffmann <jan@3e8.eu> [reorder structure] Signed-off-by: David Bauer <mail@david-bauer.net>
* mac80211: fix use of local variableLeon M. George2020-06-241-1/+1
| | | | | | | | | | mac80211_get_addr is called from mac80211_generate_mac, where the local variable initialisation id="${macidx:-0}" suggests that macidx is not always defined. Probably, idx was supposed to be used instead of $(($macidx + 1)). Fixes: 4d99db168cf7 ("mac80211: try to get interface addresses from wiphy sysfs 'addresses' if no mask is set") Signed-off-by: Leon M. George <leon@georgemail.eu>
* hostapd: add support for wifi-station and wifi-vlan sectionsJohn Crispin2020-06-041-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for 2 new uci sections. config wifi-vlan # iface is optional. if it is not defined the vlan will apply # to all interfaces option iface default_radio0 option name guest option vid 100 option network guest config wifi-station # iface is optional. if it is not defined the station will apply # to all interfaces option iface default_radio0 # mac is optional. if it is not defined it will be a catch all # for any sta using this key option mac '00:11:22:33:44:55' # vid is optional. if it is not defined, the sta will be part of # the primary iface. option vid 100 option key testtest With this patch applied it is possible to use multiple PSKs on a single BSS. Signed-off-by: John Crispin <john@phrozen.org>