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. > 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
