Kernel
/
iwd
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git
3
0
Fork 0
Code Releases Activity
iwd/src/wiphy.h

127 lines
4.8 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;
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: 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,
};
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: 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,
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
struct scan_bss *bss,
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: add convenience API wiphy_find_by_wdev
2020-07-02 19:35:27 +02:00
#define wiphy_find_by_wdev(w) wiphy_find(w >> 32)
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: add fils_hint to wiphy_can_connect A prior commit refactored the AKM selection in wiphy.c. This ended up breaking FILS tests due to the hard coding of a false fils_hint in wiphy_select_akm. Since our FILS tests only advertise FILS AKMs wiphy_can_connect would return false for these networks. Similar to wiphy_select_akm, add a fils hint parameter to wiphy_can_connect and pass that down directly to wiphy_select_akm.
2021-04-27 20:06:26 +02:00
bool wiphy_can_connect(struct wiphy *wiphy, struct scan_bss *bss,
bool fils_hint);
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: 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: 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
const uint8_t *wiphy_get_supported_rates(struct wiphy *wiphy, unsigned int band,
unsigned int *out_num);
wiphy: Add wiphy_supports_adhoc_rsn
2018-08-07 18:15:23 +02:00
bool wiphy_supports_adhoc_rsn(struct wiphy *wiphy);
wiphy: parse OFFCHANNEL_TX_OK attribute The wiphy can indicate if it supports sending offchannel frames. This allows us to bail out of a Hotspot connection early if this is not supported.
2019-06-14 19:06:35 +02:00
bool wiphy_can_offchannel_tx(struct wiphy *wiphy);
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);
wiphy: Obtain permanent mac address from sysfs
2019-07-01 21:42:12 +02:00
const uint8_t *wiphy_get_permanent_address(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_supports_adhoc_rsn
2018-08-07 18:15:23 +02:00
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]);
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
void wiphy_generate_address_from_ssid(struct wiphy *wiphy, const char *ssid,
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 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: add wiphy_radio_work_is_running This provides a way to know if a work item is actually running vs only been queued and waiting to run.
2021-04-05 23:53:51 +02:00
bool wiphy_radio_work_is_running(struct wiphy *wiphy, uint32_t id);