| Message ID | 20221205144336.35535-1-andrei.otcheretianski@intel.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | wpa_supplicant/hostapd: add an option to only advertise FTM responder | expand |
On Mon, Dec 05, 2022 at 04:43:36PM +0200, Andrei Otcheretianski wrote: > When configuring FTM responder, wpa_supplicant/hostapd configures the > driver to operate as a responder. However, it is possible that it is > only needed to advertise the FTM responder capabilties, but not > configure the driver to operate as a responder (e.g. when a usespace > daemon operates as a responder). Add an option to only advertise the > FTM responder capabilities without configuring the driver. How would a user know when to use the new ftm_responder_capab_only vs. the old ftm_responder_capab configuration parameter? What happens if ftp_responder_capab_only=1 is used and there is no userspace daemon to process the operations? Is this something that could be handled automatically? It would seem to be much more convenient to not add this new configuration parameter at all and instead determine the FTM responder location between the driver and that separate userspace daemon automatically so that it does not matter whether hostapd/wpa_supplicant requests the driver to process the requests.
> On Mon, Dec 05, 2022 at 04:43:36PM +0200, Andrei Otcheretianski wrote: > > When configuring FTM responder, wpa_supplicant/hostapd configures the > > driver to operate as a responder. However, it is possible that it is > > only needed to advertise the FTM responder capabilties, but not > > configure the driver to operate as a responder (e.g. when a usespace > > daemon operates as a responder). Add an option to only advertise the > > FTM responder capabilities without configuring the driver. > > How would a user know when to use the new ftm_responder_capab_only > vs. > the old ftm_responder_capab configuration parameter? What happens if > ftp_responder_capab_only=1 is used and there is no userspace daemon to > process the operations? Is this something that could be handled > automatically? It would seem to be much more convenient to not add this > new configuration parameter at all and instead determine the FTM > responder location between the driver and that separate userspace daemon > automatically so that it does not matter whether hostapd/wpa_supplicant > requests the driver to process the requests. I understand your concern about having multiple similar configurations which may be confusing for the user. Actually, after looking at the code again, it looks that if the driver doesn't publish WPA_DRIVER_FLAGS_FTM_RESPONDER while regular ftm_responder configuration flag is set, hostapd will publish ext. capability bit but will not attempt to configure the responder (without failing). I'm not sure if this is the intended behavior, but if it is, it can be used to achieve what we want. However, for drivers that do support FTM_RESPONDER, there is no way to signal to hostapd that the responder shouldn't be started. Automatically coordinating FTM responder location between the drivers and external daemon sounds quite complicated and will require more kernel API's and driver changes. Andrei > > -- > Jouni Malinen PGP id EFC895FA
diff --git a/hostapd/config_file.c b/hostapd/config_file.c index b5393fd6c7..01454e1c6c 100644 --- a/hostapd/config_file.c +++ b/hostapd/config_file.c @@ -4427,6 +4427,8 @@ static int hostapd_config_fill(struct hostapd_config *conf, conf->stationary_ap = atoi(pos); } else if (os_strcmp(buf, "ftm_responder") == 0) { bss->ftm_responder = atoi(pos); + } else if (os_strcmp(buf, "ftm_responder_capab_only") == 0) { + bss->ftm_responder_capab_only = atoi(pos); } else if (os_strcmp(buf, "ftm_initiator") == 0) { bss->ftm_initiator = atoi(pos); #ifdef CONFIG_FILS diff --git a/src/ap/ap_config.h b/src/ap/ap_config.h index 46b7a47816..456387d9b5 100644 --- a/src/ap/ap_config.h +++ b/src/ap/ap_config.h @@ -731,6 +731,7 @@ struct hostapd_bss_config { #endif /* CONFIG_MBO */ int ftm_responder; + int ftm_responder_capab_only; int ftm_initiator; #ifdef CONFIG_FILS diff --git a/src/ap/ieee802_11_shared.c b/src/ap/ieee802_11_shared.c index a7ab3a2d77..c94f0d942e 100644 --- a/src/ap/ieee802_11_shared.c +++ b/src/ap/ieee802_11_shared.c @@ -404,7 +404,8 @@ static void hostapd_ext_capab_byte(struct hostapd_data *hapd, u8 *pos, int idx, case 7: /* Bits 56-63 */ break; case 8: /* Bits 64-71 */ - if (hapd->conf->ftm_responder) + if (hapd->conf->ftm_responder || + hapd->conf->ftm_responder_capab_only) *pos |= 0x40; /* Bit 70 - FTM responder */ if (hapd->conf->ftm_initiator) *pos |= 0x80; /* Bit 71 - FTM initiator */ diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c index 653f15f54d..6a96550a19 100644 --- a/wpa_supplicant/ap.c +++ b/wpa_supplicant/ap.c @@ -785,6 +785,7 @@ no_wps: } bss->ftm_responder = wpa_s->conf->ftm_responder; + bss->ftm_responder_capab_only = wpa_s->conf->ftm_responder_capab_only; bss->ftm_initiator = wpa_s->conf->ftm_initiator; bss->transition_disable = ssid->transition_disable; diff --git a/wpa_supplicant/config.c b/wpa_supplicant/config.c index a2e21431c2..4b228c1a0d 100644 --- a/wpa_supplicant/config.c +++ b/wpa_supplicant/config.c @@ -5461,6 +5461,7 @@ static const struct global_parse_data global_fields[] = { #endif /* CONFIG_MBO */ { INT(gas_address3), 0 }, { INT_RANGE(ftm_responder, 0, 1), 0 }, + { INT_RANGE(ftm_responder_capab_only, 0, 1), 0 }, { INT_RANGE(ftm_initiator, 0, 1), 0 }, { INT(gas_rand_addr_lifetime), 0 }, { INT_RANGE(gas_rand_mac_addr, 0, 2), 0 }, diff --git a/wpa_supplicant/config.h b/wpa_supplicant/config.h index 87cbb1ea2f..01dfad051c 100644 --- a/wpa_supplicant/config.h +++ b/wpa_supplicant/config.h @@ -1586,17 +1586,29 @@ struct wpa_config { /** * ftm_responder - Publish FTM (fine timing measurement) - * responder functionality + * responder functionality and configure the driver as a FTM responder * * Values: * 0 - do not publish FTM responder functionality (Default) * 1 - publish FTM responder functionality in * bit 70 of Extended Capabilities element + * and configure the driver as a FTM responder * Note, actual FTM responder operation is managed outside * wpa_supplicant. */ int ftm_responder; + /** + * ftm_responder_capab_only - Publish FTM (fine timing measurement) + * responder functionality but don't configure the driver as a responder + * + * Values: + * 0 - do not publish FTM responder functionality (Default) + * 1 - publish FTM responder functionality in + * bit 70 of Extended Capabilities element + */ + int ftm_responder_capab_only; + /** * ftm_initiator - Publish FTM (fine timing measurement) * initiator functionality diff --git a/wpa_supplicant/config_file.c b/wpa_supplicant/config_file.c index 4d50f44a86..af9c391e84 100644 --- a/wpa_supplicant/config_file.c +++ b/wpa_supplicant/config_file.c @@ -1550,6 +1550,9 @@ static void wpa_config_write_global(FILE *f, struct wpa_config *config) if (config->ftm_responder) fprintf(f, "ftm_responder=%d\n", config->ftm_responder); + if (config->ftm_responder_capab_only) + fprintf(f, "ftm_responder_capab_only=%d\n", + config->ftm_responder_capab_only); if (config->ftm_initiator) fprintf(f, "ftm_initiator=%d\n", config->ftm_initiator); diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c index 7849b40296..35be751154 100644 --- a/wpa_supplicant/wpa_supplicant.c +++ b/wpa_supplicant/wpa_supplicant.c @@ -2110,7 +2110,8 @@ static void wpas_ext_capab_byte(struct wpa_supplicant *wpa_s, u8 *pos, int idx) case 7: /* Bits 56-63 */ break; case 8: /* Bits 64-71 */ - if (wpa_s->conf->ftm_responder) + if (wpa_s->conf->ftm_responder || + wpa_s->conf->ftm_responder_capab_only) *pos |= 0x40; /* Bit 70 - FTM responder */ if (wpa_s->conf->ftm_initiator) *pos |= 0x80; /* Bit 71 - FTM initiator */