Hi Marcel,
On Tue, May 8, 2018 at 10:53 AM Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Luiz,
> > This adds Flags which the application can use in case it want to set
> > it own flags.
> >
> > Note: This would allow for example an application to advertise as
> > discoverable even if the adapter is not discoverable which may be
> > required by dual-mode as it may not require BR/EDR to be discoverable.
> > ---
> > doc/advertising-api.txt | 15 +++++++++++++++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/doc/advertising-api.txt b/doc/advertising-api.txt
> > index eef98ad91..4e015f282 100644
> > --- a/doc/advertising-api.txt
> > +++ b/doc/advertising-api.txt
> > @@ -78,6 +78,21 @@ Properties string Type
> > <Transport Discovery> <Organization
Flags...>
> > 0x26 0x01
0x01...
> >
> > + array{byte} Flags [Experimental]
> > +
> > + Advertising Flags to include. When present this
will
> > + override existing flags such as Discoverable.
> > +
> > + Note: This property shall not be set when Type is
set
> > + to broadcast.
> > +
> > + Possible value:
> > + bit 0 - LE Limited Discoverable Mode
> > + bit 1 - LE General Discoverable Mode
> > + bit 2 - BR/EDR Not Supported
> > + bit 3 - Simultaneous LE and BR/EDR
(Controller)
> > + bit 4 - Simultaneous LE and BR/EDR (Host)
> > +
> I think this is the wrong approach. Exposing this low-level part is just
giving an API to circumvent and violate the Bluetooth spec. You are
inviting apps to create bad advertising data. So NAK.
Then we should find some alternative, perhaps only allow certain flags to
be set this way or change the property to just Discoverable.
> Regards
> Marcel
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
