Re: [PATCH 0/3] Add support for ftm responder configuration

Re: [PATCH 0/3] Add support for ftm responder configuration

[Pradeep Kumar Chitrapu]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Johannes Berg]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Pradeep Kumar Chitrapu]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Johannes Berg]

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

[PATCH 0/3] Add support for ftm responder configuration

[Pradeep Kumar Chitrapu]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Johannes Berg]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[pradeepc]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Johannes Berg]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Pradeep Kumar Chitrapu]

> 
> 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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Johannes Berg]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Pradeep Kumar Chitrapu]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Johannes Berg]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[Kalle Valo]

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.

-- 
Kalle Valo