On Fri, Oct 9, 2015 at 12:32 AM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Jakub,
>
> On Fri, Oct 9, 2015 at 6:14 AM, Jakub Pawlowski <jpawlowski@xxxxxxxxxx> wrote:
>> Hi,
>>
>> Can someone please explain the difference between profiles from
>> 'profiles' directory, and DBus profiles, i.e. 'test/test-profile' and
>> 'test/test-gatt-profile' ? How they're supposed to be used, and how do
>> they map to Bluetooth Profiles ?
>
> There are 2 categories of profiles if one need to categorize them:
>
> - Internal: Those implemented by plugins/driver which are run in the
> context of bluetoothd, this includes profiles under profiles/
> directory. It recommended for profiles that require system
> integration, that access needs to restricted. These sometimes
> implement specific D-Bus interface to interact with the profile.
> - External: Those implemented by D-Bus clients, recommended for
> profiles of general use, currently there are 2 subcategories of it:
> - GATT Profiles: Those registered with GATT Manager, as the name
> imply it should be used for GATT only profiles.
> - Classic Profiles: Those registered with Profile Manager, this is
> for classic only.
>
> Note that the usage model of GATT is a little bit different than it is
> for classic profile since GATT offers attributes it is much easier to
> write external profiles/services than it is with classic where almost
> every profile uses a different protocol.
>
>> Are those from "profiles" directory somehow special, or deprecated?
>> Does DBus profiles also work for LE devices somehow (ones from test
>> directory look like BT Classic ones)
>> profiles from "profile" directory can expose functionality through
>> DBus (like heart rate profile), can same be achieved through DBus
>> services ?
>
> Almost all BLE profiles not implemented using src/shared should be
> considered deprecated, the only exception is HoG but even that will
> need changing, Heart Rate should probably be implemented as an
> external profile.
>
>> I have some issues with devices that expose service with 0xFFFD UUID,
>> that is Universal Second Factor Authenticator Service (U2F). I need to
>> disable auto connect for LE devices that have exclusively three
>> services: Device Info, GAS, and U2F. Shall I use profile, DBus
>> profile, or maybe plugin ? What are plugins for ?
>
> It depends on the usage mode of U2F, I suppose you could use it and
> then once done call Disconnect which would disable auto-connect flag,
> but the connect again you would have to use Connect which essentially
> means it will never auto connect. Regarding Device Info and GAS, those
> should probably not set auto-connect flag, if they do we might need to
> fix them.
Deviceinfo triggers auto connect (that's probably bug):
in deviceinfo.c (all calls are unconditional)
deviceinfo_driver_probe -> deviceinfo_register ->
btd_device_add_attio_callback -> device_set_auto_connect(device,
TRUE);
Shall I add "bool set_auto_connect" param to btd_device_add_attio_callback ?
Other services triggering auto_connect now ("git grep
btd_device_add_attio_callback")
alert, cyclingspeed, deviceinfo, heartrate, input, proximity,
scanparam, thermometer
>
>> When these three services are on device, it's single-purpose
>> authenticator device. It's used to authenticate transactions, and
>> might be used between multiple machines (laptop, workstation, phone),
>> but support one connection at a time. Having linux auto connect to it
>> all the time makes it unable to connect to other nearby devices that
>> might try to authenticate transaction. If other services are exposed,
>> it might be multi-purpose device (i.e. phone that also acts as
>> authenticator) and default auto connect rules shall apply.
>
> By the description it looks like the client will always initiate the
> connection, you only need to connect if you need to authenticate
> something, in that case having auto_connect flag set is probably
> useless and as you said it may interfere with other device that may
> have some authentication pending.
>
>> I've looked through "plugins" directory and seen that there's a
>> disable auto connect field that can be set. Would writing u2f plugin
>> be proper way to solve that?
>
> I guess U2F should be done as external profile, but you probably
> should _not_ use GattManager1.RegisterProfiles because that would set
> auto_connect flag.
>
>
> --
> 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
