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