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

From: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 0/3] Add support for ftm responder configuration
Date: Tue, 21 Aug 2018 11:32:42 -0700	[thread overview]
Message-ID: <dbd347a3434c05f48931559818dac8a1@codeaurora.org> (raw)
In-Reply-To: <1534757602.6287.4.camel@sipsolutions.net>

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