[0/3] Add support for ftm responder configuration
mbox series

Message ID 1534293018-4930-1-git-send-email-pradeepc@codeaurora.org
Headers show
Series
  • Add support for ftm responder configuration
Related show

Message

Pradeep Kumar Chitrapu Aug. 15, 2018, 12:30 a.m. UTC
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(+)

Comments

Johannes Berg Aug. 15, 2018, 9:04 a.m. UTC | #1
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
Pradeep Kumar Chitrapu Aug. 16, 2018, 1:50 a.m. UTC | #2
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
Johannes Berg Aug. 16, 2018, 8:12 a.m. UTC | #3
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
Kalle Valo Aug. 16, 2018, 9:21 a.m. UTC | #4
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.
Pradeep Kumar Chitrapu Aug. 18, 2018, 7:50 a.m. UTC | #5
> 
> 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
Johannes Berg Aug. 20, 2018, 9:33 a.m. UTC | #6
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
Pradeep Kumar Chitrapu Aug. 21, 2018, 6:32 p.m. UTC | #7
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
Johannes Berg Aug. 21, 2018, 7:24 p.m. UTC | #8
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
Pradeep Kumar Chitrapu Aug. 31, 2018, 1:10 a.m. UTC | #9
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(-)