Hi,
In Web Bluetooth there is a list of blacklisted attributes that may
leak some important information:
https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt
Currently we don't support claiming attribute, which is what in the
end prevent a service to be exposed, so I would like to know the
opinion about having such a feature noting that this may lead to
conflicts such as plugins and application accessing the same
attributes which may or may not interfere.
One of the service that web guys would like to access is GAP service
which is something BlueZ don't actually let them do since there is a
plugin accessing it, and given its name we can probably except changes
on every new Bluetooth release making me wary about exposing its
attributes over D-Bus.
--
Luiz Augusto von Dentz
We now have a new Web Bluetooth sample which shows how to read all GAP
characteristics from a nearby Bluetooth device.
https://plus.google.com/+FrancoisBeaufort/posts/7pLosPyHd41
Hopefully, we'll get BlueZ to work.
On Wed, May 25, 2016 at 2:51 PM, François Beaufort
<[email protected]> wrote:
> For info, the Web Bluetooth team is tracking this issue at
> https://bugs.chromium.org/p/chromium/issues/detail?id=611678
>
> We would really appreciate some consistency between Android, Mac OS
> and Linux platforms to query GAP service characteristics.
>
> Thanks in advance for considering this,
> Francois.
>
> On Fri, May 20, 2016 at 4:36 PM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi,
>>
>> In Web Bluetooth there is a list of blacklisted attributes that may
>> leak some important information:
>>
>> https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt
>>
>> Currently we don't support claiming attribute, which is what in the
>> end prevent a service to be exposed, so I would like to know the
>> opinion about having such a feature noting that this may lead to
>> conflicts such as plugins and application accessing the same
>> attributes which may or may not interfere.
>>
>> One of the service that web guys would like to access is GAP service
>> which is something BlueZ don't actually let them do since there is a
>> plugin accessing it, and given its name we can probably except changes
>> on every new Bluetooth release making me wary about exposing its
>> attributes over D-Bus.
>>
>>
>> --
>> Luiz Augusto von Dentz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
For info, the Web Bluetooth team is tracking this issue at
https://bugs.chromium.org/p/chromium/issues/detail?id=611678
We would really appreciate some consistency between Android, Mac OS
and Linux platforms to query GAP service characteristics.
Thanks in advance for considering this,
Francois.
On Fri, May 20, 2016 at 4:36 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> In Web Bluetooth there is a list of blacklisted attributes that may
> leak some important information:
>
> https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt
>
> Currently we don't support claiming attribute, which is what in the
> end prevent a service to be exposed, so I would like to know the
> opinion about having such a feature noting that this may lead to
> conflicts such as plugins and application accessing the same
> attributes which may or may not interfere.
>
> One of the service that web guys would like to access is GAP service
> which is something BlueZ don't actually let them do since there is a
> plugin accessing it, and given its name we can probably except changes
> on every new Bluetooth release making me wary about exposing its
> attributes over D-Bus.
>
>
> --
> Luiz Augusto von Dentz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Emil,
On Thu, Jan 19, 2017 at 11:11 PM, Emil Lenngren <[email protected]> wrote:
> Hi,
>
> 2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <[email protected]>:
>> Hi Vincent,
>>
>> On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <[email protected]> wrote:
>>> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz
>>> <[email protected]> wrote:
>>>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <[email protected]> wrote:
>>>>> I just ran into this issue again (being blocked from accessing a standard
>>>>> GATT service) when using bluez. I had an application accessing GATT
>>>>> objects, and also the generic_access service. ...
>>>>
>>>> Well the general idea was to block access if there is a plugin already
>>>> handling a certain service. Now you seem to be claiming this shouldn't
>>>> be the case and any service can be accessed simultaneously by a plugin
>>>> running in daemon process and an application, but I don't think this
>>>> is always true and in some cases they may conflict, or just generate
>>>> duplicated traffic.
>>>
>>> Correct. Bluetooth devices are all required to have a generic_access
>>> service, and I believe applications should be able to use the GATT
>>> protocol to interact with that service. I think that the current
>>> approach bluez has taken of trying to abstract this is a mistake.
>>> There doesn't seem to be value added by doing so, but there is harm in
>>> creating additional ways to interact, harming portability and
>>> requiring more attention and custom code by application developers.
>>
>> Well you seem to forget that there are various ways to get the name,
>> not only GATT. In fact the GAP Service over GATT is just the tip of
>> the iceberg, since GAP define the connection procedures which has very
>> little to do with this service, and when it comes to GAP procedures we
>> do need to know the Name of the devices to display to the user and
>> that may come from advertisements, inquiry results or from Read Name
>> command so we can cache the name so we can display it even when not
>> connected. So if you arguing that the stack should not deal with this
>> service I would have to disagree.
>>
>
> In my opinion, it's nice that the system tries to maintain a cache
> using various methods to be able to show the name to the user even
> when the device is disconnected. However that should not imply that it
> shouldn't be possible to read the name characteristic directly from an
> application. There are many reasons why one thinks the name is old and
> needs to be refreshed; for example if you use a smartphone as GATT
> server where you easily can change both GATT server and name, or if
> you do a firmware update and reboot the device the name may change as
> well. If there is no way to force the system to reload the name then
> it should definitely be possible to read it directly. This is how
> Android's implementation works and I guess no one has complained about
> it.
Reading is alright, writing is the one Im more concerned since we
might not be able to detect the change until it gets reconnected. Also
there is no mention on how this affects the name in the advertisement,
if that gets truncated, etc. Flashing a new firmware is actually no
problem, we do read the name every time it gets connected. Im not sure
I follow regarding the GATT server and name, do you want applications
to register a GAP service as a server? How would we handle different
applications trying to register themselves as GAP service since I
don't think we can have multiple instances of that service, if Android
allow to do that its probably not even complaint.
> Also when you want to build a Bluetooth library on top on another
> Bluetooth library it's never fun when each platform has its own
> restrictions that probably was intended to simplify for the users but
> in practice often misses special cases leading to incompatibility
> problems.
Well the same can be said if the Bluetooth stack allow doing things
forbidden by the spec.
>
>>>> Perhaps for GAP service itself it is fine to allow applications to
>>>> access it, the problem is if we allow the application to set the name
>>>> like you want does it notifies that do the daemon as well?
>>>
>>> Yes. The same way multiple applications should be able to receive
>>> notifications for one device.
>>
>> Except that org.bluetooth.characteristic.gap.device_name excludes
>> notification support:
>>
>> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml
>
> I would guess the spec writers didn't really think about what should
> happen when the name gets updated. iOS actually "takes up/waste" one
> round trip in each start of connection to read the name characteristic
> in order to always try to have the latest.
BlueZ does the same and we do emit a signal if we the detect the name
has changed.
--
Luiz Augusto von Dentz
Hi,
2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <[email protected]>:
> Hi Vincent,
>
> On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <[email protected]> wrote:
>> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <[email protected]> wrote:
>>>> I just ran into this issue again (being blocked from accessing a standard
>>>> GATT service) when using bluez. I had an application accessing GATT
>>>> objects, and also the generic_access service. ...
>>>
>>> Well the general idea was to block access if there is a plugin already
>>> handling a certain service. Now you seem to be claiming this shouldn't
>>> be the case and any service can be accessed simultaneously by a plugin
>>> running in daemon process and an application, but I don't think this
>>> is always true and in some cases they may conflict, or just generate
>>> duplicated traffic.
>>
>> Correct. Bluetooth devices are all required to have a generic_access
>> service, and I believe applications should be able to use the GATT
>> protocol to interact with that service. I think that the current
>> approach bluez has taken of trying to abstract this is a mistake.
>> There doesn't seem to be value added by doing so, but there is harm in
>> creating additional ways to interact, harming portability and
>> requiring more attention and custom code by application developers.
>
> Well you seem to forget that there are various ways to get the name,
> not only GATT. In fact the GAP Service over GATT is just the tip of
> the iceberg, since GAP define the connection procedures which has very
> little to do with this service, and when it comes to GAP procedures we
> do need to know the Name of the devices to display to the user and
> that may come from advertisements, inquiry results or from Read Name
> command so we can cache the name so we can display it even when not
> connected. So if you arguing that the stack should not deal with this
> service I would have to disagree.
>
In my opinion, it's nice that the system tries to maintain a cache
using various methods to be able to show the name to the user even
when the device is disconnected. However that should not imply that it
shouldn't be possible to read the name characteristic directly from an
application. There are many reasons why one thinks the name is old and
needs to be refreshed; for example if you use a smartphone as GATT
server where you easily can change both GATT server and name, or if
you do a firmware update and reboot the device the name may change as
well. If there is no way to force the system to reload the name then
it should definitely be possible to read it directly. This is how
Android's implementation works and I guess no one has complained about
it.
Also when you want to build a Bluetooth library on top on another
Bluetooth library it's never fun when each platform has its own
restrictions that probably was intended to simplify for the users but
in practice often misses special cases leading to incompatibility
problems.
>>> Perhaps for GAP service itself it is fine to allow applications to
>>> access it, the problem is if we allow the application to set the name
>>> like you want does it notifies that do the daemon as well?
>>
>> Yes. The same way multiple applications should be able to receive
>> notifications for one device.
>
> Except that org.bluetooth.characteristic.gap.device_name excludes
> notification support:
>
> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml
I would guess the spec writers didn't really think about what should
happen when the name gets updated. iOS actually "takes up/waste" one
round trip in each start of connection to read the name characteristic
in order to always try to have the latest.
Emil
Hi Vincent,
On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <[email protected]> wrote:
> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <[email protected]> wrote:
>>> I just ran into this issue again (being blocked from accessing a standard
>>> GATT service) when using bluez. I had an application accessing GATT
>>> objects, and also the generic_access service. ...
>>
>> Well the general idea was to block access if there is a plugin already
>> handling a certain service. Now you seem to be claiming this shouldn't
>> be the case and any service can be accessed simultaneously by a plugin
>> running in daemon process and an application, but I don't think this
>> is always true and in some cases they may conflict, or just generate
>> duplicated traffic.
>
> Correct. Bluetooth devices are all required to have a generic_access
> service, and I believe applications should be able to use the GATT
> protocol to interact with that service. I think that the current
> approach bluez has taken of trying to abstract this is a mistake.
> There doesn't seem to be value added by doing so, but there is harm in
> creating additional ways to interact, harming portability and
> requiring more attention and custom code by application developers.
Well you seem to forget that there are various ways to get the name,
not only GATT. In fact the GAP Service over GATT is just the tip of
the iceberg, since GAP define the connection procedures which has very
little to do with this service, and when it comes to GAP procedures we
do need to know the Name of the devices to display to the user and
that may come from advertisements, inquiry results or from Read Name
command so we can cache the name so we can display it even when not
connected. So if you arguing that the stack should not deal with this
service I would have to disagree.
>> Perhaps for GAP service itself it is fine to allow applications to
>> access it, the problem is if we allow the application to set the name
>> like you want does it notifies that do the daemon as well?
>
> Yes. The same way multiple applications should be able to receive
> notifications for one device.
Except that org.bluetooth.characteristic.gap.device_name excludes
notification support:
https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml
--
Luiz Augusto von Dentz
On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <[email protected]> wrote:
>> I just ran into this issue again (being blocked from accessing a standard
>> GATT service) when using bluez. I had an application accessing GATT
>> objects, and also the generic_access service. ...
>
> Well the general idea was to block access if there is a plugin already
> handling a certain service. Now you seem to be claiming this shouldn't
> be the case and any service can be accessed simultaneously by a plugin
> running in daemon process and an application, but I don't think this
> is always true and in some cases they may conflict, or just generate
> duplicated traffic.
Correct. Bluetooth devices are all required to have a generic_access
service, and I believe applications should be able to use the GATT
protocol to interact with that service. I think that the current
approach bluez has taken of trying to abstract this is a mistake.
There doesn't seem to be value added by doing so, but there is harm in
creating additional ways to interact, harming portability and
requiring more attention and custom code by application developers.
> Perhaps for GAP service itself it is fine to allow applications to
> access it, the problem is if we allow the application to set the name
> like you want does it notifies that do the daemon as well?
Yes. The same way multiple applications should be able to receive
notifications for one device.
Hi Vincent,
On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <[email protected]> wrote:
> I just ran into this issue again (being blocked from accessing a standard
> GATT service) when using bluez. I had an application accessing GATT
> objects, and also the generic_access service. It's very odd that GATT
> operations to any service would be blocked unless there was a security
> reason to prevent them. Reading and writing the device name should just
> work. It doesn't make sense to write different code with a different API
> when the GATT API is already designed to provide access to this service.
>
> Is there a reason bluez can't allow access?
Well the general idea was to block access if there is a plugin already
handling a certain service. Now you seem to be claiming this shouldn't
be the case and any service can be accessed simultaneously by a plugin
running in daemon process and an application, but I don't think this
is always true and in some cases they may conflict, or just generate
duplicated traffic.
Perhaps for GAP service itself it is fine to allow applications to
access it, the problem is if we allow the application to set the name
like you want does it notifies that do the daemon as well? If it
doesn't then the daemon might only be able to detect the name has
changed once it connect again and attempt to read the name.
I just ran into this issue again (being blocked from accessing a standard
GATT service) when using bluez. I had an application accessing GATT
objects, and also the generic_access service. It's very odd that GATT
operations to any service would be blocked unless there was a security
reason to prevent them. Reading and writing the device name should just
work. It doesn't make sense to write different code with a different API
when the GATT API is already designed to provide access to this service.
Is there a reason bluez can't allow access?
Re: http://marc.info/?l=3Dlinux-bluetooth&m=3D146433282020607
> We now have a new Web Bluetooth sample which shows how to read all GAP
> characteristics from a nearby Bluetooth device.
> https://plus.google.com/+FrancoisBeaufort/posts/7pLosPyHd41
>
> Hopefully, we'll get BlueZ to work.
>
> On Wed, May 25, 2016 at 2:51 PM, Fran=C3=A7ois Beaufort
> <[email protected]> wrote:
>> For info, the Web Bluetooth team is tracking this issue at
>> https://bugs.chromium.org/p/chromium/issues/detail?id=3D611678
>>
>> We would really appreciate some consistency between Android, Mac OS
>> and Linux platforms to query GAP service characteristics.
>>
>> Thanks in advance for considering this,
>> Francois.
>>
>> On Fri, May 20, 2016 at 4:36 PM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi,
>>>
>>> In Web Bluetooth there is a list of blacklisted attributes that may
>>> leak some important information:
>>>
>>>
https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt
>>>
>>> Currently we don't support claiming attribute, which is what in the
>>> end prevent a service to be exposed, so I would like to know the
>>> opinion about having such a feature noting that this may lead to
>>> conflicts such as plugins and application accessing the same
>>> attributes which may or may not interfere.
>>>
>>> One of the service that web guys would like to access is GAP service
[Sending again in plain text mode]
I don't think it makes sense to block this functionality. This will
only cause developers to introduce non-standard characteristics to
achieve what they want. For example Playbulb already does this:
Characteristic with UUID 0xffff[1] can be used to change the device's
name. I can imagine the number of peripherals that do this will only
grow as this is clearly a desired feature.
[1] https://github.com/Phhere/Playbulb/blob/master/protocols/characteristics.md
On Mon, Jan 23, 2017 at 8:41 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Emil,
>
> On Thu, Jan 19, 2017 at 11:11 PM, Emil Lenngren <[email protected]> wrote:
>> Hi,
>>
>> 2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <[email protected]>:
>>> Hi Vincent,
>>>
>>> On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <[email protected]> wrote:
>>>> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz
>>>> <[email protected]> wrote:
>>>>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <[email protected]> wrote:
>>>>>> I just ran into this issue again (being blocked from accessing a standard
>>>>>> GATT service) when using bluez. I had an application accessing GATT
>>>>>> objects, and also the generic_access service. ...
>>>>>
>>>>> Well the general idea was to block access if there is a plugin already
>>>>> handling a certain service. Now you seem to be claiming this shouldn't
>>>>> be the case and any service can be accessed simultaneously by a plugin
>>>>> running in daemon process and an application, but I don't think this
>>>>> is always true and in some cases they may conflict, or just generate
>>>>> duplicated traffic.
>>>>
>>>> Correct. Bluetooth devices are all required to have a generic_access
>>>> service, and I believe applications should be able to use the GATT
>>>> protocol to interact with that service. I think that the current
>>>> approach bluez has taken of trying to abstract this is a mistake.
>>>> There doesn't seem to be value added by doing so, but there is harm in
>>>> creating additional ways to interact, harming portability and
>>>> requiring more attention and custom code by application developers.
>>>
>>> Well you seem to forget that there are various ways to get the name,
>>> not only GATT. In fact the GAP Service over GATT is just the tip of
>>> the iceberg, since GAP define the connection procedures which has very
>>> little to do with this service, and when it comes to GAP procedures we
>>> do need to know the Name of the devices to display to the user and
>>> that may come from advertisements, inquiry results or from Read Name
>>> command so we can cache the name so we can display it even when not
>>> connected. So if you arguing that the stack should not deal with this
>>> service I would have to disagree.
>>>
>>
>> In my opinion, it's nice that the system tries to maintain a cache
>> using various methods to be able to show the name to the user even
>> when the device is disconnected. However that should not imply that it
>> shouldn't be possible to read the name characteristic directly from an
>> application. There are many reasons why one thinks the name is old and
>> needs to be refreshed; for example if you use a smartphone as GATT
>> server where you easily can change both GATT server and name, or if
>> you do a firmware update and reboot the device the name may change as
>> well. If there is no way to force the system to reload the name then
>> it should definitely be possible to read it directly. This is how
>> Android's implementation works and I guess no one has complained about
>> it.
>
> Reading is alright, writing is the one Im more concerned since we
> might not be able to detect the change until it gets reconnected. Also
> there is no mention on how this affects the name in the advertisement,
> if that gets truncated, etc. Flashing a new firmware is actually no
> problem, we do read the name every time it gets connected. Im not sure
> I follow regarding the GATT server and name, do you want applications
> to register a GAP service as a server? How would we handle different
> applications trying to register themselves as GAP service since I
> don't think we can have multiple instances of that service, if Android
> allow to do that its probably not even complaint.
>
>> Also when you want to build a Bluetooth library on top on another
>> Bluetooth library it's never fun when each platform has its own
>> restrictions that probably was intended to simplify for the users but
>> in practice often misses special cases leading to incompatibility
>> problems.
>
> Well the same can be said if the Bluetooth stack allow doing things
> forbidden by the spec.
>
>>
>>>>> Perhaps for GAP service itself it is fine to allow applications to
>>>>> access it, the problem is if we allow the application to set the name
>>>>> like you want does it notifies that do the daemon as well?
>>>>
>>>> Yes. The same way multiple applications should be able to receive
>>>> notifications for one device.
>>>
>>> Except that org.bluetooth.characteristic.gap.device_name excludes
>>> notification support:
>>>
>>> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml
>>
>> I would guess the spec writers didn't really think about what should
>> happen when the name gets updated. iOS actually "takes up/waste" one
>> round trip in each start of connection to read the name characteristic
>> in order to always try to have the latest.
>
> BlueZ does the same and we do emit a signal if we the detect the name
> has changed.
>
> --
> Luiz Augusto von Dentz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html