I'm having a problem using BLE through dbus where the GATT services
don't appear after a BLE device has been found during a scan. What is
available through dbus is a Device1 node with the correct address and a
Name property of the name which was sent in the advertising beacons -
however that's the only node available in the tree.
When running with the same BLE dongle (ID 0a5c:21e8 Broadcom Corp.
BCM20702A0 Bluetooth 4.0) and same BLE remote device (TI SensorTag 2
CC2650STK) on a different computer I can see all the GATT
characteristics in the dbus tree without any problems.
The computer with the problem is running on kernel 4.2.0 with bluez
5.34. gatttool works without a problem.
Where should I start looking to find out why this is happening? I am a
developer; if someone could point me in the direction to begin looking
I'll do some investigation.
Regards
Steven Davies
Hi Luiz,
>>>>>> I'm having a problem using BLE through dbus where the GATT services
>>>>>> don't appear after a BLE device has been found during a scan. What is
>>>>>> available through dbus is a Device1 node with the correct address and a
>>>>>> Name property of the name which was sent in the advertising beacons -
>>>>>> however that's the only node available in the tree.
>>>>> Are you running bluetoothd with the experimental (-E) flag?
>>>> Yes:
>>>> ~$ ps aux | grep bluetooth
>>>> root 8277 0.0 0.1 4320 2628 ? Ss Sep21 0:00
>>>> /usr/libexec/bluetooth/bluetoothd -E
>>> First and most important gatttool shall not be used along with
>>> bluetoothd, it is a stand alone tool for testing. That being said you
>>> need to connect in order to discover the attribute the remote device
>>> has, without that we only know about the UUIDs advertised nothing
>>> else.
>> Yes - I was using gatttool to prove I could still connect without going
>> through bluetoothd. Should I expect the GATT UUIDs, services and so on
>> to be available through dbus once I've called Connect on the device?
>
> If you connect using gatttool it will prevent bluetoothd to discover
> the attributes.
>
>> What I was seeing yesterday was that after calling Connect the nodes in
>> dbus don't change so I still can't see the GATT bits. Is there a code
>> path I could look through to see why this is?
>
> Start bluetoothd with -d option for printing the debugs, then start
> btmon and finally use bluetoothctl to connect, if all goes fine
> bluetoothctl will print the attributes found.
I did this and it showed where I was going wrong: upon first discovery
and connection, it takes approximately 15 seconds for the devices to
register all their GATT services. I simply wasn't waiting long enough
for all the dbus nodes to be populated.
However I do have another issue and I'll post again if I can't figure it
out. Thanks for the help!
Regards
Steven Davies
Hi Steven,
On Tue, Sep 22, 2015 at 4:44 PM, Steven Davies
<[email protected]> wrote:
>>>>> I'm having a problem using BLE through dbus where the GATT services
>>>>> don't appear after a BLE device has been found during a scan. What is
>>>>> available through dbus is a Device1 node with the correct address and a
>>>>> Name property of the name which was sent in the advertising beacons -
>>>>> however that's the only node available in the tree.
>>>> Are you running bluetoothd with the experimental (-E) flag?
>>> Yes:
>>> ~$ ps aux | grep bluetooth
>>> root 8277 0.0 0.1 4320 2628 ? Ss Sep21 0:00
>>> /usr/libexec/bluetooth/bluetoothd -E
>> First and most important gatttool shall not be used along with
>> bluetoothd, it is a stand alone tool for testing. That being said you
>> need to connect in order to discover the attribute the remote device
>> has, without that we only know about the UUIDs advertised nothing
>> else.
> Yes - I was using gatttool to prove I could still connect without going
> through bluetoothd. Should I expect the GATT UUIDs, services and so on
> to be available through dbus once I've called Connect on the device?
If you connect using gatttool it will prevent bluetoothd to discover
the attributes.
> What I was seeing yesterday was that after calling Connect the nodes in
> dbus don't change so I still can't see the GATT bits. Is there a code
> path I could look through to see why this is?
Start bluetoothd with -d option for printing the debugs, then start
btmon and finally use bluetoothctl to connect, if all goes fine
bluetoothctl will print the attributes found.
> Thanks
> Steven Davies
> --
> 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
--
Luiz Augusto von Dentz
>>>> I'm having a problem using BLE through dbus where the GATT services
>>>> don't appear after a BLE device has been found during a scan. What is
>>>> available through dbus is a Device1 node with the correct address and a
>>>> Name property of the name which was sent in the advertising beacons -
>>>> however that's the only node available in the tree.
>>> Are you running bluetoothd with the experimental (-E) flag?
>> Yes:
>> ~$ ps aux | grep bluetooth
>> root 8277 0.0 0.1 4320 2628 ? Ss Sep21 0:00
>> /usr/libexec/bluetooth/bluetoothd -E
> First and most important gatttool shall not be used along with
> bluetoothd, it is a stand alone tool for testing. That being said you
> need to connect in order to discover the attribute the remote device
> has, without that we only know about the UUIDs advertised nothing
> else.
Yes - I was using gatttool to prove I could still connect without going
through bluetoothd. Should I expect the GATT UUIDs, services and so on
to be available through dbus once I've called Connect on the device?
What I was seeing yesterday was that after calling Connect the nodes in
dbus don't change so I still can't see the GATT bits. Is there a code
path I could look through to see why this is?
Thanks
Steven Davies
Hi Steven,
On Tue, Sep 22, 2015 at 10:53 AM, Steven Davies
<[email protected]> wrote:
>
>>> I'm having a problem using BLE through dbus where the GATT services
>>> don't appear after a BLE device has been found during a scan. What is
>>> available through dbus is a Device1 node with the correct address and a
>>> Name property of the name which was sent in the advertising beacons -
>>> however that's the only node available in the tree.
>> Are you running bluetoothd with the experimental (-E) flag?
> Yes:
> ~$ ps aux | grep bluetooth
> root 8277 0.0 0.1 4320 2628 ? Ss Sep21 0:00
> /usr/libexec/bluetooth/bluetoothd -E
First and most important gatttool shall not be used along with
bluetoothd, it is a stand alone tool for testing. That being said you
need to connect in order to discover the attribute the remote device
has, without that we only know about the UUIDs advertised nothing
else.
--
Luiz Augusto von Dentz
>> I'm having a problem using BLE through dbus where the GATT services
>> don't appear after a BLE device has been found during a scan. What is
>> available through dbus is a Device1 node with the correct address and a
>> Name property of the name which was sent in the advertising beacons -
>> however that's the only node available in the tree.
> Are you running bluetoothd with the experimental (-E) flag?
Yes:
~$ ps aux | grep bluetooth
root 8277 0.0 0.1 4320 2628 ? Ss Sep21 0:00
/usr/libexec/bluetooth/bluetoothd -E
On Mon, Sep 21, 2015 at 2:20 PM, Steven Davies <[email protected]> wrote:
> I'm having a problem using BLE through dbus where the GATT services
> don't appear after a BLE device has been found during a scan. What is
> available through dbus is a Device1 node with the correct address and a
> Name property of the name which was sent in the advertising beacons -
> however that's the only node available in the tree.
Are you running bluetoothd with the experimental (-E) flag?
Regards,
Mark
markrages@gmail