Kernel/iwd
3
0
Fork 0
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git synced 2024-11-20 12:39:25 +01:00
Code Releases Activity
f6f5570bc8
iwd/src/ft.h

71 lines
2.2 KiB
C
Raw Normal View History

netdev: Handle the FT Authentication Response message Parse the second message of the FT transition, validate and build the third message, the Reassociation Request.
2017-01-12 09:36:01 +01:00
/*
*
* Wireless daemon for Linux
*
treewide: Move the Intel copyright forward to 2019
2019-10-25 00:43:08 +02:00
* Copyright (C) 2017-2019 Intel Corporation. All rights reserved.
netdev: Handle the FT Authentication Response message Parse the second message of the FT transition, validate and build the third message, the Reassociation Request.
2017-01-12 09:36:01 +01: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
*
*/
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
struct handshake_state;
ft: netdev: move Authenticate IE building into ft.c Since FT already handles processing the FT IE's (and building for associate) it didn't make sense to have all the IE building inside netdev_build_cmd_ft_authenticate. Instead this logic was moved into ft.c, and an iovec is now passed from FT into netdev_ft_tx_authenticate. This leaves the netdev command builder unburdened by the details of FT, as well as prepares for FT-over-DS.
2019-05-09 19:14:12 +02:00
typedef void (*ft_tx_authenticate_func_t)(struct iovec *iov, size_t iov_len,
void *user_data);
ft: netdev: add return value to tx_associate Prior to this, an error sending the FT Reassociation was treated as fatal, which is correct for FT-over-Air but not for FT-over-DS. If the actual l_genl_family_send call fails for FT-over-DS the existing connection can be maintained and there is no need to call netdev_connect_failed. Adding a return to the tx_associate function works for both FT types. In the FT-over-Air case this return will ultimately get sent back up to auth_proto_rx_authenticate in which case will call netdev_connect_failed. For FT-over-DS tx_associate is actually called from the 'start' operation which can fail and still maintain the existing connection.
2021-04-30 19:47:04 +02:00
typedef int (*ft_tx_associate_func_t)(struct iovec *ie_iov, size_t iov_len,
netdev: ft: refactor FT into an auth-proto Since FT operates over Authenticate/Associate, it makes the most sense for it to behave like the other auth-protos. This change moves all the FT specific processing out of netdev and into ft.c. The bulk of the changes were strait copy-pastes from netdev into ft.c with minor API changes (e.g. remove struct netdev). The 'in_ft' boolean unforunately is still required for a few reasons: - netdev_disconnect_event relies on this flag so it can ignore the disconnect which comes in when doing a fast transition. We cannot simply check netdev->ap because this would cause the other auth-protos to not handle a disconnect correctly. - netdev_associate_event needs to correctly setup the eapol_sm when in FT mode by setting require_handshake and use_eapol_start to false. This cannot be handled inside eapol by checking the AKM because an AP may only advertise a FT AKM, and the initial mobility association does require the 4-way handshake.
2019-05-07 20:53:42 +02:00
void *user_data);
netdev: Handle the FT Authentication Response message Parse the second message of the FT transition, validate and build the third message, the Reassociation Request.
2017-01-12 09:36:01 +01:00
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
typedef void (*ft_ds_free_func_t)(void *user_data);
struct ft_ds_info {
uint8_t spa[6];
uint8_t aa[6];
uint8_t snonce[32];
uint8_t mde[3];
uint8_t *fte;
struct ie_ft_info ft_info;
void (*free)(struct ft_ds_info *s);
};
void ft_ds_info_free(struct ft_ds_info *info);
ft: expose ft_build_authenticate_ies The building of the FT IEs for Action/Authenticate frames will need to be shared between ft and netdev once FT-over-DS is refactored. The building was refactored to work off the callers buffer rather than internal stack buffers. An argument 'new_snonce' was included as FT-over-DS will generate a new snonce for the initial action frame, hence the handshakes snonce cannot be used.
2021-04-27 21:49:41 +02:00
bool ft_build_authenticate_ies(struct handshake_state *hs,
const uint8_t *new_snonce, uint8_t *buf,
size_t *len);
ft: break up FT action parsing into two steps This is to prepare for multiple concurrent FT-over-DS action frames. A list will be kept in netdev and for lookup reasons it needs to parse the start of the frame to grab the aa/spa addresses. In this call the IEs are also returned and passed to the new ft_over_ds_parse_action_response. For now the address checks have been moved into netdev, but this will eventually turn into a queue lookup.
2021-05-13 01:01:40 +02:00
int ft_over_ds_parse_action_response(const uint8_t *frame, size_t frame_len,
const uint8_t **spa_out,
const uint8_t **aa_out,
const uint8_t **ies_out,
size_t *ies_len);
bool ft_over_ds_parse_action_ies(struct ft_ds_info *info,
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
struct handshake_state *hs,
ft: break up FT action parsing into two steps This is to prepare for multiple concurrent FT-over-DS action frames. A list will be kept in netdev and for lookup reasons it needs to parse the start of the frame to grab the aa/spa addresses. In this call the IEs are also returned and passed to the new ft_over_ds_parse_action_response. For now the address checks have been moved into netdev, but this will eventually turn into a queue lookup.
2021-05-13 01:01:40 +02:00
const uint8_t *ies,
size_t ies_len);
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
ft: netdev: station: support FT-over-DS FT-over-DS is a way to do a Fast BSS Transition using action frames for the authenticate step. This allows a station to start a fast transition to a target AP while still being connected to the original AP. This, in theory, can result in less carrier downtime. The existing ft_sm_new was removed, and two new constructors were added; one for over-air, and another for over-ds. The internals of ft.c mostly remain the same. A flag to distinguish between air/ds was added along with a new parser to parse the action frames rather than authenticate frames. The IE parsing is identical. Netdev now just initializes the auth-proto differently depending on if its doing over-air or over-ds. A new TX authenticate function was added and used for over-ds. This will send out the IEs from ft.c with an FT Request action frame. The FT Response action frame is then recieved from the AP and fed into the auth-proto state machine. After this point ft-over-ds behaves the same as ft-over-air (associate to the target AP). Some simple code was added in station.c to determine if over-air or over-ds should be used. FT-over-DS can be beneficial in cases where the AP is directing us to roam, or if the RSSI falls below a threshold. It should not be used if we have lost communication to the AP all (beacon lost) as it only works while we can still talk to the original AP.
2019-05-09 20:16:28 +02:00
struct auth_proto *ft_over_air_sm_new(struct handshake_state *hs,
ft_tx_authenticate_func_t tx_auth,
ft_tx_associate_func_t tx_assoc,
void *user_data);
struct auth_proto *ft_over_ds_sm_new(struct handshake_state *hs,
netdev: ft: refactor FT into an auth-proto Since FT operates over Authenticate/Associate, it makes the most sense for it to behave like the other auth-protos. This change moves all the FT specific processing out of netdev and into ft.c. The bulk of the changes were strait copy-pastes from netdev into ft.c with minor API changes (e.g. remove struct netdev). The 'in_ft' boolean unforunately is still required for a few reasons: - netdev_disconnect_event relies on this flag so it can ignore the disconnect which comes in when doing a fast transition. We cannot simply check netdev->ap because this would cause the other auth-protos to not handle a disconnect correctly. - netdev_associate_event needs to correctly setup the eapol_sm when in FT mode by setting require_handshake and use_eapol_start to false. This cannot be handled inside eapol by checking the AKM because an AP may only advertise a FT AKM, and the initial mobility association does require the 4-way handshake.
2019-05-07 20:53:42 +02:00
ft_tx_associate_func_t tx_assoc,
void *user_data);
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
bool ft_over_ds_prepare_handshake(struct ft_ds_info *info,
struct handshake_state *hs);
Copy Permalink