Kernel/iwd
3
0
Fork 0
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git synced 2024-11-22 06:29:23 +01:00
Code Releases Activity
a910a21beb
iwd/src/wiphy.h

174 lines
6.3 KiB
C
Raw Normal View History

core: Add skeleton for nl80211 setup
2014-07-29 21:25:01 +02:00
/*
*
* Wireless daemon for Linux
*
treewide: Move the Intel copyright forward to 2019
2019-10-25 00:43:08 +02:00
* Copyright (C) 2013-2019 Intel Corporation. All rights reserved.
core: Add skeleton for nl80211 setup
2014-07-29 21:25:01 +02:00
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
core: Add sanity check to sync RTNL link deletion with nl80211
2014-08-07 08:52:42 +02:00
#include <stdint.h>
core: Add skeleton for nl80211 setup
2014-07-29 21:25:01 +02:00
#include <stdbool.h>
wiphy: Expose wiphy_select_cipher
2016-05-16 19:21:26 +02:00
struct wiphy;
wiphy: Add utility to check if bss ciphers compatible Move the BSS's supported ciphers checks from network_bss_select to a new function in wiphy.c so we can reuse it in device.c.
2017-01-20 06:49:40 +01:00
struct scan_bss;
wiphy: Add freq set constrain API
2019-04-11 21:14:27 +02:00
struct scan_freq_set;
wiphy: introduce new radio management APIs These APIs will handle fairness and order in any operations which radios can only do sequentially (offchannel, scanning, connection etc.). Both scan and frame-xchg are complex modules (especially scanning) which is why the radio management APIs were implemented generic enough where the changes to both modules will be minimal. Any module that requires this kind of work can push a work item into the radio management work queue (wiphy_radio_work_insert) and when the work is ready to be started radio management will call back into the module. Once the work is completed (and this may be some time later e.g. in scan results or a frame watch) the module can signal back that the work is finished (wiphy_radio_work_done). Wiphy will then pop the queue and continue with the next work item. A concept of priority was added in order to allow important offchannel operations (e.g. ANQP) to take priority over other work items. The priority is an integer, where lower values are of a higher priority. The concept of priority cleanly solves a lot of the complexity that was added in order to support ANQP queries (suspending scanning and waiting for ANQP to finish before connecting). Instead ANQP queries can be queued at a higher priority than scanning which removes the need for suspending scans. In addition we can treat connections as radio management work and insert them at a lower priority than ANQP, but higher than scanning. This forces the connection to wait for ANQP without having to track any state.
2020-07-09 02:04:32 +02:00
struct wiphy_radio_work_item;
network: Enforce Transition Disable settings Transition Disable indications and information stored in the network profile needs to be enforced. Since Transition Disable information is now stored inside the network object, add a new method 'network_can_connect_bss' that will take this information into account. wiphy_can_connect method is thus deprecated and removed. Transition Disable can also result in certain AKMs and pairwise ciphers being disabled, so wiphy_select_akm method's signature is changed and takes the (possibly overriden) ie_rsn_info as input.
2021-07-27 20:59:52 +02:00
struct ie_rsn_info;
wiphy: parse/store frequency info in band object As additional frequency info is needed it doesn't make sense to store a full list of frequencies for every attribute (i.e. supported, disabled, no-IR, etc). This changes nl80211_parse_supported_frequencies to take a list of frequency attributes where each index corresponds to a channel, and each value can be filled with flag bits to signal any limitations on that frequency. wiphy.c then had to be updated to use this rather than the existing scan_freq_set lists. This, as-is, will break anything using wiphy_get_disabled_freqs().
2022-12-16 22:27:35 +01:00
struct band_freq_attrs;
network: Enforce Transition Disable settings Transition Disable indications and information stored in the network profile needs to be enforced. Since Transition Disable information is now stored inside the network object, add a new method 'network_can_connect_bss' that will take this information into account. wiphy_can_connect method is thus deprecated and removed. Transition Disable can also result in certain AKMs and pairwise ciphers being disabled, so wiphy_select_akm method's signature is changed and takes the (possibly overriden) ie_rsn_info as input.
2021-07-27 20:59:52 +02:00
enum security;
wiphy: use enum band_freq with rates getter wiphy_get_supported_rates expected an enum defined in the nl80211 header but the argument type was an unsigned int, not exactly intuitive to anyone using the API. Since the nl80211 enum value was only used in a switch statement it could just as well be IWD's internal enum band_freq. This also allows modules which do not reference nl80211.h to use wiphy_get_supported_rates().
2022-12-09 20:39:27 +01:00
enum band_freq;
wiphy: introduce new radio management APIs These APIs will handle fairness and order in any operations which radios can only do sequentially (offchannel, scanning, connection etc.). Both scan and frame-xchg are complex modules (especially scanning) which is why the radio management APIs were implemented generic enough where the changes to both modules will be minimal. Any module that requires this kind of work can push a work item into the radio management work queue (wiphy_radio_work_insert) and when the work is ready to be started radio management will call back into the module. Once the work is completed (and this may be some time later e.g. in scan results or a frame watch) the module can signal back that the work is finished (wiphy_radio_work_done). Wiphy will then pop the queue and continue with the next work item. A concept of priority was added in order to allow important offchannel operations (e.g. ANQP) to take priority over other work items. The priority is an integer, where lower values are of a higher priority. The concept of priority cleanly solves a lot of the complexity that was added in order to support ANQP queries (suspending scanning and waiting for ANQP to finish before connecting). Instead ANQP queries can be queued at a higher priority than scanning which removes the need for suspending scans. In addition we can treat connections as radio management work and insert them at a lower priority than ANQP, but higher than scanning. This forces the connection to wait for ANQP without having to track any state.
2020-07-09 02:04:32 +02:00
typedef bool (*wiphy_radio_work_func_t)(struct wiphy_radio_work_item *item);
typedef void (*wiphy_radio_work_destroy_func_t)(
struct wiphy_radio_work_item *item);
struct wiphy_radio_work_item_ops {
wiphy_radio_work_func_t do_work;
wiphy_radio_work_destroy_func_t destroy;
};
struct wiphy_radio_work_item {
uint32_t id;
int priority;
const struct wiphy_radio_work_item_ops *ops;
};
wiphy: add __iwd_device_foreach
2014-10-24 04:47:38 +02:00
wiphy: Use anonymous enum in favor of #defines
2022-03-02 20:55:26 +01:00
enum {
wiphy: add new work priority for FT FT is special in that it really should not be interrupted. Since FRAME/OFFCHANNEL have the highest priority we run the risk of DPP or some other offchannel operation interfering with FT.
2022-09-22 00:31:46 +02:00
WIPHY_WORK_PRIORITY_FT = 0,
WIPHY_WORK_PRIORITY_FRAME = 1,
WIPHY_WORK_PRIORITY_OFFCHANNEL = 1,
WIPHY_WORK_PRIORITY_CONNECT = 2,
WIPHY_WORK_PRIORITY_SCAN = 3,
WIPHY_WORK_PRIORITY_PERIODIC_SCAN = 4,
wiphy: Use anonymous enum in favor of #defines
2022-03-02 20:55:26 +01:00
};
wiphy: define work priorities in one place Work priority was never explicitly defined anywhere, and a module using wiphy_radio_work APIs needed to ensure it was not inserting at a priority that would interfere with other work. Now all the types of work have been defined with their own priority and future priorities can easily be added before, after, or in between existing priorities.
2022-01-11 18:45:09 +01:00
wiphy: Add wiphy state watch add / remove
2018-11-29 18:22:50 +01:00
enum wiphy_state_watch_event {
WIPHY_STATE_WATCH_EVENT_POWERED,
WIPHY_STATE_WATCH_EVENT_RFKILLED,
wiphy: add two regulatory domain state events Events to indicate when a regulatory domain wiphy dump has started and ended. This is important because certain actions such as scanning need to be delayed until the dump has finished.
2022-08-03 23:36:37 +02:00
WIPHY_STATE_WATCH_EVENT_REGDOM_STARTED,
WIPHY_STATE_WATCH_EVENT_REGDOM_DONE,
wiphy: Add wiphy state watch add / remove
2018-11-29 18:22:50 +01:00
};
typedef void (*wiphy_state_watch_func_t)(struct wiphy *wiphy,
enum wiphy_state_watch_event event,
void *user_data);
typedef void (*wiphy_destroy_func_t)(void *user_data);
wiphy: Expose wiphy_select_cipher
2016-05-16 19:21:26 +02:00
enum ie_rsn_cipher_suite wiphy_select_cipher(struct wiphy *wiphy,
uint16_t mask);
wiphy: add wiphy_get_supported_ciphers Similar to wiphy_select_cipher but returns all supported ciphers included in the mask rather than just one.
2022-11-02 23:51:06 +01:00
uint16_t wiphy_get_supported_ciphers(struct wiphy *wiphy, uint16_t mask);
wiphy: added wiphy_select_akm This is a replacement for station's static select_akm_suite. This was done because wiphy can make a much more intellegent decision about the akm suite by checking the wiphy supported features e.g. SAE support. This allows a connection to hybrid WPA2/WPA3 AP's if SAE is not supported in the kernel.
2018-09-24 23:29:53 +02:00
enum ie_rsn_akm_suite wiphy_select_akm(struct wiphy *wiphy,
network: Enforce Transition Disable settings Transition Disable indications and information stored in the network profile needs to be enforced. Since Transition Disable information is now stored inside the network object, add a new method 'network_can_connect_bss' that will take this information into account. wiphy_can_connect method is thus deprecated and removed. Transition Disable can also result in certain AKMs and pairwise ciphers being disabled, so wiphy_select_akm method's signature is changed and takes the (possibly overriden) ie_rsn_info as input.
2021-07-27 20:59:52 +02:00
const struct scan_bss *bss,
enum security security,
const struct ie_rsn_info *info,
wiphy: handle FILS AKMs wiphy_select_akm needed to be updated to take a flag, which can be set to true if there are known reauth keys for this connection. If we have reauth keys, and FILS is available we will choose it.
2019-04-19 21:59:03 +02:00
bool fils_capable_hint);
wiphy: Expose wiphy_select_cipher
2016-05-16 19:21:26 +02:00
wiphy: Add wiphy_find
2016-06-01 22:20:33 +02:00
struct wiphy *wiphy_find(int wiphy_id);
wiphy: Use an inline function in favor of a macro
2022-03-02 20:57:00 +01:00
static inline struct wiphy *wiphy_find_by_wdev(uint64_t w)
{
return wiphy_find(w >> 32);
}
wiphy: add convenience API wiphy_find_by_wdev
2020-07-02 19:35:27 +02:00
manager: Handle missing NEW_WIPHY events The kernel emits NEW_WIPHY events whenever a new wiphy is registered. Unfortunately these events are emitted under the 'legacy' semantics and have a hard size limit of 4096 bytes. Unfortunately, it is possible for a NEW_WIPHY message to exceed this limit (ath10k cards seem to be affected in particular), which results in the kernel never sending these messages out. This can lead to NEW_INTERFACE events being emitted with a wiphy_id that had no corresponding NEW_WIPHY event emitted. Such a sequence can confuse iwd's hardware detection logic, particularly during hot-plug or system boot. Fix this by re-dumping the wiphy if such a condition is detected. This has some interaction with blacklisted wiphys, so the wiphy objects are now always tracked and marked as blacklisted. Before, the blacklisted wiphys were simply not added to the iwd list of tracked wiphys.
2020-02-03 23:25:07 +01:00
bool wiphy_is_blacklisted(const struct wiphy *wiphy);
wiphy: Add wiphy_find
2016-06-01 22:20:33 +02:00
wiphy: Add wiphy_create/wiphy_destroy API Add wiphy_create, wiphy_update_from_genl and wiphy_destroy that together will let a new file command the wiphy creation, updates and deletion with the same functionality the current config notification handler implements in wiphy.c.
2019-04-11 03:10:23 +02:00
struct wiphy *wiphy_create(uint32_t wiphy_id, const char *name);
manager: Handle missing NEW_WIPHY events The kernel emits NEW_WIPHY events whenever a new wiphy is registered. Unfortunately these events are emitted under the 'legacy' semantics and have a hard size limit of 4096 bytes. Unfortunately, it is possible for a NEW_WIPHY message to exceed this limit (ath10k cards seem to be affected in particular), which results in the kernel never sending these messages out. This can lead to NEW_INTERFACE events being emitted with a wiphy_id that had no corresponding NEW_WIPHY event emitted. Such a sequence can confuse iwd's hardware detection logic, particularly during hot-plug or system boot. Fix this by re-dumping the wiphy if such a condition is detected. This has some interaction with blacklisted wiphys, so the wiphy objects are now always tracked and marked as blacklisted. Before, the blacklisted wiphys were simply not added to the iwd list of tracked wiphys.
2020-02-03 23:25:07 +01:00
void wiphy_update_name(struct wiphy *wiphy, const char *name);
wiphy: Add wiphy_create_complete Let manager.c signal to wiphy.c when the wiphy parsing from the genl messages is complete. When we query for existing wiphy using the GET_WIPHY dump command we get many genl messages per wiphy, on a notification we only get one message. So after wiphy_create there may be one or many calls to wiphy_update_from_genl. wiphy_create_complete is called after all of them, so wiphy.c can be sure it's done with parsing the wiphy attributes when in prints the new wiphy summary log message, like it did before manager.c was added. I had wrongly assumed that all the important wiphy attributes were in the first message in the dump, but NL80211_ATTR_EXT_FEATURES was not and wasn't being parsed which was breaking at least testRSSIAgent.
2019-04-20 22:29:06 +02:00
void wiphy_create_complete(struct wiphy *wiphy);
wiphy: Add wiphy_create/wiphy_destroy API Add wiphy_create, wiphy_update_from_genl and wiphy_destroy that together will let a new file command the wiphy creation, updates and deletion with the same functionality the current config notification handler implements in wiphy.c.
2019-04-11 03:10:23 +02:00
bool wiphy_destroy(struct wiphy *wiphy);
manager: Handle missing NEW_WIPHY events The kernel emits NEW_WIPHY events whenever a new wiphy is registered. Unfortunately these events are emitted under the 'legacy' semantics and have a hard size limit of 4096 bytes. Unfortunately, it is possible for a NEW_WIPHY message to exceed this limit (ath10k cards seem to be affected in particular), which results in the kernel never sending these messages out. This can lead to NEW_INTERFACE events being emitted with a wiphy_id that had no corresponding NEW_WIPHY event emitted. Such a sequence can confuse iwd's hardware detection logic, particularly during hot-plug or system boot. Fix this by re-dumping the wiphy if such a condition is detected. This has some interaction with blacklisted wiphys, so the wiphy objects are now always tracked and marked as blacklisted. Before, the blacklisted wiphys were simply not added to the iwd list of tracked wiphys.
2020-02-03 23:25:07 +01:00
void wiphy_update_from_genl(struct wiphy *wiphy, struct l_genl_msg *msg);
wiphy: Add wiphy_create/wiphy_destroy API Add wiphy_create, wiphy_update_from_genl and wiphy_destroy that together will let a new file command the wiphy creation, updates and deletion with the same functionality the current config notification handler implements in wiphy.c.
2019-04-11 03:10:23 +02:00
wiphy: Add freq set constrain API
2019-04-11 21:14:27 +02:00
bool wiphy_constrain_freq_set(const struct wiphy *wiphy,
struct scan_freq_set *set);
wiphy: Add wiphy_get_id
2020-02-04 00:37:08 +01:00
uint32_t wiphy_get_id(struct wiphy *wiphy);
wiphy: Add Adapter objects above Device Change the path for net.connman.iwd.Device objects to /phyX/Y and register net.connman.iwd.Adapter at /phyX grouping devices of the same wiphy. Turns out no changes to the test/* scripts are needed.
2016-07-12 04:13:54 +02:00
const char *wiphy_get_path(struct wiphy *wiphy);
wiphy: Add wiphy_get_supported_bands
2016-09-13 21:36:46 +02:00
uint32_t wiphy_get_supported_bands(struct wiphy *wiphy);
wiphy: Add accessor for supported frequencies
2019-02-28 01:44:17 +01:00
const struct scan_freq_set *wiphy_get_supported_freqs(
const struct wiphy *wiphy);
wiphy: parse/store frequency info in band object As additional frequency info is needed it doesn't make sense to store a full list of frequencies for every attribute (i.e. supported, disabled, no-IR, etc). This changes nl80211_parse_supported_frequencies to take a list of frequency attributes where each index corresponds to a channel, and each value can be filled with flag bits to signal any limitations on that frequency. wiphy.c then had to be updated to use this rather than the existing scan_freq_set lists. This, as-is, will break anything using wiphy_get_disabled_freqs().
2022-12-16 22:27:35 +01:00
wiphy: add getter for frequency/band info This adds two new APIs: wiphy_get_frequency_info(): Used to get information about a given frequency such as disabled/no-IR. This can also be used to check if the frequency is supported (NULL return is unsupported). wiphy_band_is_disabled(): Checks if a band is disabled. Note that an unsupported band will also return true. Checking support should be done with wiphy_get_supported_bands()
2022-12-16 22:27:38 +01:00
const struct band_freq_attrs *wiphy_get_frequency_info(
const struct wiphy *wiphy,
uint32_t freq);
wiphy: add wiphy_get_frequency_info_list Gets the entire list of frequency attributes advertised. This is needed for AP mode to create a country IE which includes subband triplet fields.
2022-12-30 23:12:13 +01:00
const struct band_freq_attrs *wiphy_get_frequency_info_list(
const struct wiphy *wiphy,
enum band_freq band,
size_t *size);
wiphy: make wiphy_band_is_disabled return more descriptive The function wiphy_band_is_disabled() return was a bit misleading because if the band was not supported it would return true which could be misunderstood as the band is supported, but disabled. There was only one call site and because of this behavior wiphy_band_is_disabled needed to be paired with checking if the band was supported. To be more descriptive to the caller, wiphy_band_is_disabled() now returns an int and if the band isn't supported -ENOTSUP will be returned, otherwise 1 is returned if the band is disabled and 0 otherwise.
2023-09-29 18:19:57 +02:00
int wiphy_band_is_disabled(const struct wiphy *wiphy, enum band_freq band);
wiphy: add getter for frequency/band info This adds two new APIs: wiphy_get_frequency_info(): Used to get information about a given frequency such as disabled/no-IR. This can also be used to check if the frequency is supported (NULL return is unsupported). wiphy_band_is_disabled(): Checks if a band is disabled. Note that an unsupported band will also return true. Checking support should be done with wiphy_get_supported_bands()
2022-12-16 22:27:38 +01:00
wiphy: add wiphy_supports_probe_resp_offload Parse the AP probe response offload attribute during the dump. If set this indicates the driver expects the probe response attribute to be included with START_AP.
2022-09-28 21:48:51 +02:00
bool wiphy_supports_probe_resp_offload(struct wiphy *wiphy);
wiphy: Add wiphy_can_transition_disable
2021-07-27 19:59:03 +02:00
bool wiphy_can_transition_disable(struct wiphy *wiphy);
wiphy: add wiphy_can_offload This is a convenience method for detecting any supported offload extended features (4way/1x/SAE).
2021-10-19 23:52:46 +02:00
bool wiphy_can_offload(struct wiphy *wiphy);
wiphy: add getter for 'supports_cmds_auth_assoc'
2021-03-22 17:01:51 +01:00
bool wiphy_supports_cmds_auth_assoc(struct wiphy *wiphy);
wiphy: Add MAC randomization feature check API
2019-01-16 04:14:54 +01:00
bool wiphy_can_randomize_mac_addr(struct wiphy *wiphy);
wiphy: Add wiphy_rrm_capable
2019-07-10 23:23:13 +02:00
bool wiphy_rrm_capable(struct wiphy *wiphy);
wiphy: add wiphy_supports_ext_key_id
2021-10-04 18:48:52 +02:00
bool wiphy_supports_ext_key_id(struct wiphy *wiphy);
wiphy: added accessor for the feature flags
2018-05-24 19:12:10 +02:00
bool wiphy_has_feature(struct wiphy *wiphy, uint32_t feature);
wiphy: Rename get_ext_feature API to has_ext_feature
2018-05-24 20:12:36 +02:00
bool wiphy_has_ext_feature(struct wiphy *wiphy, uint32_t feature);
wiphy: add support for MAX_NUM_SCAN_SSIDS
2018-05-09 00:54:40 +02:00
uint8_t wiphy_get_max_num_ssids_per_scan(struct wiphy *wiphy);
wiphy: Add parser and getter for max ie len attr
2019-11-06 23:16:23 +01:00
uint16_t wiphy_get_max_scan_ie_len(struct wiphy *wiphy);
wiphy: Add wiphy_get_max_roc_duration Add a function to retrieve the maximum Remain On Channel listen duration supported by the wiphy's driver.
2019-10-21 15:55:09 +02:00
uint32_t wiphy_get_max_roc_duration(struct wiphy *wiphy);
wiphy: Parse & report supported interface types
2018-08-07 18:53:31 +02:00
bool wiphy_supports_iftype(struct wiphy *wiphy, uint32_t iftype);
wiphy: use enum band_freq with rates getter wiphy_get_supported_rates expected an enum defined in the nl80211 header but the argument type was an unsigned int, not exactly intuitive to anyone using the API. Since the nl80211 enum value was only used in a switch statement it could just as well be IWD's internal enum band_freq. This also allows modules which do not reference nl80211.h to use wiphy_get_supported_rates().
2022-12-09 20:39:27 +01:00
const uint8_t *wiphy_get_supported_rates(struct wiphy *wiphy,
enum band_freq band,
wiphy: Add wiphy_get_supported_rates Add code to parse the supported data rates info from the wiphy dumps and expose it for P2P's use with a getter function.
2019-10-28 15:04:53 +01:00
unsigned int *out_num);
wiphy: set QoS bit in extended capabilities
2019-09-14 00:26:30 +02:00
bool wiphy_supports_qos_set_map(struct wiphy *wiphy);
wiphy: parse NL80211_ATTR_ROAM_SUPPORT flag This tells us if the hardware is going to automatically roam. We need this to know if station roaming logic should be disabled.
2021-03-15 18:29:30 +01:00
bool wiphy_supports_firmware_roam(struct wiphy *wiphy);
wiphy: Add wiphy_get_driver api Read the driver name for each wiphy from sysfs if available. I didn't find a better way to obtain the driver name for a phy than by reading the dir name that the "driver" symlink points at. For an existing netdev this can be done using the SIOCETHTOOL ioctl.
2019-05-08 03:15:26 +02:00
const char *wiphy_get_driver(struct wiphy *wiphy);
wiphy: Add wiphy_get_name
2019-07-02 01:28:07 +02:00
const char *wiphy_get_name(struct wiphy *wiphy);
manager/wiphy: Move default if determination Move the driver database into wiphy.c so it can be extended with other potential driver quirks.
2021-10-01 15:49:07 +02:00
bool wiphy_uses_default_if(struct wiphy *wiphy);
wiphy: change wiphy_control_port_capable -> enabled Move the reading of ControlPortOverNL80211 into wiphy itself and renamed wiphy_control_port_capable to wiphy_control_port_enabled. This makes things easier for any modules interested in control port support since they will only have to check this one API rather than read the settings and check capability.
2021-10-07 22:49:45 +02:00
bool wiphy_control_port_enabled(struct wiphy *wiphy);
wiphy: add [DriverQuirks].PowerSaveDisable flag Certain drivers do not handle power save very well resulting in missed frames, firmware crashes, or other bad behavior. Its easy enough to disable power save via iw, iwconfig, etc but since IWD removes and creates the interface on startup it blows away any previous power save setting. The setting must be done *after* IWD creates the interface which can be done, but needs to be via some external daemon monitoring IWD's state. For minimal systems, e.g. without NetworkManager, it becomes difficult and annoying to persistently disable power save. For this reason a new driver flag POWER_SAVE_DISABLE is being added. This can then be referenced when creating the interfaces and if set, disable power save.
2023-06-15 21:24:12 +02:00
bool wiphy_power_save_disabled(struct wiphy *wiphy);
wiphy: add OweDisable driver quirk Some drivers like brcmfmac don't support OWE but from userspace its not possible to query this information. Rather than completely blacklist brcmfmac we can allow the user to configure this and disable OWE in IWD.
2024-10-23 20:29:09 +02:00
bool wiphy_owe_disabled(struct wiphy *wiphy);
wiphy: Parse driver extended capabilities
2019-07-10 17:53:07 +02:00
const uint8_t *wiphy_get_extended_capabilities(struct wiphy *wiphy,
uint32_t iftype);
wiphy: Setup RM Enabled Capabilities in wiphy
2019-08-23 15:55:54 +02:00
const uint8_t *wiphy_get_rm_enabled_capabilities(struct wiphy *wiphy);
wiphy: Add wiphy_get_rsnxe Returns a template RSNX element that can be further modified by callers to set any additional capabilities if required. wiphy will fill in those capabilities that are driver / firmware dependent.
2021-07-13 21:43:52 +02:00
bool wiphy_get_rsnxe(const struct wiphy *wiphy, uint8_t *buf, size_t len);
wiphy: Track regulatory domain changes When a new wiphy is added query its regulatory domain and listen for nl80211 regulatory notifications to be able to provide current regulatory country code through the new wiphy_get_reg_domain_country().
2020-04-23 18:24:35 +02:00
void wiphy_get_reg_domain_country(struct wiphy *wiphy, char *out);
wiphy: add wiphy_country_is_unknown A helper to check whether the country code corresponds to a real country, or some special code indicating the country isn't yet set. For now, the special codes are OO (world roaming) and XX (unknown entity).
2022-08-03 23:36:40 +02:00
bool wiphy_country_is_unknown(struct wiphy *wiphy);
wiphy: add wiphy_supports_uapsd
2022-12-20 22:43:15 +01:00
bool wiphy_supports_uapsd(const struct wiphy *wiphy);
wiphy: add flag for supporting remain on channel
2024-08-29 13:41:00 +02:00
bool wiphy_supports_cmd_offchannel(const struct wiphy *wiphy);
wiphy: Add wiphy_supports_adhoc_rsn
2018-08-07 18:15:23 +02:00
wiphy: add getter for HT capabilities This adds some additional parsing to obtain the AMPDU parameter byte as well as wiphy_get_ht_capabilities() which returns the complete IE (combining the 3 separate kernel attributes).
2022-12-20 22:43:12 +01:00
const uint8_t *wiphy_get_ht_capabilities(const struct wiphy *wiphy,
enum band_freq band,
size_t *size);
wiphy: Add wiphy_generate_random_address
2019-07-02 01:28:26 +02:00
void wiphy_generate_random_address(struct wiphy *wiphy, uint8_t addr[static 6]);
netdev: Fix buffer overflow with 32 character ssids ssid is declared as a 32 byte field in handshake_state, hence using it as a string which is assumed to be nul-terminated will fail for SSIDs that are 32 bytes long. Fixes: 1f1478285725 ("wiphy: add _generate_address_from_ssid") Fixes: 5a1b1184fca6 ("netdev: support per-network MAC addresses")
2023-11-27 05:38:45 +01:00
void wiphy_generate_address_from_ssid(struct wiphy *wiphy,
const uint8_t *ssid, size_t ssid_len,
wiphy: add _generate_address_from_ssid This API is being added to support per-network MAC address generation. The MAC is generated based on the network SSID and the adapters permanent address using HMAC-SHA256. The SHA digest is then constrained to make it MAC address compliant. Generating the MAC address like this will ensure that the MAC remains the same each time a given SSID is connected to.
2020-03-18 19:54:17 +01:00
uint8_t addr[static 6]);
wiphy: Add wiphy_generate_random_address
2019-07-02 01:28:26 +02:00
wiphy: Add wiphy_estimate_data_rate The data rate estimation belongs in wiphy since it should take hardware capabilities into account. Right now the data rate calculation simply assumes the hardware is as capable as the AP. scan.c will be ported to use this utility and the data rate estimation will be expanded to take wiphy capabilities into account.
2021-05-28 23:06:26 +02:00
int wiphy_estimate_data_rate(struct wiphy *wiphy,
const void *ies, uint16_t ies_len,
const struct scan_bss *bss,
uint64_t *out_data_rate);
wiphy: add wiphy_regdom_is_updating This allows a module to check the current status of the regdom in case it misses the wiphy event (e.g. registers after the STARTED event).
2022-08-04 20:51:08 +02:00
bool wiphy_regdom_is_updating(struct wiphy *wiphy);
wiphy: Add wiphy_estimate_data_rate The data rate estimation belongs in wiphy since it should take hardware capabilities into account. Right now the data rate calculation simply assumes the hardware is as capable as the AP. scan.c will be ported to use this utility and the data rate estimation will be expanded to take wiphy capabilities into account.
2021-05-28 23:06:26 +02:00
wiphy: Add wiphy state watch add / remove
2018-11-29 18:22:50 +01:00
uint32_t wiphy_state_watch_add(struct wiphy *wiphy,
wiphy_state_watch_func_t func, void *user_data,
wiphy_destroy_func_t destroy);
bool wiphy_state_watch_remove(struct wiphy *wiphy, uint32_t id);
wiphy: introduce new radio management APIs These APIs will handle fairness and order in any operations which radios can only do sequentially (offchannel, scanning, connection etc.). Both scan and frame-xchg are complex modules (especially scanning) which is why the radio management APIs were implemented generic enough where the changes to both modules will be minimal. Any module that requires this kind of work can push a work item into the radio management work queue (wiphy_radio_work_insert) and when the work is ready to be started radio management will call back into the module. Once the work is completed (and this may be some time later e.g. in scan results or a frame watch) the module can signal back that the work is finished (wiphy_radio_work_done). Wiphy will then pop the queue and continue with the next work item. A concept of priority was added in order to allow important offchannel operations (e.g. ANQP) to take priority over other work items. The priority is an integer, where lower values are of a higher priority. The concept of priority cleanly solves a lot of the complexity that was added in order to support ANQP queries (suspending scanning and waiting for ANQP to finish before connecting). Instead ANQP queries can be queued at a higher priority than scanning which removes the need for suspending scans. In addition we can treat connections as radio management work and insert them at a lower priority than ANQP, but higher than scanning. This forces the connection to wait for ANQP without having to track any state.
2020-07-09 02:04:32 +02:00
uint32_t wiphy_radio_work_insert(struct wiphy *wiphy,
struct wiphy_radio_work_item *item,
int priority,
const struct wiphy_radio_work_item_ops *ops);
void wiphy_radio_work_done(struct wiphy *wiphy, uint32_t id);
wiphy: update wiphy_radio_work_is_running to return int This differentiates between pending, running, and non-existent: false, true, -ENOENT respectively
2021-12-06 21:17:25 +01:00
int wiphy_radio_work_is_running(struct wiphy *wiphy, uint32_t id);
wiphy: make wiphy work queue reentrant In some situations its convenient for the same work item to be inserted (rescheduled) while its in progress. FT for example does this now if a roam fails. The same ft_work item gets re-inserted which, currently, is not safe to do since the item is modified and removed once completed. Fix this by introducing wiphy_radio_work_reschedule which is an explicit API for re-inserting work items from within the do_work callback. The wiphy work logic was changed around slightly to remove the item at the head of the queue prior to starting and note the ID going into do_work. If do_work signaled done and ID changed we know it was re-inserted and can skip the destroy logic and move onto the next item. If the item is not done continue as normal but set the priority to INT_MIN, as usual, to prevent other items from getting to the head of the queue.
2023-05-18 18:49:59 +02:00
uint32_t wiphy_radio_work_reschedule(struct wiphy *wiphy,
struct wiphy_radio_work_item *item);
Copy Permalink