Hi,
Does Bluez provide a way to detect the compatibility of a Bluetooth
adapter with Bluetooth 4.0/Low Energy?
I have written some command-line tools to interact with BLE devices
and have received a couple of bug reports from users who don't realize
that they don't have Bluetooth 4.0 adapters.
It appears that connect() with a BLE destination address results in
errno=EBADRQC. Is this errno value a reliable way to detect an
incompatible adapter? Is it possible to query the hci device to detect
compatibility without trying and failing?
struct sockaddr_l2 srcaddr, dstaddr;
memset(&dstaddr, 0, sizeof(dstaddr));
dstaddr.l2_family = AF_BLUETOOTH;
dstaddr.l2_cid = htobs(4); // ATT_CID
dstaddr.l2_bdaddr_type = BDADDR_LE_RANDOM;
...
connect(sock, (struct sockaddr *) &dstaddr, sizeof(dstaddr))
Thanks,
Dan
On Mon, Aug 24, 2015 at 11:09 AM, Marcel Holtmann <[email protected]> wrote:
>>>> Does Bluez provide a way to detect the compatibility of a Bluetooth
>>>> adapter with Bluetooth 4.0/Low Energy?
>>>
>>> That would be the mgmt settings bit number 9 (see doc/mgmt-api.txt).
>>> bluetoothd keeps track of this (and enables it automatically if
>>> available) and you should also be able to see it e.g. with "btmgmt
>>> info". The mgmt interface tells you both whether it's supported as well
>>> as whether it's enabled.
>>>
>>
>> Thank you!
>>
>> In the meantime, I found another way to do it, using
>> hci_read_local_features() and checking for the appropriate bit from
>> lmp_features_map, specifically features[4]&0x40.
>>
>> Is there any reason I should prefer one approach over the other?
>
> raw HCI access is a bad idea. Do not do that. The btmgmt info command is what gives you most information.
>
> Index list with 1 item
> hci0: Primary controller
> addr 98:58:8A:xx:xx:xx version 6 manufacturer 15 class 0x000000
> supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy configuration static-addr
> current settings: powered bondable ssp br/edr le secure-conn
> name BlueZ
> short name
> hci0: Configuration options
> supported options: public-address
> missing options:
>
> It will easily tell you if LE is supported and also if it has been enabled.
Actually, I already need raw HCI access because the devices I am
communicating with request a LE connection interval that is
unnecessarily long, and there doesn't seem to be another way to
override this (http://thread.gmane.org/gmane.linux.bluez.kernel/63778/focus=63819).
> The raw features are exposed via /sys/kernel/debug/bluetooth/hci0/features file. However that is not a stable API. That is for manual debugging.
Got it. I'll use the mgmt_* calls for feature detection if they're more stable.
Thanks,
Dan
Hi Daniel,
>>> Does Bluez provide a way to detect the compatibility of a Bluetooth
>>> adapter with Bluetooth 4.0/Low Energy?
>>
>> That would be the mgmt settings bit number 9 (see doc/mgmt-api.txt).
>> bluetoothd keeps track of this (and enables it automatically if
>> available) and you should also be able to see it e.g. with "btmgmt
>> info". The mgmt interface tells you both whether it's supported as well
>> as whether it's enabled.
>>
>
> Thank you!
>
> In the meantime, I found another way to do it, using
> hci_read_local_features() and checking for the appropriate bit from
> lmp_features_map, specifically features[4]&0x40.
>
> Is there any reason I should prefer one approach over the other?
raw HCI access is a bad idea. Do not do that. The btmgmt info command is what gives you most information.
Index list with 1 item
hci0: Primary controller
addr 98:58:8A:xx:xx:xx version 6 manufacturer 15 class 0x000000
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy configuration static-addr
current settings: powered bondable ssp br/edr le secure-conn
name BlueZ
short name
hci0: Configuration options
supported options: public-address
missing options:
It will easily tell you if LE is supported and also if it has been enabled.
The raw features are exposed via /sys/kernel/debug/bluetooth/hci0/features file. However that is not a stable API. That is for manual debugging.
Regards
Marcel
On Mon, Aug 24, 2015 at 1:30 AM, Johan Hedberg <[email protected]> wrote:
> On Sat, Aug 22, 2015, Daniel Lenski wrote:
>> Does Bluez provide a way to detect the compatibility of a Bluetooth
>> adapter with Bluetooth 4.0/Low Energy?
>
> That would be the mgmt settings bit number 9 (see doc/mgmt-api.txt).
> bluetoothd keeps track of this (and enables it automatically if
> available) and you should also be able to see it e.g. with "btmgmt
> info". The mgmt interface tells you both whether it's supported as well
> as whether it's enabled.
>
Thank you!
In the meantime, I found another way to do it, using
hci_read_local_features() and checking for the appropriate bit from
lmp_features_map, specifically features[4]&0x40.
Is there any reason I should prefer one approach over the other?
Dan
Hi Daniel,
On Sat, Aug 22, 2015, Daniel Lenski wrote:
> Does Bluez provide a way to detect the compatibility of a Bluetooth
> adapter with Bluetooth 4.0/Low Energy?
That would be the mgmt settings bit number 9 (see doc/mgmt-api.txt).
bluetoothd keeps track of this (and enables it automatically if
available) and you should also be able to see it e.g. with "btmgmt
info". The mgmt interface tells you both whether it's supported as well
as whether it's enabled.
Johan