| Message ID | 1534293018-4930-1-git-send-email-pradeepc@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for ftm responder configuration | expand |
On Tue, 2018-08-14 at 17:30 -0700, Pradeep Kumar Chitrapu wrote: > Currently ftm_responder parameter in hostapd.conf is only used for fine > timing measurement (FTM) capability advertisement and actual control of > the functionality is with low-level device/driver. This leads to confusion > to the user when the capability advertisement is different from actual FTM > responder functionality. > > For example, FTM responder capability advertisement is set to 'disabled', > which would imply that AP must not respond to FTM requests, but user sees > AP still responding to FTM requests, as the functionality is enabled in > the driver. All you describe above is really a driver bug - it shouldn't have enabled it to start with? > The patch set allows userspace to configure FTM responder functionality > with the addition of new Netlink attribute NL80211_ATTR_FTM_RESPONDER > and also adds extended feature flag for the drivers to advertise the > support. Sending '0' to disable FTM responder would imply AP does not > respond to FTM requests and sending '1' to enable FTM responder would > imply that AP responds to all FTM requests. This makes sense anyway. Funny you should post this within hours of me doing the same, basically. I have no objection to your approach, though I guess it'd be nice if you could take a look at the statistics I have exposed and see if those makes sense or if additional ones are desirable for you, and then we can combine the work that way, i.e. have your configuration and our stats? johannes
On 2018-08-15 02:04, Johannes Berg wrote: > On Tue, 2018-08-14 at 17:30 -0700, Pradeep Kumar Chitrapu wrote: >> Currently ftm_responder parameter in hostapd.conf is only used for >> fine >> timing measurement (FTM) capability advertisement and actual control >> of >> the functionality is with low-level device/driver. This leads to >> confusion >> to the user when the capability advertisement is different from actual >> FTM >> responder functionality. >> >> For example, FTM responder capability advertisement is set to >> 'disabled', >> which would imply that AP must not respond to FTM requests, but user >> sees >> AP still responding to FTM requests, as the functionality is enabled >> in >> the driver. > Hi Johannes, Thanks for the review.. > All you describe above is really a driver bug - it shouldn't have > enabled it to start with? Sure.. But isn't it justifiable for drivers/firmware choosing to enable ftm responder by default when there is no way for userspace to specify this parameter? > >> The patch set allows userspace to configure FTM responder >> functionality >> with the addition of new Netlink attribute NL80211_ATTR_FTM_RESPONDER >> and also adds extended feature flag for the drivers to advertise the >> support. Sending '0' to disable FTM responder would imply AP does not >> respond to FTM requests and sending '1' to enable FTM responder would >> imply that AP responds to all FTM requests. > > This makes sense anyway. Funny you should post this within hours of me > doing the same, basically. Sorry, I missed your patches before posting mine :) > > I have no objection to your approach, though I guess it'd be nice if > you > could take a look at the statistics I have exposed and see if those > makes sense or if additional ones are desirable for you, and then we > can > combine the work that way, i.e. have your configuration and our stats? I looked at the patch you posted and this makes sense. I will try to align ath10k driver changes with your approach. Thanks Pradeep > > johannes
On Wed, 2018-08-15 at 18:50 -0700, pradeepc@codeaurora.org wrote: > > All you describe above is really a driver bug - it shouldn't have > > enabled it to start with? > > Sure.. But isn't it justifiable for drivers/firmware choosing to enable > ftm responder by default when there is no way for userspace to specify > this parameter? No? FTM needs higher-level configuration/advertisement, so how could the driver/firmware enable it when it's not supposed to be? I really do think this is a driver bug. Nothing stopped you from submitting these patches months/years ago when the capability was first added to the firmware, after all. > > This makes sense anyway. Funny you should post this within hours of me > > doing the same, basically. > > Sorry, I missed your patches before posting mine :) No worries. > > > > I have no objection to your approach, though I guess it'd be nice if > > you > > could take a look at the statistics I have exposed and see if those > > makes sense or if additional ones are desirable for you, and then we > > can combine the work that way, i.e. have your configuration and our stats? > > I looked at the patch you posted and this makes sense. I will try to > align ath10k driver changes with your approach. I tend to actually like your patch better for configuration - no new command, though it is, I think, lacking configuration of the necessary elements (where do you take the LCI/Civic location from?). johannes
pradeepc@codeaurora.org writes: > Thanks for the review.. Could you please fix your From field to include your full name: From: pradeepc@codeaurora.org It should look like this: From: Kalle Valo <kvalo@codeaurora.org> This makes it a lot easier to follow threads.
> > No worries. > >> > >> > I have no objection to your approach, though I guess it'd be nice if >> > you >> > could take a look at the statistics I have exposed and see if those >> > makes sense or if additional ones are desirable for you, and then we >> > can combine the work that way, i.e. have your configuration and our stats? >> >> I looked at the patch you posted and this makes sense. I will try to >> align ath10k driver changes with your approach. > > I tend to actually like your patch better for configuration - no new > command, though it is, I think, lacking configuration of the necessary > elements (where do you take the LCI/Civic location from?). > > johannes Hi Johannes, I will change the attribute to FLAG type, also add support for LCI/CIVIC params and repost the patch. Thanks Pradeep
On Sat, 2018-08-18 at 00:50 -0700, Pradeep Kumar Chitrapu wrote: > > > I will change the attribute to FLAG type, also add support for LCI/CIVIC > params and repost the patch. Looking at Android (for unrelated reasons), I see that they have a separate "enable FTM responder" command: https://android.googlesource.com/platform/hardware/interfaces/+/master/wifi/1.0/IWifiRttController.hal#158 Is that something you've seen/worked with? If so, how does it match your current approach where FTM responder has to be enabled from the start? Or perhaps this API is independent of AP and starts its own AP? But it doesn't have any setup for the SSID etc., only the channel, so not clear how that'd work? johannes
On 2018-08-20 02:33, Johannes Berg wrote: > On Sat, 2018-08-18 at 00:50 -0700, Pradeep Kumar Chitrapu wrote: >> > >> I will change the attribute to FLAG type, also add support for >> LCI/CIVIC >> params and repost the patch. > > Looking at Android (for unrelated reasons), I see that they have a > separate "enable FTM responder" command: > > https://android.googlesource.com/platform/hardware/interfaces/+/master/wifi/1.0/IWifiRttController.hal#158 > > Is that something you've seen/worked with? If so, how does it match > your > current approach where FTM responder has to be enabled from the start? > > Or perhaps this API is independent of AP and starts its own AP? But it > doesn't have any setup for the SSID etc., only the channel, so not > clear > how that'd work? > > johannes I wasn't aware of this android api. However, looking at the api, the assumption is that bss is started by a different api and the 'enableResponder' api is used for enabling rtt for a given duration. The reason we have added enabling ftm responder through start ap is that this can reflect beacon IE change in the configuration in the same place. In case of the separate command, enabling responder will not update the beacon, however, the application must issue the new command, whenever its updating beacon template. Please let me know your thoughts/suggestions. Pradeep
On Tue, 2018-08-21 at 11:32 -0700, Pradeep Kumar Chitrapu wrote: > > I wasn't aware of this android api. OK. > However, looking at the api, the > assumption is that bss is started by a different > api and the 'enableResponder' api is used for enabling rtt for a given > duration. It looks like. Note that there's also *disable*, which we hadn't even implemented before. > The reason we have added enabling ftm responder through start ap is that > this can reflect beacon IE change in the > configuration in the same place. Which makes sense, yeah. > In case of the separate command, > enabling responder will not update the beacon, > however, the application must issue the new command, whenever its > updating beacon template. Right. However, I guess we could allow updating/changing this setting on the fly through nl80211_set_beacon() which already allows changing other non-beacon parameters (like the probe or assoc response templates), and then we can use your approach. Basically changing "SET_BEACON" to be a bit like "CHANGE_AP". In that case we definitely would need the attribute to be 0/1 as you had it so that it not present can be used to indicate "no change". johannes
Currently ftm_responder parameter in hostapd.conf is only used for fine timing measurement (FTM) capability advertisement and actual control of the functionality is with low-level device/driver. This leads to confusion to the user when the capability advertisement is different from actual FTM responder functionality. For example, FTM responder capability advertisement is set to 'enabled', but the functionality is disabled or not supported by the driver. The patch set allows userspace to enable FTM responder functionality with the addition of new Netlink flag attribute NL80211_ATTR_FTM_RESPONDER with configurable lci/civic ocation parameters. Also extended feature flag is added for the drivers to advertise the support. Setting the flag to enable FTM responder would imply that AP responds to all FTM requests. Default is considered to be disabled. Johannes Berg, Pradeep Kumar Chitrapu (1): cfg80211: support FTM responder configuration/statistics David Spinadel, Johannes Berg, Pradeep Kumar Chitrapu (1): mac80211: support FTM responder configuration/statistics Pradeep Kumar Chitrapu (1): ath10k: Add support to configure ftm responder role drivers/net/wireless/ath/ath10k/core.h | 1 + drivers/net/wireless/ath/ath10k/mac.c | 29 +++++++++ drivers/net/wireless/ath/ath10k/wmi.c | 4 ++ drivers/net/wireless/ath/ath10k/wmi.h | 10 +++ include/net/cfg80211.h | 66 +++++++++++++++++++ include/net/mac80211.h | 12 ++++ include/uapi/linux/nl80211.h | 71 ++++++++++++++++++++ net/mac80211/cfg.c | 74 +++++++++++++++++++++ net/mac80211/driver-ops.h | 16 +++++ net/mac80211/trace.h | 23 +++++++ net/mac80211/util.c | 3 + net/wireless/nl80211.c | 115 +++++++++++++++++++++++++++++++-- net/wireless/rdev-ops.h | 15 +++++ net/wireless/trace.h | 44 +++++++++++++ 14 files changed, 478 insertions(+), 5 deletions(-)
Currently ftm_responder parameter in hostapd.conf is only used for fine timing measurement (FTM) capability advertisement and actual control of the functionality is with low-level device/driver. This leads to confusion to the user when the capability advertisement is different from actual FTM responder functionality. For example, FTM responder capability advertisement is set to 'disabled', which would imply that AP must not respond to FTM requests, but user sees AP still responding to FTM requests, as the functionality is enabled in the driver. The patch set allows userspace to configure FTM responder functionality with the addition of new Netlink attribute NL80211_ATTR_FTM_RESPONDER and also adds extended feature flag for the drivers to advertise the support. Sending '0' to disable FTM responder would imply AP does not respond to FTM requests and sending '1' to enable FTM responder would imply that AP responds to all FTM requests. Pradeep Kumar Chitrapu (3): nl80211: add support to configure FTM responder functionality mac80211: Add support to notify ftm responder configuration to the driver ath10k: Add support to configure ftm responder role drivers/net/wireless/ath/ath10k/core.h | 1 + drivers/net/wireless/ath/ath10k/mac.c | 29 +++++++++++++++++++++++++++++ drivers/net/wireless/ath/ath10k/wmi.c | 4 ++++ drivers/net/wireless/ath/ath10k/wmi.h | 10 ++++++++++ include/net/cfg80211.h | 2 ++ include/net/mac80211.h | 4 ++++ include/uapi/linux/nl80211.h | 20 ++++++++++++++++++++ net/mac80211/cfg.c | 4 ++++ net/mac80211/util.c | 3 +++ net/wireless/nl80211.c | 19 +++++++++++++++++++ 10 files changed, 96 insertions(+)