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
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
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
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
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
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
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:
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
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
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
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
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
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
13 matches
Mail list logo
