Re: [PATCH 0/3] Add support for ftm responder configuration
On Wed, 2018-08-22 at 11:22 -0700, Pradeep Kumar Chitrapu wrote: > > Should we just ignore that? Or perhaps add a separate capability for > > it? > > Yes, even we behave the same. In that case, we can go ahead now with the > capability to only enable FTM responder. If the driver wants to support > disabling option in future, at which point, the new capability can be > added. True. > However, changes to nl80211_set_beacon to support enabling FTM responder > may still be needed along with start_ap, assuming that ap start will be > issued by different android api than enableResponder api. Yes, I guess that's still needed to be able to support the Android API, which seems useful. johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
On 2018-08-22 00:27, Johannes Berg wrote: On Tue, 2018-08-21 at 15:08 -0700, Pradeep Kumar Chitrapu wrote: > Right. However, I guess we could allow updating/changing this setting > on > the fly through () 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". Agree. ( ftm_responder param will have to be added in cfg80211_beacon_data instead of cfg80211_ap_settings) Right. I'm not even sure that all devices can disable it though, so we may be in a bind here? I think ours (Intel) can't, for example, disable FTM responder without disabling the AP (at least momentarily)... Should we just ignore that? Or perhaps add a separate capability for it? Yes, even we behave the same. In that case, we can go ahead now with the capability to only enable FTM responder. If the driver wants to support disabling option in future, at which point, the new capability can be added. However, changes to nl80211_set_beacon to support enabling FTM responder may still be needed along with start_ap, assuming that ap start will be issued by different android api than enableResponder api. Please let me know your suggestion. Maybe there's even hardware that cannot change the elements (LCI/Civic location) on the fly? johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
On Tue, 2018-08-21 at 15:08 -0700, Pradeep Kumar Chitrapu wrote: > > 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". > > Agree. ( ftm_responder param will have to be added in > cfg80211_beacon_data > instead of cfg80211_ap_settings) Right. I'm not even sure that all devices can disable it though, so we may be in a bind here? I think ours (Intel) can't, for example, disable FTM responder without disabling the AP (at least momentarily)... Should we just ignore that? Or perhaps add a separate capability for it? Maybe there's even hardware that cannot change the elements (LCI/Civic location) on the fly? johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
On 2018-08-21 12:24, Johannes Berg wrote: 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". Agree. ( ftm_responder param will have to be added in cfg80211_beacon_data instead of cfg80211_ap_settings) 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". OK. johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
prade...@codeaurora.org writes: > Thanks for the review.. Could you please fix your From field to include your full name: From: prade...@codeaurora.org It should look like this: From: Kalle Valo This makes it a lot easier to follow threads. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
On Wed, 2018-08-15 at 18:50 -0700, prade...@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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/3] Add support for ftm responder configuration
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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH 0/3] Add support for ftm responder configuration
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(+) -- 1.9.1 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
