Re: GATT service blacklist

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx>:
> Hi Vincent,
>
> On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <scheib@xxxxxxxxxx> wrote:
>> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz
>> <luiz.dentz@xxxxxxxxx> wrote:
>>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@xxxxxxxxxx> 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
--
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



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux