[BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Ting Chou]

Hello,

The Problem
-----------

I am trying to connect to a BLE device (thermometer) by the D-Bus API with
following steps:

  1. Call org.bluez.Device1.Connect(), got org.bluez.Error.NotAvailable. But
     from the log of hcidump, the device is connected.
  2. Invoke org.bluez.Device1.Disconnect(), hcidump shows it is disconnected.
  3. Connect again, org.bluez.Device1.Connect() still throws
     org.bluez.Error.NotAvailable, but this time, there's nothing from hcidump,
     i.e., the device is not connected.

I'm not sure is this expected or it is a bug. If this is a bug, and you don't
have time to fix it, I'd love to help, but I may need a mentor.

Reproduce Steps
---------------

1. ting@user-OptiPlex-755:~/w/bluez$ sudo test/test-discovery -i hci0
   [ 00:07:80:4C:5F:17 ]
       Name = DKBLE112 thermometer
       Paired = 0
       Adapter = /org/bluez/hci0
       LegacyPairing = 0
       Alias = DKBLE112 thermometer
       Connected = 0
       Address = 00:07:80:4C:5F:17
       RSSI = -66
       Trusted = 0
       Blocked = 0
   ting@user-OptiPlex-755:~/w/bluez$ sudo test/test-device connect 00:07:80:4C:5F:17
   Traceback (most recent call last):
     File "test/test-device", line 104, in <module>
       device.ConnectProfile(args[2])
     File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in __call__
       return self._proxy_method(*args, **keywords)
     File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
       **keywords)
     File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
       message, timeout)
   dbus.exceptions.DBusException: org.bluez.Error.NotAvailable: Operation currently not available

2. ting@user-OptiPlex-755:~/w/bluez$ sudo test/test-device disconnect 00:1C:4D:00:09:02

3. ting@user-OptiPlex-755:~/w/bluez$ sudo test/test-device connect 00:07:80:4C:5F:17
   Traceback (most recent call last):
     File "test/test-device", line 104, in <module>
       device.ConnectProfile(args[2])
     File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in __call__
       return self._proxy_method(*args, **keywords)
     File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
       **keywords)
     File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
       message, timeout)
   dbus.exceptions.DBusException: org.bluez.Error.NotAvailable: Operation currently not available

I Found
-------

- I checked /var/log/syslog and src/device.c, and found connect_profiles() is
  called twice at the first time calling org.bluez.Device.Connect():

  - 1st time
    dev->svc_resolved==FALSE, device_resolve_svc() is invoked.

  - 2nd time
    dev->svc_resolved==TRUE
    In the for loop of iterating device profiles, there're two profiles:

      a) p->auto_connect==FALSE, p->name==deviceinfo, p->local_uuid==NULL
      b) p->auto_connect==FALSE, p->name==Health Thermometer GATT driver, p->local_uuid==NULL

    Since none of them have auto_connect TRUE, dev->pending==NULL, and
    btd_error_not_available() is called.

- I tried org.bluez.Device1.ConnectProfile() as well, but since all the profiles
  have local_uuid NULL, find_connectable_profile() return NULL and
  btd_error_invalid_args() is called.

Regards,
Ting

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Johan Hedberg]

Hi Ting,

On Wed, Dec 12, 2012, Ting Chou wrote:
> I Found
> -------
> 
> - I checked /var/log/syslog and src/device.c, and found connect_profiles() is
>   called twice at the first time calling org.bluez.Device.Connect():
> 
>   - 1st time
>     dev->svc_resolved==FALSE, device_resolve_svc() is invoked.
> 
>   - 2nd time
>     dev->svc_resolved==TRUE
>     In the for loop of iterating device profiles, there're two profiles:
> 
>       a) p->auto_connect==FALSE, p->name==deviceinfo, p->local_uuid==NULL
>       b) p->auto_connect==FALSE, p->name==Health Thermometer GATT driver, p->local_uuid==NULL
> 
>     Since none of them have auto_connect TRUE, dev->pending==NULL, and
>     btd_error_not_available() is called.
> 
> - I tried org.bluez.Device1.ConnectProfile() as well, but since all the profiles
>   have local_uuid NULL, find_connectable_profile() return NULL and
>   btd_error_invalid_args() is called.

It's not actually local_uuid that is so important but that p->connect is
set. Also, it'd make much more sense to pass the remote UUID to
ConnectProfile than the local one and we'll still do this change before
releasing 5.0. The main thing that needs to be done before that is to
convert profile->remote_uuids list to a single profile->remote_uuid
which is a bit of work since some profiles still declare multiple UUIDs.

So far no LE profile is hooked up to Device.Connect and I'm not sure
exactly how that should be done since LE device are connected through
the general connection establishment procedure which requires scanning
first. Since we already have Device.Pair doing the same as
CreatePairedDevice in BlueZ 4 (and this should work btw, did you try
it?) maybe Device.Connect should be roughly the same for LE devices as
Adapter.CreateDevice is in BlueZ 4? For BR/EDR devices it already serves
this purpose. The main question is what should be done if Device.Connect
is called subsequent times as bluetoothd should anyway already be doing
passive scanning and trying to connect to devices that have supported
profiles.

Johan

RE: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Ting Chou]

Hello Johan,

> -----Original Message-----
> From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> Sent: Wednesday, December 12, 2012 3:52 PM
> To: Ting Chou
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: [BLE] org.bluez.Device1.Connect() returns
> org.bluez.Error.NotAvailable
> 
> Hi Ting,
> 
> On Wed, Dec 12, 2012, Ting Chou wrote:
> > I Found
> > -------
> >
> > - I checked /var/log/syslog and src/device.c, and found
> connect_profiles() is
> >   called twice at the first time calling org.bluez.Device.Connect():
> >
> >   - 1st time
> >     dev->svc_resolved==FALSE, device_resolve_svc() is invoked.
> >
> >   - 2nd time
> >     dev->svc_resolved==TRUE
> >     In the for loop of iterating device profiles, there're two
> profiles:
> >
> >       a) p->auto_connect==FALSE, p->name==deviceinfo, p-
> >local_uuid==NULL
> >       b) p->auto_connect==FALSE, p->name==Health Thermometer GATT
> > driver, p->local_uuid==NULL
> >
> >     Since none of them have auto_connect TRUE, dev->pending==NULL,
> and
> >     btd_error_not_available() is called.
> >
> > - I tried org.bluez.Device1.ConnectProfile() as well, but since all
> the profiles
> >   have local_uuid NULL, find_connectable_profile() return NULL and
> >   btd_error_invalid_args() is called.
> 
> It's not actually local_uuid that is so important but that p->connect
> is set. Also, it'd make much more sense to pass the remote UUID to
> ConnectProfile than the local one and we'll still do this change before
> releasing 5.0. The main thing that needs to be done before that is to
> convert profile->remote_uuids list to a single profile->remote_uuid
> which is a bit of work since some profiles still declare multiple UUIDs.
> 
> So far no LE profile is hooked up to Device.Connect and I'm not sure
> exactly how that should be done since LE device are connected through
> the general connection establishment procedure which requires scanning
> first. Since we already have Device.Pair doing the same as
> CreatePairedDevice in BlueZ 4 (and this should work btw, did you try
> it?) maybe Device.Connect should be roughly the same for LE devices as
> Adapter.CreateDevice is in BlueZ 4? For BR/EDR devices it already
> serves this purpose. The main question is what should be done if
> Device.Connect is called subsequent times as bluetoothd should anyway
> already be doing passive scanning and trying to connect to devices that
> have supported profiles.
> 
> Johan

I tried Device.Pair, it does connect to the LE device like the first call to
Device.Connect, but:

- I can't unpair the device (CancelPairing can't do this).

- If I Device.Disconnect after Device.Pair, then I can't connect to the device
  again by either Device.Connect or Device.Pair:
  - Device1.Connect
    Error org.bluez.Error.NotAvailable: Operation currently not available
  - Device1.Pair
    Error org.bluez.Error.AlreadyExists: Already Exists

I still can't connect to the LE device once I disconnect it.

Thanks,
Ting

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Johan Hedberg]

Hi Ting,

On Wed, Dec 12, 2012, Ting Chou wrote:
> I tried Device.Pair, it does connect to the LE device like the first call to
> Device.Connect, but:
> 
> - I can't unpair the device (CancelPairing can't do this).

There's no "unpair" method. You'd need to call Adapter.RemoveDevice to
do it.

> - If I Device.Disconnect after Device.Pair, then I can't connect to the device
>   again by either Device.Connect or Device.Pair:
>   - Device1.Connect
>     Error org.bluez.Error.NotAvailable: Operation currently not available
>   - Device1.Pair
>     Error org.bluez.Error.AlreadyExists: Already Exists
> 
> I still can't connect to the LE device once I disconnect it.

That means that the profiles that are supposed to be supported with this
device are not calling either device_set_auto_connect() or
btd_device_add_attio_callback(). Both of those functions should cause
bluetoothd to start doing passive scanning and try to connect to the
device. Btw, which kernel version are you using. IIRC you'll need
something like 3.5 or newer for LE passive scanning to work.

Johan

RE: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Ting Chou]

Hello Johan,

> -----Original Message-----
> From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> Sent: Wednesday, December 12, 2012 5:26 PM
> To: Ting Chou
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: [BLE] org.bluez.Device1.Connect() returns
> org.bluez.Error.NotAvailable
> 
> Hi Ting,
> 
> On Wed, Dec 12, 2012, Ting Chou wrote:
> > I tried Device.Pair, it does connect to the LE device like the first
> > call to Device.Connect, but:
> >
> > - I can't unpair the device (CancelPairing can't do this).
> 
> There's no "unpair" method. You'd need to call Adapter.RemoveDevice to
> do it.
> 
> > - If I Device.Disconnect after Device.Pair, then I can't connect to
> the device
> >   again by either Device.Connect or Device.Pair:
> >   - Device1.Connect
> >     Error org.bluez.Error.NotAvailable: Operation currently not
> available
> >   - Device1.Pair
> >     Error org.bluez.Error.AlreadyExists: Already Exists
> >
> > I still can't connect to the LE device once I disconnect it.
> 
> That means that the profiles that are supposed to be supported with
> this device are not calling either device_set_auto_connect() or
> btd_device_add_attio_callback(). Both of those functions should cause
> bluetoothd to start doing passive scanning and try to connect to the
> device. Btw, which kernel version are you using. IIRC you'll need
> something like 3.5 or newer for LE passive scanning to work.
> 

I tried to let btd_device_add_attio_callback() get called by

  Characterisitc.DiscoverCharacteristics()

But still the Device1.Connect() after Device1.Disconnect() does not establish
the connection. connect_profiles() returns btd_error_not_available() since
!dev->pending:

  ting@user-OptiPlex-755:~/w/bluez$ sudo dbus-send --system --dest=org.bluez --type=method_call --print-reply /org/bluez/hci0/dev_00_07_80_4C_5F_17 org.bluez.Device1.Connect
  Error org.bluez.Error.NotAvailable: Operation currently not available

  ting@user-OptiPlex-755:~/w/bluez$ sudo dbus-send --system --dest=org.bluez --type=method_call --print-reply /org/bluez/hci0/dev_00_07_80_4C_5F_17/service000d  org.bluez.Characteristic.DiscoverCharacteristics
  method return sender=:1.1992 -> dest=:1.1997 reply_serial=2
     array [
        object path "/org/bluez/hci0/dev_00_07_80_4C_5F_17/service000d/characteristic000f"
     ]

  ting@user-OptiPlex-755:~/w/bluez$ sudo dbus-send --system --dest=org.bluez --type=method_call --print-reply /org/bluez/hci0/dev_00_07_80_4C_5F_17 org.bluez.Device1.Disconnect
  method return sender=:1.1992 -> dest=:1.1998 reply_serial=2

  ting@user-OptiPlex-755:~/w/bluez$ sudo dbus-send --system --dest=org.bluez --type=method_call --print-reply /org/bluez/hci0/dev_00_07_80_4C_5F_17 org.bluez.Device1.Connect
  Error org.bluez.Error.NotAvailable: Operation currently not available

The kernel I'm using:

  ting@user-OptiPlex-755:~/w/bluez$ uname -a
  Linux user-OptiPlex-755 3.6.6-030606-generic #201211050512 SMP Mon Nov 5 10:20:03 UTC 2012 i686 i686 i686 GNU/Linux

Thank you,
Ting

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Johan Hedberg]

Hi Ting,

On Wed, Dec 12, 2012, Ting Chou wrote:
> > That means that the profiles that are supposed to be supported with
> > this device are not calling either device_set_auto_connect() or
> > btd_device_add_attio_callback(). Both of those functions should cause
> > bluetoothd to start doing passive scanning and try to connect to the
> > device. Btw, which kernel version are you using. IIRC you'll need
> > something like 3.5 or newer for LE passive scanning to work.
> > 
> 
> I tried to let btd_device_add_attio_callback() get called by
> 
>   Characterisitc.DiscoverCharacteristics()

I thought you said some internally supported profiles get detected? Why
then do you need to use the ATT D-Bus interface? FWIW, since
attrib/client.c implementation doesn't match what's documented and since
there hasn't been anyone stepping up to update the code to use D-Bus
properties we'll probably not have the entire Characteristic D-Bus
interface in the 5.0 release. Instead, there's a plan to have a more
comprehensive and generic GATT D-Bus API for both peripheral and central
roles, which will probably land in 5.1 or one of the subsequent
releases.

> But still the Device1.Connect() after Device1.Disconnect() does not establish
> the connection. connect_profiles() returns btd_error_not_available() since
> !dev->pending:

It seems you've misunderstood this part. If the functions I mentioned
are used correctly you will not need to use Device.Connect at all.
Instead bluetoothd will start doing passive scanning and automatically
establish a connection to any device doing connectable advertising.

Johan

RE: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Ting Chou]

Hello Johan,

> -----Original Message-----
> From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> Sent: Wednesday, December 12, 2012 6:08 PM
> To: Ting Chou
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: [BLE] org.bluez.Device1.Connect() returns
> org.bluez.Error.NotAvailable
> 
> Hi Ting,
> 
> On Wed, Dec 12, 2012, Ting Chou wrote:
> > > That means that the profiles that are supposed to be supported with
> > > this device are not calling either device_set_auto_connect() or
> > > btd_device_add_attio_callback(). Both of those functions should
> > > cause bluetoothd to start doing passive scanning and try to connect
> > > to the device. Btw, which kernel version are you using. IIRC you'll
> > > need something like 3.5 or newer for LE passive scanning to work.
> > >
> >
> > I tried to let btd_device_add_attio_callback() get called by
> >
> >   Characterisitc.DiscoverCharacteristics()
> 
> I thought you said some internally supported profiles get detected? Why
> then do you need to use the ATT D-Bus interface? FWIW, since
> attrib/client.c implementation doesn't match what's documented and
> since there hasn't been anyone stepping up to update the code to use D-
> Bus properties we'll probably not have the entire Characteristic D-Bus
> interface in the 5.0 release. Instead, there's a plan to have a more
> comprehensive and generic GATT D-Bus API for both peripheral and
> central roles, which will probably land in 5.1 or one of the subsequent
> releases.
> 
> > But still the Device1.Connect() after Device1.Disconnect() does not
> > establish the connection. connect_profiles() returns
> > btd_error_not_available() since
> > !dev->pending:
> 
> It seems you've misunderstood this part. If the functions I mentioned
> are used correctly you will not need to use Device.Connect at all.
> Instead bluetoothd will start doing passive scanning and automatically
> establish a connection to any device doing connectable advertising.
> 

Do you mean once a LE device with internally supported profiles is discovered,
it will be connected automatically? Which means I cannot connect manually, at
the timing I prefer?

Since with my BT 4.0 dongle, Adpater.StartDiscovery discover also LE devices, I
thought I should use Device.Connect to connect to the device.

Thanks,
Ting

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Johan Hedberg]

Hi Ting,

On Wed, Dec 12, 2012, Ting Chou wrote:
> Do you mean once a LE device with internally supported profiles is
> discovered, it will be connected automatically? Which means I cannot
> connect manually, at the timing I prefer?

Correct. In many ways one could consider the peripheral (advertising
device) to be the one that "initiates" the connection by starting to do
connectable advertising. We are merely reacting to this "request" by
sending a HCI_LE_Create_Connection command.

> Since with my BT 4.0 dongle, Adpater.StartDiscovery discover also LE
> devices, I thought I should use Device.Connect to connect to the
> device.

I agree that Device.Connect should at least work on devices that have
been discovered but on whom we haven't completed service discovery yet.
This would be analogous to the old Adapter.CreateDevice and it'd allow
us to implement proper support for devices not supporting SMP (i.e.
devices you can't call Device.Pair on). What remains to be discussed is
whether Device.Connect is useful for LE devices in some more extended
sense. Maybe it could at least force calling device_set_auto_connect().

Johan

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Anderson Lizardo]

Hi Johan,

On Wed, Dec 12, 2012 at 6:36 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> I agree that Device.Connect should at least work on devices that have
> been discovered but on whom we haven't completed service discovery yet.
> This would be analogous to the old Adapter.CreateDevice and it'd allow
> us to implement proper support for devices not supporting SMP (i.e.
> devices you can't call Device.Pair on). What remains to be discussed is
> whether Device.Connect is useful for LE devices in some more extended
> sense. Maybe it could at least force calling device_set_auto_connect().

On that matter, I would suggest (although I didn't spent much time
thinking on the consequences) that Device.Connect should add device to
auto connect list, and Device.Disconnect should disconnect current
connection and remove device from autoconnect list.

For devices which have services implemented inside BlueZ (e.g. HTP),
I'm not sure this is a good idea, because these profiles explicitely
state on their spec what should happen in case of disconnection, so it
is better to have BlueZ handle this for them (IMHO).

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Anderson Lizardo]

Hi Ting,

On Wed, Dec 12, 2012 at 6:21 AM, Ting Chou <Ting.Chou@iasolution.net> wrote:
> Do you mean once a LE device with internally supported profiles is discovered,
> it will be connected automatically? Which means I cannot connect manually, at
> the timing I prefer?
>
> Since with my BT 4.0 dongle, Adpater.StartDiscovery discover also LE devices, I
> thought I should use Device.Connect to connect to the device.

According to the General Connection Establishment procedure (GCEP, see
Core spec page 1716 for details), the host shall start scanning and:

"When the Host discovers a device to which the Host may attempt to connect,
the Host shall stop the scanning, and initiate a connection using the
direct con-
nection establishment procedure."

That's exactly what BlueZ does for LE devices. For paired devices
whose profile is supported internally by BlueZ (e.g. a LE
thermometer), the GCEP will keep trying to connect to them, where
"connect" means using LE active/passive scan, followed by the
procedure above.

For unsupported devices, IIRC there will be not attempt to keep
re-connecting to it (or even keep the connection up after service
discovery). This should be addressed by the generic GATT API in
attrib/client.c, but the current implementation has several
limitations and is not implementing a consistent API, therefore it
will probably be removed for first BlueZ 5.0 release, and a
replacement (which should probably address reconnection for
external/proprietary GATT services) will be implemented.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

RE: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Ting Chou]

Hi Anderson,

> -----Original Message-----
> From: Anderson Lizardo [mailto:anderson.lizardo@openbossa.org]
> Sent: Wednesday, December 12, 2012 6:53 PM
> To: Ting Chou
> Cc: Johan Hedberg; linux-bluetooth@vger.kernel.org
> Subject: Re: [BLE] org.bluez.Device1.Connect() returns
> org.bluez.Error.NotAvailable
> 
> Hi Ting,
> 
> On Wed, Dec 12, 2012 at 6:21 AM, Ting Chou <Ting.Chou@iasolution.net>
> wrote:
> > Do you mean once a LE device with internally supported profiles is
> > discovered, it will be connected automatically? Which means I cannot
> > connect manually, at the timing I prefer?
> >
> > Since with my BT 4.0 dongle, Adpater.StartDiscovery discover also LE
> > devices, I thought I should use Device.Connect to connect to the
> device.
> 
> According to the General Connection Establishment procedure (GCEP, see
> Core spec page 1716 for details), the host shall start scanning and:
> 
> "When the Host discovers a device to which the Host may attempt to
> connect, the Host shall stop the scanning, and initiate a connection
> using the direct con- nection establishment procedure."
> 
> That's exactly what BlueZ does for LE devices. For paired devices whose
> profile is supported internally by BlueZ (e.g. a LE thermometer), the
> GCEP will keep trying to connect to them, where "connect" means using
> LE active/passive scan, followed by the procedure above.
> 

Does this mean the "User selects a device to connect" in Figure 9.6 (Page 1715,
Flow chart for a device performing the general connection establishment
procedure) is not needed for supported devices?

> For unsupported devices, IIRC there will be not attempt to keep re-
> connecting to it (or even keep the connection up after service
> discovery). This should be addressed by the generic GATT API in
> attrib/client.c, but the current implementation has several limitations
> and is not implementing a consistent API, therefore it will probably be
> removed for first BlueZ 5.0 release, and a replacement (which should
> probably address reconnection for external/proprietary GATT services)
> will be implemented.
> 

I'm not sure if I understand correctly. But do you mean the GCEP you mentioned
above is applied while "reconnecting" to a supported device?

Thanks,
Ting

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Anderson Lizardo]

Hi Ting,

On Wed, Dec 12, 2012 at 7:30 AM, Ting Chou <Ting.Chou@iasolution.net> wrote:
> Hi Anderson,
>
>> -----Original Message-----
>> From: Anderson Lizardo [mailto:anderson.lizardo@openbossa.org]
>> Sent: Wednesday, December 12, 2012 6:53 PM
>> To: Ting Chou
>> Cc: Johan Hedberg; linux-bluetooth@vger.kernel.org
>> Subject: Re: [BLE] org.bluez.Device1.Connect() returns
>> org.bluez.Error.NotAvailable
>>
>> Hi Ting,
>>
>> On Wed, Dec 12, 2012 at 6:21 AM, Ting Chou <Ting.Chou@iasolution.net>
>> wrote:
>> > Do you mean once a LE device with internally supported profiles is
>> > discovered, it will be connected automatically? Which means I cannot
>> > connect manually, at the timing I prefer?
>> >
>> > Since with my BT 4.0 dongle, Adpater.StartDiscovery discover also LE
>> > devices, I thought I should use Device.Connect to connect to the
>> device.
>>
>> According to the General Connection Establishment procedure (GCEP, see
>> Core spec page 1716 for details), the host shall start scanning and:
>>
>> "When the Host discovers a device to which the Host may attempt to
>> connect, the Host shall stop the scanning, and initiate a connection
>> using the direct con- nection establishment procedure."
>>
>> That's exactly what BlueZ does for LE devices. For paired devices whose
>> profile is supported internally by BlueZ (e.g. a LE thermometer), the
>> GCEP will keep trying to connect to them, where "connect" means using
>> LE active/passive scan, followed by the procedure above.
>>
>
> Does this mean the "User selects a device to connect" in Figure 9.6 (Page 1715,
> Flow chart for a device performing the general connection establishment
> procedure) is not needed for supported devices?

This image is incorrect, and is fixed on ESR06 (see correct image on
page 29 of that document). There is no user interaction for GCEP.

>> For unsupported devices, IIRC there will be not attempt to keep re-
>> connecting to it (or even keep the connection up after service
>> discovery). This should be addressed by the generic GATT API in
>> attrib/client.c, but the current implementation has several limitations
>> and is not implementing a consistent API, therefore it will probably be
>> removed for first BlueZ 5.0 release, and a replacement (which should
>> probably address reconnection for external/proprietary GATT services)
>> will be implemented.
>>
>
> I'm not sure if I understand correctly. But do you mean the GCEP you mentioned
> above is applied while "reconnecting" to a supported device?

Yes, all GAP connection procedures are applicable for re-connection.
There is no "reconnection" procedure as per GAP (as far as I know).
But note that each GATT profile can specify reconnection procedures in
case of disconnection due to link loss (most of those that I read have
this). For instance, in HTP:

"5.2.4 Link Loss Reconnection Procedure
When a connection is terminated due to link loss, a Collector should attempt to
reconnect to the Thermometer using any of the GAP connection procedures with the
parameters in Table 5.2."

This is what BlueZ is doing for profiles implemented internally,
except that the parameters we use are not the ones recommended on the
profile specs (that could be implemented in future, but for now GCEP
uses fixed connection parameters).

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

RE: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Ting Chou]

Hi Anderson,

> > I'm not sure if I understand correctly. But do you mean the GCEP you
> > mentioned above is applied while "reconnecting" to a supported device?
> 
> Yes, all GAP connection procedures are applicable for re-connection.
> There is no "reconnection" procedure as per GAP (as far as I know).
> But note that each GATT profile can specify reconnection procedures in
> case of disconnection due to link loss (most of those that I read have
> this). For instance, in HTP:
> 
> "5.2.4 Link Loss Reconnection Procedure
> When a connection is terminated due to link loss, a Collector should
> attempt to reconnect to the Thermometer using any of the GAP connection
> procedures with the parameters in Table 5.2."
> 
> This is what BlueZ is doing for profiles implemented internally, except
> that the parameters we use are not the ones recommended on the profile
> specs (that could be implemented in future, but for now GCEP uses fixed
> connection parameters).
> 

So I should exercise the D-Bus API like following for LE device:

  Adapter1.StartDiscovery
  Device1.Pair
  ...
  ...
  // link loss
  ...
  // auto reconnect
  ...
  Adapter1.RemoveDevice

Is my understanding correct?

Thank you,
Ting

Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable

[Johan Hedberg]

Hi Ting,

On Thu, Dec 13, 2012, Ting Chou wrote:
> > > I'm not sure if I understand correctly. But do you mean the GCEP you
> > > mentioned above is applied while "reconnecting" to a supported device?
> > 
> > Yes, all GAP connection procedures are applicable for re-connection.
> > There is no "reconnection" procedure as per GAP (as far as I know).
> > But note that each GATT profile can specify reconnection procedures in
> > case of disconnection due to link loss (most of those that I read have
> > this). For instance, in HTP:
> > 
> > "5.2.4 Link Loss Reconnection Procedure
> > When a connection is terminated due to link loss, a Collector should
> > attempt to reconnect to the Thermometer using any of the GAP connection
> > procedures with the parameters in Table 5.2."
> > 
> > This is what BlueZ is doing for profiles implemented internally, except
> > that the parameters we use are not the ones recommended on the profile
> > specs (that could be implemented in future, but for now GCEP uses fixed
> > connection parameters).
> > 
> 
> So I should exercise the D-Bus API like following for LE device:
> 
>   Adapter1.StartDiscovery
>   Device1.Pair
>   ...
>   ...
>   // link loss
>   ...
>   // auto reconnect
>   ...
>   Adapter1.RemoveDevice
> 
> Is my understanding correct?

Yes, except that you should call Adapter1.StopDiscovery before calling
Device1.Pair.

Johan